CDN Önbellek Davranışı: Neler Önbelleğe Alınır ve Nasıl Geçersiz Kılınır

CDN önbellek davranışına dair ayrıntılı rehber: Hangi yanıtlar varsayılan olarak önbelleğe alınır, Cache-Control ve Vary başlıklarının etkisi ve tüm önbelleği temizlemeden seçici geçersiz kılma yöntemi.

7 dk Güncellendi 10 Nov 2026

Siteyi CDN'e taşıdınız, CSS dosyasını değiştirdiniz, ama kullanıcının tarayıcısı hâlâ eski sürümü gösteriyor. Ya da daha kötüsü: Ürün sayfası fiyat değişikliğinden sonra bazı kullanıcılara eski rakamı, bazılarına yeni rakamı döndürüyor. Sorun genellikle CDN'de değil; ağın kenarının (edge) tam olarak neyi hangi anahtarla sakladığını bilmiyor olmanızdadır. Bu metin, CDN önbellek davranışını tahmin ederek değil, öngörerek yönetebilmeniz için bilmeniz gereken her şeydir.

CDN varsayılan olarak neyi önbelleğe alır

Kısa cevap: Düşündüğünüzden daha azını. Çoğu CDN yalnızca GET ve HEAD yanıtlarını önbelleğe alır ve 200, 203, 204, 206, 300, 301, 404, 410 durum kodlu her yanıtı "önbelleğe alınabilir" olarak tanır. POST, PUT, DELETE yanıtları, Cache-Control başlığı koysanız bile asla önbelleğe alınmaz. Bunu çoğu kişi bilmez ve saatlerce hata arar.

İlkinden daha fazla sorun çıkaran ikinci nokta: Yanıtta hiçbir önbellek başlığı yoksa, CDN varsayılan bir politikayla karar verir. Bu politika sağlayıcıdan sağlayıcıya değişir. Bazıları başlıksız yanıtı hiç önbelleğe almaz; bazıları kısa bir varsayılan TTL ile önbelleğe alır. Varsayılan davranışa güvenirseniz, sağlayıcı politikasını değiştirdiği gün siteniz habersizce davranış değiştirir.

Önbellek anahtarı yalnızca URL değildir

Varsayılan anahtar neredeyse her zaman metodu, yolu ve sorgu dizesini içerir. Yani /product?id=12 ve /product?id=13 iki ayrı girdidir, ancak /product?id=12&utm_source=x da üçüncü bir girdi olur. İşte burada önbellek hacminiz gereksiz yere birkaç katına çıkar ve hit ratio düşer. Standart çözüm, pazarlama parametrelerini önbellek anahtarında yok saymaktır; neredeyse tüm CDN'lerde bunun için yapılandırılabilir bir query string listesi vardır.

Vary başlığı anahtarı daha da karmaşıklaştırır. Yanıtınızda Vary: Accept-Encoding varsa, gzip ve brotli sürümleri ayrı ayrı saklanır. Vary: User-Agent koyarsanız, önbelleği fiilen devre dışı bırakmış olursunuz, çünkü her tarayıcı farklı bir anahtar oluşturur ve hit ratio neredeyse sıfıra iner. Ben pratikte Vary üzerinde yalnızca iki değeri severim: Accept-Encoding ve özel durumlarda Accept-Language. Gerisini kaldırın.

Başlıklar tam olarak nasıl karar verir

Öncelik sırasını koruyun, çünkü CDN'ler tam olarak bu sırayı uygular:

  1. Cache-Control: no-store her şeyden önce gelir. Yanıt ne kenarda ne de tarayıcıda saklanır.
  2. Cache-Control: private yalnızca tarayıcının önbelleğe alabileceği, kenarın alamayacağı anlamına gelir. Kullanıcı çerezine bağlı sayfalar için.
  3. Cache-Control: public, max-age=31536000, immutable app.4f2c1a.js gibi sürümlenmiş dosyalar için.
  4. s-maxage yalnızca paylaşımlı önbellek (kenar) içindir ve max-age'e göre önceliklidir.
  5. Expires yalnızca Cache-Control yoksa kullanılır. İkisi de varsa, Cache-Control kazanır.

