CDN Nedir? Web Sitesini Nasıl Hızlandırır?

CDN, web sitesi dosyalarını ziyaretçiye yakın dağıtım sunucularında önbelleğe alarak hızlandırır. Statik içerik cache hit olduğunda istek origin sunucuya gitmez; ağ gecikmesi, TLS ve uygulama yükü azalır. Ancak CDN veritabanını veya yavaş kodu kendiliğinden düzeltmez; doğru cache, DNS ve HTTPS ayarı gerekir.

CDN nedir ve istekleri nasıl karşılar?

Bir web sitesinin tüm dosyalarını yalnızca tek bir sunucudan dağıtmak, ziyaretçi ile sunucu arasındaki mesafe arttıkça gecikmeyi büyütür. CDN, statik içerikleri farklı bölgelerdeki kenar sunucularda önbelleğe alır; ziyaretçinin DNS yönlendirmesiyle kendisine daha yakın bir noktadan dosya almasını sağlar. Böylece origin sunucunun bağlantı ve işlem yükü azalır.

CDN açılımı Content Delivery Network, yani İçerik Dağıtım Ağıdır. CDN sağlayıcısı; JavaScript, CSS, görsel, font ve bazı durumlarda HTML yanıtlarını önceden belirlenmiş kurallara göre saklar. İstek geldiğinde dosya kenar sunucuda varsa doğrudan oradan döner. Dosya yoksa CDN, origin adı verilen asıl web sunucusundan içeriği alır, yanıtı ziyaretçiye iletir ve uygun görülürse sonraki istekler için saklar.

Bu mimaride VPS ortadan kalkmaz. VPS çoğu zaman uygulamanın, veritabanının ve değişken içeriğin çalıştığı origin sunucudur; CDN ise ziyaretçiye daha yakın dağıtım katmanıdır.

CDN’i statik içerik ve kontrollü önbellekleme için konumlandırın – oturum, sepet ve yönetim paneli gibi kişisel yanıtları varsayılan olarak cache etmeyin.

CDN web sitesini nasıl hızlandırır?

Hızlanma tek bir mekanizmadan gelmez. Ağ mesafesi, TLS bağlantısı, dosyanın tekrar indirilmemesi ve origin sunucunun daha az istek işlemesi birlikte etki eder.

Mesafeyi ve ilk bayt bekleme süresini azaltır

Ziyaretçi İzmir’de, origin sunucu Frankfurt’ta olabilir. DNS çözümünden sonra trafik, sağlayıcının uygun gördüğü edge noktasına gider. CDN yanıtı önbellekte tutuyorsa Frankfurt’a her istekte yeni bağlantı açılması gerekmez. Bu durum özellikle büyük görseller, JavaScript paketleri ve font dosyalarında belirgindir.

TTFB, yani ilk bayta kadar geçen süre, yalnızca sunucunun PHP veya veritabanı hızını ölçmez; ağ yolunu, TLS anlaşmasını, edge işlemlerini ve cache durumunu da kapsar. CDN cache hit olduğunda origin uygulamasına ulaşılmadığı için değişken uygulama süresi devreden çıkar. Cache miss durumunda ise CDN’in origin’e yaptığı isteğin süresi yine hesaba katılır.

Tekrar indirmeleri önler

Tarayıcı önbelleği ile CDN önbelleği aynı şey değildir. Tarayıcı dosyayı kullanıcının cihazında saklar; CDN ise aynı içeriği birden fazla ziyaretçi için edge noktasında saklar. HTTP Cache-Control başlığındaki max-age, s-maxage ve no-store yönergeleri bu katmanların davranışını etkiler. RFC 9111, HTTP önbelleklerinin temel kurallarını tanımlar.

Örneğin, sürümlenmiş bir CSS dosyası için Cache-Control: public, max-age=31536000, immutable kullanılabilir. Buradaki 31536000 saniye 365 güne karşılık gelir. Dosya içeriği değiştiğinde aynı URL’yi kullanmak yerine app.2026-09.css gibi yeni bir dosya adı üretmek gerekir.

Önbellek süresini içerik türüne göre belirleyin – sürümlenmiş statik dosyalarda uzun, sık değişen HTML yanıtlarında kısa TTL kullanın.

CDN ile origin sunucu arasındaki fark nedir?

Origin, uygulamanın doğruluk kaynağıdır. Kullanıcı hesabı, sepet, sipariş veya yönetim işlemleri gibi yanıtlar çoğunlukla burada üretilir. CDN ise dağıtım ve trafik emme katmanı olarak davranır. Her dosyayı körlemesine cache etmek doğru değildir; yanlış bir kural, bir kullanıcının HTML yanıtını başka bir kullanıcıya gösterebilir.

CDN kullanırken origin sunucunun yalnızca CDN IP aralıklarından gelen HTTP ve HTTPS trafiğini kabul etmesi sık kullanılan bir güvenlik modelidir. Sağlayıcının güncel IP listesi otomatik veya düzenli biçimde takip edilmelidir. Sabit bir listeyi yıllarca değiştirmemek, CDN’in yeni edge noktalarını farkında olmadan engelleyebilir.

Origin üzerinde Nginx çalışıyorsa temel proxy başlıkları, gerçek istemci IP’si ve HTTPS durumu ayrıca ele alınmalıdır. Reverse proxy katmanını yeni kuruyorsanız Ubuntu’da Nginx Kurulumu ve İlk Yapılandırma Rehberi içindeki temel sanal host adımları yardımcı olabilir.

CDN hangi içerikleri cache eder?

En güvenli başlangıç, değişmeyen ve URL’si içerik sürümünü taşıyan dosyalardır. Aşağıdaki içerikler çoğu sitede CDN için uygundur:

• CSS ve JavaScript dosyaları
• JPEG, PNG, WebP, AVIF ve SVG görselleri
• Web fontları
• Video parçaları ve indirilebilir statik dosyalar
• Versiyonlanmış API yanıtları

HTML için karar daha dikkatli verilmelidir. Bir blogun herkese aynı görünen yazı sayfası cache edilebilir; ancak kullanıcı adı, sepet, para birimi veya oturum durumu yanıtı değiştiriyorsa private ya da no-store tercih edilmelidir.

Cookie kullanımı da önemlidir. Bazı CDN kuralları Cookie başlığı taşıyan yanıtları varsayılan olarak cache dışı bırakır. Bazı kurulumlarda ise yalnızca belirli cookie’ler hesaba katılır. Cache anahtarına gereksiz sorgu parametreleri eklenmesi de hit oranını düşürür. ?utm_source= gibi analitik parametreler için normalleştirme yapılabiliyorsa aynı içeriğin onlarca ayrı kopyası oluşmaz.

Cache-Control başlıklarını kontrol etme

Üretim sitenizde CDN eklemeden önce origin yanıtını inceleyin:

curl -I https://www.example.com/assets/app.2026-09.css

Çıktıda Cache-Control, ETag, Last-Modified ve varsa CDN’e ait Age, X-Cache veya benzeri başlıklar incelenir. Sağlayıcılar bu başlıkları farklı adlarla gösterebilir; tek bir header adına güvenmek yerine paneldeki cache durumuyla karşılaştırın.

CDN’in aynı dosyaya ikinci istekte cache hit üretip üretmediğini görmek için birkaç saniye arayla yeniden istek gönderilebilir:

curl -sS -D - -o /dev/null https://www.example.com/assets/app.2026-09.css

-D - yanıt başlıklarını ekrana basar, -o /dev/null ise dosyanın gövdesini indirmeden testi tamamlar. İlk isteğin cache miss, sonraki isteğin hit olması beklenir; ancak edge noktası, TTL ve sağlayıcı politikasına göre sonuç değişebilir.

Cache hit durumunu başlıklarla doğrulayın – yalnızca hız testi skoruna bakarak CDN’in doğru çalıştığını varsaymayın.

CDN kurulumu için DNS ve HTTPS nasıl ayarlanır?

CDN kurulumu genellikle alan adının DNS kayıtlarını sağlayıcının ağına yönlendirmekle başlar. Yaygın modelde www.example.com için bir CNAME kaydı, kök alan adı için ise sağlayıcının desteklediği ALIAS, ANAME veya apex yönlendirme yöntemi kullanılır. DNS’te CNAME bir alan adını başka bir alan adına bağlar; doğrudan IP adresi vermez.