Sürümlenmiş statik dosyalar için yazdığım gerçek bir satır:

Cache-Control: public, max-age=31536000, s-maxage=31536000, immutable

Ve her an değişebilecek HTML için:

Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=300, stale-if-error=86400

s-maxage=60 sayısı, kenarın en fazla bir dakika eski sürümü sunduğu anlamına gelir. stale-while-revalidate=300, son kullanma tarihinden sonraki beş dakikaya kadar eski yanıtı hemen ver ve arka planda yenile demektir. stale-if-error=86400 ise origin tam bir gün hata verirse, kenarın aynı eski sürümü sunması anlamına gelir. Bu iki direktif, origin kesintisi sırasında "site ayakta" ile "502 sayfası" arasındaki farktır.

İşte burada hata yapıyorlar

Gördüğüm en yaygın hata: Cache-Control: no-cache koyup bunun "önbelleğe alma" anlamına geldiğini sanmak. Bu başlık "önbelleğe al, ama her kullanımdan önce origin'e sor" demektir. Sonuç, kenarın her istek için origin'e gidip gelmesi, TTFB'nin yükselmesi ve origin yükünün birkaç katına çıkmasıdır; oysa ekip önbelleği tamamen kapattığını sanır. Gerçekten önbelleğe alınmasını istemiyorsanız, no-store yazın. Bu iki kelime arasındaki fark, işe yaramaz bir CDN ile verimli bir CDN arasındaki farktır.

İkinci hata: Statik yanıtlarda Set-Cookie. Bazı CDN'ler yanıtta Set-Cookie görür görmez onu önbelleğe alınamaz olarak işaretler. JS ve CSS dosyalarında çerez ayarlıyorsanız, önbelleği kendi elinizle öldürüyorsunuz.

Tüm önbelleği temizlemek yerine seçici geçersiz kılma

İçerik değiştiğinde iki yolunuz var. Birinci yol tam purge'dir: Her şey kenardan silinir ve istek dalgası bir anda origin'e çarpar. Siteniz yüksek trafikliyse, bu origin'i yerle bir eder. İkinci yol seçici geçersiz kılmadır: Yalnızca o yolu veya o deseni temizleyin.

Çoğu CDN'de üç tür purge vardır: Tam URL'ye göre, prefix veya wildcard'a göre ve tag ya da surrogate key'e göre. Üçüncü tür en kesin olanıdır. Yanıtta Cache-Tag: product-12, category-shoes başlığı koyarsanız, sonradan yalnızca product-12'yi geçersiz kılabilirsiniz, kalan kategoriye dokunmadan. Büyük mağazalarda gerçekten işe yarayan tek yöntem budur.

YöntemKesinlikMaliyetNerede uygundur
Tam PurgeSıfırOrigin'e ağır dalgaGenel layout değişikliği, nadiren
URL'ye göre PurgeYüksekHafifBirkaç belirli sayfa
Prefix'e göre PurgeOrtaOrta/blog/* gibi tüm bir yol
Tag'e göre PurgeYüksekKod değişikliği gerektirirMağaza, veriye bağlı içerik

Az söylenen gerçek bir kısıtlama: Geçersiz kılma anında gerçekleşmez. Komutun tüm kenarlara ulaşması sıfırdan birkaç saniyeye kadar sürer ve büyük coğrafi ağlarda bu sayı daha da artabilir. İş mantığınız "anında"ya bağlıysa, kenar önbelleğine güvenmeyin; o yolu önbellek dışında tutun.

Geçersiz kılmayı azaltan sürümleme deseni

En iyi geçersiz kılma, gerek duyulmayan geçersiz kılmadır. Dosya adını içeriğine bağlayın: main.css yerine main.a91f3c.css. Artık her değişiklik yeni bir URL oluşturur ve eski dosya bir yıllık TTL ile kendiliğinden sona erer. HTML'yi kısa, varlıkları uzun önbelleğe alın. Bu kombinasyon hem yüksek hit ratio verir hem de geçersiz kılmayı nadir bir işleme dönüştürür.

Altyapınız ServerNet bulut sunucusu veya bulut altyapısı (IaaS) üzerindeyse, bu deseni origin'in önüne health check ve SSL'li bir load balancer koyarak birleştirebilirsiniz, böylece tam purge dalgası bile origin'i yerle bir etmez. Sürümlenmiş varlıkları sunmak için de nesne depolama alanı, web sunucusu diskinden daha mantıklı bir seçenektir, çünkü başlıkları bir kez ayarlarsınız ve bir daha dokunmazsınız.

Gerçek önbellek davranışı nasıl ölçülür

Dokümantasyonun söylediğine değil, yanıt başlığına bakın. Şu komutu çalıştırın:

curl -sSI -H 'Accept-Encoding: gzip' https://example.com/main.css | grep -iE 'cache-control|age|x-cache|cf-cache|vary'

Age başlığı altın sayıdır. Age: 0 ise yanıt origin'den yeni gelmiştir. Age: 47 ise bu yanıt kenarda 47 saniye beklemiştir ve siz hit almışsınızdır. Arka arkaya iki kez istek gönderin; ikinci seferde Age daha büyük olmalıdır. Olmazsa, önbellek çalışmıyor demektir ve fazladan Set-Cookie ya da Vary aramalısınız.

Gerçek hit ratio'yu ölçmek için CDN panosuna güvenmeyin; origin loglarını sayın. Önbelleği etkinleştirdikten sonra origin'e ulaşan istek sayısı değişmediyse, muhtemelen tüm trafik saklanmadan önbellekten geçiyor demektir. Bu durum, origin istek hızı üzerinde bulut izleme ve uyarı ile tespit edilebilir; bu sayıdaki ani sıçramaya konulacak basit bir uyarı, birçok kesintiyi gerçekleşmeden yakalar.

Önbellek ayarlarını değiştirdikten sonra sunucu yapılandırmasını da değiştiriyorsanız, her riskli değişiklikten önce bulut alanından bir snapshot alın. Bir snapshot'tan geri dönmek birkaç dakikadır; yapılandırmayı elle yeniden oluşturmak birkaç saat.

Sıkça sorulan sorular

CDN önbellek davranışında no-cache ile no-store arasındaki fark nedir?

no-cache saklamaya izin verir ama her kullanımdan önce origin'den doğrulanması gerekir, dolayısıyla origin trafiği azalmaz. no-store hiç saklamaz ve kenarda ya da tarayıcıda hiçbir sürüm kalmaz. Ödeme sayfası gibi hassas veriler için no-store doğrudur.

Purge sonrası neden bazı kullanıcılar hâlâ eski sürümü görüyor?

Çünkü purge yalnızca kenar önbelleğini temizler, kullanıcının tarayıcı önbelleğini değil. Dosya tarayıcıda max-age=31536000 ile saklanmışsa, son kullanma tarihine kadar aynı sürümü görür. Kalıcı çözüm, sık purge değil, dosya adını içerik hash'ine göre değiştirmektir.

CDN 404 yanıtlarını da önbelleğe alır mı?

Evet, birçok uygulamada 404 yanıtı önbelleğe alınabilir. Bir sayfayı geçici olarak kaldırıp sonra geri getirdiyseniz, kenar hâlâ 404 verebilir. Bunu önlemek için 404 yanıtlarına max-age=60 gibi kısa bir Cache-Control koyun.

Vary başlığı hit ratio'yu nasıl bozar?

Vary içine gelen her değer önbellek anahtarının bir parçası olur. Vary: User-Agent fiilen her tarayıcı sürümü için ayrı bir girdi oluşturur ve hit ratio'yu neredeyse sıfıra indirir. Mümkün olduğunca yalnızca Accept-Encoding'i tutun.

Sonraki adım basit: Hemen şimdi curl -sSI ile bir statik dosyanın ve bir HTML sayfasının başlıklarını alın ve Age ile Cache-Control'ü yan yana koyun. İkinci istekte Age sayısı büyümüyorsa, önbellek sorununuz tam oradadır, CDN ayarlarında değil.

Bu sayfa yardımcı oldu mu?