Değişiklikten önce mevcut kayıtları not edin. MX kayıtları e-posta trafiğini, TXT kayıtları doğrulama ve SPF yapılandırmasını, CAA kayıtları ise sertifika yetkilendirmesini etkileyebilir. Yalnızca web kaydını taşıyıp e-posta kayıtlarını yanlışlıkla silmek sık rastlanan bir geçiş hatasıdır.

dig +short www.example.com CNAME
dig +short www.example.com A
dig +short example.com MX

İlk komut CNAME hedefini, ikinci komut IPv4 yanıtını, üçüncü komut posta sunucularını gösterir. DNS yanıtı tek bir makinede hemen değişmeyebilir; TTL, resolver önbelleği ve sağlayıcının dağıtım süresi birlikte değerlendirilmelidir. DNS teşhisinde panelden önce dig +short kullanmak, görünen kayıt ile gerçekten dönen kayıt arasındaki farkı hızlıca ortaya çıkarır.

HTTPS tarafında sertifika CDN edge noktalarında sunulur. Origin ile CDN arasındaki bağlantı da mümkünse HTTPS olmalı ve sertifika doğrulaması kapatılmamalıdır. “Flexible” benzeri modeller, ziyaretçi ile CDN arasını şifreleyip CDN ile origin arasını düz HTTP bırakabilir; bu yaklaşım oturum cookie’leri ve giriş bilgileri için uygun değildir.

CDN, origin’e hangi Host başlığını göndereceğini ve SNI değerini doğru kullanmalıdır. Origin sertifikası yalnızca iç ağ adını kapsıyorsa doğrulama hatası oluşabilir. Sertifika yenileme, yönlendirme ve HTTP-HTTPS politikası geçişten önce test edilmelidir.

CDN kullanmanın güvenlik ve performans sınırları nelerdir?

CDN, DDoS trafiğinin tamamını sihirli biçimde yok etmez. Sağlayıcının kapasitesi, koruma katmanları, rate limit kuralları ve uygulamaya özgü saldırıların niteliği önemlidir. Özellikle geçersiz parametrelerle cache bypass yapan istekler origin’e kadar ulaşabilir.

Origin IP adresi daha önce DNS kayıtlarında, e-posta başlıklarında, eski bir alt alan adında veya doğrudan sunucu banner’larında açığa çıkmışsa saldırgan CDN’i atlayabilir. Origin firewall’ı yalnızca CDN’in kaynak ağlarına izin verecek şekilde daraltmak bu riski azaltır. SSH için 22 numaralı portu değiştirmek tek başına güvenlik değildir; yönetim erişimi anahtar tabanlı kimlik doğrulama, firewall ve izleme ile korunmalıdır.

Rate limit kuralını önce gözlem modunda uygulamak daha güvenlidir. Giriş endpoint’ine IP başına çok düşük bir sınır koymak, ortak NAT kullanan gerçek kullanıcıları da engelleyebilir. API istemcileri için kimlik, token veya kullanıcı hesabı temelli sınırlar IP tabanlı kurallardan daha uygun olabilir.

Bir CDN, veritabanı sorgularını hızlandırmaz. Uygulama her cache miss’te pahalı sorgu çalıştırıyorsa origin hâlâ yavaş kalır. Sorgu tarafındaki darboğazlar için Veritabanı İndeksi Nedir? Sorgular Nasıl Hızlanır? yazısındaki EXPLAIN yaklaşımı ayrı bir çalışma alanıdır. CDN, veritabanı optimizasyonunun yerine geçmez.

Benzer şekilde CDN, origin’deki 502 hatasını ortadan kaldırmaz. Nginx ile PHP-FPM, upstream veya uygulama arasındaki kopukluk devam eder; yalnızca daha önce cache’lenmiş bazı yanıtlar erişilebilir kalabilir. 502 Bad Gateway Hatası Nedir ve Nasıl Çözülür? içindeki upstream ve log kontrolleri bu noktada hâlâ geçerlidir.

Origin’i doğrudan erişime açık bırakmayın – CDN devredeyken bile firewall, uygulama logları ve kaynak IP doğrulamasını birlikte izleyin.

CDN cache temizleme ve içerik güncelleme nasıl yapılır?

Cache temizleme, CDN’de saklanan nesnelerin silinip sonraki istekte origin’den yeniden alınmasıdır. Tüm cache’i temizlemek kolay görünür; ancak yüksek trafikli bir sitede aynı anda çok sayıda isteğin origin’e dönmesine neden olabilir. Buna cache stampede veya thundering herd etkisi denir.

Tercih edilen yöntem, dosyaları sürümlemektir. style.css yerine style.2026-09-25.css kullanılır ve HTML yeni dosya adına geçirilir. Acil bir düzeltmede yalnızca ilgili URL için purge uygulanır. HTML ve API yanıtlarında kısa TTL, stale-while-revalidate veya sağlayıcının benzeri mekanizmaları kontrollü biçimde kullanılabilir.

Cache temizleme sonrasında üç kontrol yapılmalıdır:

1. Yeni içeriğin origin yanıtında bulunduğunu doğrulayın.
2. Farklı bir edge noktasından cache durumunu kontrol edin.
3. Tarayıcı önbelleğinin eski dosyayı kullanmadığından emin olun.

301 yönlendirmeleri de cache’lenebilir. Yanlış bir kalıcı yönlendirme uzun süre istemcilerde ve CDN noktalarında kalabilir. Alan adı veya HTTPS geçişi planlanıyorsa 301 Yönlendirme Nedir? SEO İçin Kullanım Rehberi içindeki geçiş sırasını izlemek, geri dönüş planı hazırlamadan kalıcı yönlendirme yayımlamaktan daha güvenlidir.

CDN seçerken hangi ölçümleri izlemelisiniz?

“CDN aktif” bilgisi tek başına yeterli değildir. İzleme panelinde en az cache hit oranı, origin istek sayısı, origin yanıt süresi, HTTP durum kodları, bant genişliği ve edge bölgesi bazında gecikme takip edilmelidir.

Cache hit oranı yükselirken kullanıcı deneyimi kötüleşebilir; örneğin CDN eski HTML’i hızlıca sunuyor olabilir. Bu nedenle ölçümler URL türüne göre ayrılmalıdır. Statik dosyalarda yüksek hit beklenirken kişiselleştirilmiş endpoint’lerde düşük veya sıfır hit normal olabilir.

Gerçek kullanıcı ölçümleri ile sentetik testleri ayırın. Lighthouse ve benzeri araçlar tek bir lokasyondan test yapabilir. Farklı bölgelerden curl testleri, RUM verileri ve uygulama logları birlikte değerlendirilmelidir. HTTP/2 ve HTTP/3 desteği de ölçülmelidir; QUIC hakkında temel bilgi için QUIC Nedir? Daha Hızlı İnternet Protokolü başlığına bakabilirsiniz.

Örnek bir kontrol döngüsü şöyledir: önce CDN öncesi TTFB ve origin CPU değerlerini kaydedin, sonra yalnızca statik dosyaları CDN’e alın, hit oranını ve hata kodlarını izleyin, en son HTML cache kurallarını küçük bir URL grubunda deneyin. Her aşamada geri alma yolu bulunmalıdır.

Bir sayfanın hızlanmaması CDN’in başarısız olduğu anlamına gelmez. HTML yanıtı dinamik olabilir, görseller gereğinden büyük olabilir, JavaScript ana iş parçacığını uzun süre meşgul edebilir veya origin sorguları yavaş olabilir. CDN ağ transferini ve tekrar indirmeleri azaltır; tarayıcı render maliyetini tek başına çözmez.

CDN'i Etkinleştirmeden Önce Şunları Kontrol Edin

• Statik ve dinamik içerik URL'lerini ayırın.
• CSS, JavaScript ve görseller için Cache-Control başlıklarını belirleyin.
• Origin sunucunun gerçek IP adresini doğrudan erişime karşı sınırlandırın.
• DNS kayıtlarını ve mevcut MX, TXT, CAA değerlerini yedekleyin.
• CDN ile origin arasındaki HTTPS sertifika doğrulamasını test edin.
• Cache hit, origin gecikmesi ve HTTP hata kodları için izleme kurun.
• Tek URL purge ve geri dönüş prosedürünü gerçek bir dosyayla deneyin.

Sık Sorulan Sorular

Kaynaklar

• RFC 9111 – HTTP Caching — rfc-editor.org
• MDN – HTTP Caching — developer.mozilla.org
• Cloudflare – Cache Documentation — developers.cloudflare.com
• nginx – Proxy Module — nginx.org