- Katılım
- 21 May 2023
- Mesajlar
- 475
- Tepki
- 17
- Puan
- 18
Yönetim panelinde değişiklik tamam, kaynak sunucuda yeni içerik var; buna rağmen bazı ziyaretçiler hâlâ önceki sürümü görüyor. Böyle bir durumda doğrudan “bütün önbelleği temizle” düğmesine basmak cazip geliyor. Fakat eski cevabı hangi katmanın verdiğini bulmadan yapılan toplu temizlik, sorunu kısa süreliğine saklayabilir ve kaynak sunucuya gereksiz yük bindirebilir.
Burada amaç CDN’i kapatmak değil, aynı isteğin nerede farklı bir nesneye dönüştüğünü görmek. Bir URL, birkaç yanıt başlığı ve kontrollü iki karşılaştırma çoğu zaman tahminden daha fazla şey söyler.
Ziyaretçinin gördüğü sayfa doğrudan kaynak sunucudan gelmeyebilir. İstek yolunda birden fazla saklama noktası bulunabilir:
Gizli sekmede yeni sürümü görmek, sorunun kesinlikle tarayıcı cache’i olduğunu göstermez. Gizli pencere farklı çerezle, farklı cache key ile veya farklı uygulama akışıyla istek atmış olabilir. Benzer şekilde URL’nin sonuna rastgele bir sorgu parametresi eklemek de cache’i temizlemez; yalnızca yapılandırmaya bağlı olarak başka bir cache anahtarı oluşturabilir.
CDN’in temel çalışma mantığını önce oturtmak isteyenler CDN ve cloud hizmetleri konusuna bakabilir. Buradaki odak ise doğrudan arıza anında kanıt toplamaktır.
Tarayıcının geliştirici araçları yararlı olsa da ilk karşılaştırmayı temiz bir GET isteğiyle yapmak daha nettir. `HEAD` yerine aşağıdaki biçimde GET kullanmak, sunucunun yöntemlere farklı davranması ihtimalini de azaltır:
Bu komut gövdeyi kaydetmeden yanıt başlıklarını ekrana basar. Aşağıdaki çıktı ise 16 Ağustos 2026’da herkese açık bir JavaScript dosyasına yapılan gerçek isteğin seçilmiş başlıklarıdır; `Age` ve tarih gibi değerler sonraki istekte doğal olarak değişebilir:
Buradaki `CF-Cache-Status: HIT`, nesnenin Cloudflare önbelleğinde bulunduğunu söylüyor. `Age: 5658` ise bu cevabın edge cache’de ne kadar süredir bulunduğuna dair saniye cinsinden bilgi veriyor. `Cache-Control` tarayıcı ve paylaşımlı cache’lerin tazelik kararını etkiliyor; `Vary: accept-encoding` de sıkıştırma tercihi değiştiğinde cevabın ayrı değerlendirilebileceğini gösteriyor.
Cloudflare’ın cache yanıtları belgesi durumları ayrıntılı açıklıyor. Teşhis sırasında en sık karşılaşılanlar şöyle okunabilir:
`ETag` ve `Last-Modified` başlıkları da değerlidir. Bunlar içeriğin yeni mi eski mi olduğunu kendi başlarına kanıtlamaz; ancak iki cevabı karşılaştırmak ve koşullu doğrulamanın çalışıp çalışmadığını görmek için iyi işaretlerdir. Aynı URL için edge ve origin cevaplarının ETag değeri ya da gövde özeti farklıysa araştırılacak yer daralır.
CDN bir nesneyi yalnızca “dosya adı” ile bulmaz; bir cache key üretir. Cloudflare’ın resmî cache key belgesine göre varsayılan anahtar tam URL’yi, yani şema, alan adı, yol ve sorgu dizesini içerir. Yapılandırılmış özel anahtarlar ise seçilen sorgu parametrelerini, istek başlıklarını, çerezleri, host bilgisini, cihaz türünü, ülkeyi veya dili de hesaba katabilir.
Bu yüzden ekranda aynı görünen `/kampanya` yolu gerçekte birkaç ayrı cache nesnesine karşılık gelebilir:
Burada iki zıt hata görülür. Gereğinden fazla parçalanmış anahtar, aynı dosyanın çok sayıda kopyasını üretir ve cache isabetini düşürür. Gereğinden fazla birleştirilmiş anahtar ise gerçekten farklı olması gereken cevapları tek nesnede toplar. İkinci durum kişiye özel içeriklerde yalnızca “eski sayfa” değil, veri gizliliği sorunu da doğurabilir.
Tek dosya temizliği doğru URL için etkili ve dar kapsamlı bir araçtır. Cloudflare’ın tek dosya purge belgesi, nesnenin veri merkezlerinden çıkarıldığını ve sonraki isteğin güncel sürümü origin’den alarak cache’i yeniden doldurduğunu belirtiyor. Ancak işlemin hedefi, cache’e yazılan anahtarla uyuşmalıdır.
Özel cache key içinde header veya cookie varsa panelden yalnız URL girerek yapılan tek dosya temizliği ilgili varyantları geçersiz kılmayabilir. Böyle bir yapılandırmada API isteğine anahtarın parçası olan değerleri de eklemek ya da ihtiyaca göre prefix/cache-tag kullanmak gerekir. URL yolunun büyük-küçük harfe duyarlı olması ve tek dosya temizliğinde joker karakter desteklenmemesi de gözden kaçan iki ayrıntıdır.
“Purge everything” bu nedenle ilk hamle olmamalı. Bütün cache boşalınca popüler sayfalar ve dosyalar aynı anda origin’e yönelir. Trafiğin yoğun olduğu bir anda, başlangıçtaki içerik sorununa kaynak sunucu yükü de eklenebilir.
Altyapının diğer parçalarıyla birlikte bir kontrol sırası gerekiyorsa Hosting / CDN / SSL Başlangıç Rotası yardımcı olur. Cache kuralının hız kadar özel veri ve oturum güvenliğini de etkilediğini unutmamak için hızlı ve güvenli site uygulamalarını da birlikte değerlendirmek gerekir.
Bir dağıtımda yeni CSS dosyası sunucuya yüklenmiş olsun. HTML hâlâ `/assets/app.css?v=41` adresini çağırırken ekip `/assets/app.css?v=42` için purge işlemi yaparsa panel başarı döndürür; fakat ziyaretçi eski URL’yi istemeye devam eder. CDN burada yanlış davranmıyordur, kendisine sorulan eski nesneyi sunuyordur.
Başka bir durumda `/kampanya` için cache key’e dil ve cihaz türü eklenmiş olabilir. Masaüstü Türkçe varyantı yenilenirken mobil İngilizce varyantı eski kalabilir. Ekip yalnız kendi tarayıcısında kontrol yaptığında sorun çözülmüş görünür. Bu kez doğru soru “Purge çalıştı mı?” değil, “Hangi varyantı temizledik ve kullanıcı hangisini istiyor?” olur.
HTTP cache davranışının ortak zemini RFC 9111 içinde tanımlanır. Buradaki önemli dil ayrımı şudur: `no-cache`, cevabın hiçbir yerde saklanamayacağı anlamına gelmez; yeniden kullanılmadan önce doğrulanmasını ister. Hiç saklanmaması isteniyorsa `no-store` ayrı yönergedir. Kural yazarken bu iki ifadeyi eş anlamlı kabul etmek, teşhisi gereksiz yere zorlaştırır.
Eski içerik gördüğünüzde önce tam isteği ve dönen cevabı kaydedin. Sonra tarayıcı, service worker, uygulama cache’i, CDN ve origin katmanlarını tek tek ayırın. `HIT` ya da yüksek bir `Age` önemli bir ipucudur; fakat cache key bilinmeden tek başına hüküm değildir.
En sağlam çözüm, “her şeyi temizledik” demek değil; hangi URL’nin, hangi varyantın, hangi veri merkezinde, hangi kuralla eski kaldığını gösterebilmektir. Sizde sorun yalnız belirli cihazda veya dilde ortaya çıkıyorsa yanıt başlıklarını kişisel bilgi bırakmadan paylaşın; birlikte hangi anahtar parçasının ayrım yarattığını daha hızlı bulabiliriz.
Burada amaç CDN’i kapatmak değil, aynı isteğin nerede farklı bir nesneye dönüştüğünü görmek. Bir URL, birkaç yanıt başlığı ve kontrollü iki karşılaştırma çoğu zaman tahminden daha fazla şey söyler.
Önce “eski” olan katmanı bulun
Ziyaretçinin gördüğü sayfa doğrudan kaynak sunucudan gelmeyebilir. İstek yolunda birden fazla saklama noktası bulunabilir:
- Tarayıcı önbelleği: Kullanıcının cihazında tutulan HTML, CSS, JavaScript veya görsel.
- Service worker / uygulama önbelleği: Özellikle PWA’larda ağdan bağımsız çalışan ve eski dosyayı kendi kuralıyla döndürebilen katman.
- Sunucu ya da CMS önbelleği: WordPress sayfa önbelleği, LiteSpeed, Nginx proxy, uygulama cache’i veya oluşturulmuş statik çıktı.
- CDN edge önbelleği: Ziyaretçiye yakın veri merkezinde saklanan cevap.
- Kaynak uygulama: Veritabanı, yayın durumu, yanlış dağıtım ya da birden fazla origin arasında sürüm farkı.
Gizli sekmede yeni sürümü görmek, sorunun kesinlikle tarayıcı cache’i olduğunu göstermez. Gizli pencere farklı çerezle, farklı cache key ile veya farklı uygulama akışıyla istek atmış olabilir. Benzer şekilde URL’nin sonuna rastgele bir sorgu parametresi eklemek de cache’i temizlemez; yalnızca yapılandırmaya bağlı olarak başka bir cache anahtarı oluşturabilir.
CDN’in temel çalışma mantığını önce oturtmak isteyenler CDN ve cloud hizmetleri konusuna bakabilir. Buradaki odak ise doğrudan arıza anında kanıt toplamaktır.
Bir GET yanıtını delile dönüştürün
Tarayıcının geliştirici araçları yararlı olsa da ilk karşılaştırmayı temiz bir GET isteğiyle yapmak daha nettir. `HEAD` yerine aşağıdaki biçimde GET kullanmak, sunucunun yöntemlere farklı davranması ihtimalini de azaltır:
Bash:
curl -sS -D - -o /dev/null 'https://ornek.com/degisen-sayfa'Bu komut gövdeyi kaydetmeden yanıt başlıklarını ekrana basar. Aşağıdaki çıktı ise 16 Ağustos 2026’da herkese açık bir JavaScript dosyasına yapılan gerçek isteğin seçilmiş başlıklarıdır; `Age` ve tarih gibi değerler sonraki istekte doğal olarak değişebilir:
Kod:
$ curl -sS -D - -o /dev/null \
'https://unpkg.com/react@18.2.0/umd/react.production.min.js'
HTTP/2 200
date: Sun, 16 Aug 2026 01:25:22 GMT
content-type: text/javascript; charset=utf-8
content-length: 10737
cf-cache-status: HIT
age: 5658
cache-control: public, max-age=31536000
last-modified: Wed, 05 Aug 2026 22:34:19 GMT
server: cloudflare
vary: accept-encodingBuradaki `CF-Cache-Status: HIT`, nesnenin Cloudflare önbelleğinde bulunduğunu söylüyor. `Age: 5658` ise bu cevabın edge cache’de ne kadar süredir bulunduğuna dair saniye cinsinden bilgi veriyor. `Cache-Control` tarayıcı ve paylaşımlı cache’lerin tazelik kararını etkiliyor; `Vary: accept-encoding` de sıkıştırma tercihi değiştiğinde cevabın ayrı değerlendirilebileceğini gösteriyor.
Cloudflare’ın cache yanıtları belgesi durumları ayrıntılı açıklıyor. Teşhis sırasında en sık karşılaşılanlar şöyle okunabilir:
- HIT: Nesne edge önbelleğinde bulundu.
- MISS: O veri merkezinin cache’inde bulunamadı ve origin’den alındı. Tek başına hata değildir; ilk istek olması mümkündür.
- EXPIRED: Kayıt vardı fakat tazelik süresi dolmuştu; origin’den yeni cevap istendi.
- REVALIDATED: Origin, koşullu istek sonucunda kayıtlı cevabın hâlâ geçerli olduğunu doğruladı.
- STALE: Süresi geçmiş cevap, origin’e ulaşılamadığı için cache’den sunuldu.
- UPDATING: Süresi geçen cevap verilirken yenileme arka planda sürüyor. Bu durum `stale-while-revalidate` kullanılan akışlarda görülebilir.
- BYPASS veya DYNAMIC: Cevap cache’e uygun bulunmamış ya da kural gereği cache aramasına alınmamış olabilir. İkisinin ayrımı yapılandırmaya ve kararın isteğin hangi aşamasında verildiğine bağlıdır.
Küçük ama önemli ayrım' Alıntı:
`ETag` ve `Last-Modified` başlıkları da değerlidir. Bunlar içeriğin yeni mi eski mi olduğunu kendi başlarına kanıtlamaz; ancak iki cevabı karşılaştırmak ve koşullu doğrulamanın çalışıp çalışmadığını görmek için iyi işaretlerdir. Aynı URL için edge ve origin cevaplarının ETag değeri ya da gövde özeti farklıysa araştırılacak yer daralır.
Cache key, görünen URL’den daha geniş olabilir
CDN bir nesneyi yalnızca “dosya adı” ile bulmaz; bir cache key üretir. Cloudflare’ın resmî cache key belgesine göre varsayılan anahtar tam URL’yi, yani şema, alan adı, yol ve sorgu dizesini içerir. Yapılandırılmış özel anahtarlar ise seçilen sorgu parametrelerini, istek başlıklarını, çerezleri, host bilgisini, cihaz türünü, ülkeyi veya dili de hesaba katabilir.
Bu yüzden ekranda aynı görünen `/kampanya` yolu gerçekte birkaç ayrı cache nesnesine karşılık gelebilir:
- `/kampanya?ref=bulten` ile sorgusuz adres farklı anahtara düşebilir.
- Mobil ve masaüstü için cihaz türü anahtara eklenmiş olabilir.
- `Accept-Language` ya da ülke bilgisi farklı içerik varyantları üretebilir.
- Belirli bir çerezin varlığı veya değeri anonim ve oturumlu cevapları ayırabilir.
- Bir Worker, yönlendirme veya origin kuralı istek hedefini değiştirebilir.
Burada iki zıt hata görülür. Gereğinden fazla parçalanmış anahtar, aynı dosyanın çok sayıda kopyasını üretir ve cache isabetini düşürür. Gereğinden fazla birleştirilmiş anahtar ise gerçekten farklı olması gereken cevapları tek nesnede toplar. İkinci durum kişiye özel içeriklerde yalnızca “eski sayfa” değil, veri gizliliği sorunu da doğurabilir.
Purge başarılı görünürken eski cevap neden kalır?
Tek dosya temizliği doğru URL için etkili ve dar kapsamlı bir araçtır. Cloudflare’ın tek dosya purge belgesi, nesnenin veri merkezlerinden çıkarıldığını ve sonraki isteğin güncel sürümü origin’den alarak cache’i yeniden doldurduğunu belirtiyor. Ancak işlemin hedefi, cache’e yazılan anahtarla uyuşmalıdır.
Özel cache key içinde header veya cookie varsa panelden yalnız URL girerek yapılan tek dosya temizliği ilgili varyantları geçersiz kılmayabilir. Böyle bir yapılandırmada API isteğine anahtarın parçası olan değerleri de eklemek ya da ihtiyaca göre prefix/cache-tag kullanmak gerekir. URL yolunun büyük-küçük harfe duyarlı olması ve tek dosya temizliğinde joker karakter desteklenmemesi de gözden kaçan iki ayrıntıdır.
“Purge everything” bu nedenle ilk hamle olmamalı. Bütün cache boşalınca popüler sayfalar ve dosyalar aynı anda origin’e yönelir. Trafiğin yoğun olduğu bir anda, başlangıçtaki içerik sorununa kaynak sunucu yükü de eklenebilir.
Sorunu güvenli biçimde daraltma sırası
- Tek bir örnek URL seçin. Kullanıcının gördüğü tam adresi, saatini, oturum durumunu, cihazını ve mümkünse eski içeriği ayırt eden kısa bir metni kaydedin. “Site eski” ifadesi yerine hangi nesnenin eski olduğunu belirleyin.
- Aynı isteği iki veya üç kez alın. `CF-Cache-Status`, `Age`, `Cache-Control`, `Vary`, `ETag` ve `Last-Modified` değerlerini karşılaştırın. İlk istek MISS, ikincisi HIT oluyorsa cache’in yeniden dolma davranışını görmüş olursunuz.
- Tarayıcı katmanını ayırın. DevTools içindeki “Disable cache” yalnız araç açıkken etkili olabilir; service worker ayrıca kontrol edilmelidir. Farklı tarayıcı sonucu ipucu verir ama tek başına kök neden değildir.
- Origin cevabını kontrollü karşılaştırın. Yönetilen bir test alan adı veya yetkili ortamda doğru Host ve TLS adı korunarak origin’e istek atın. Origin IP’sini, erişim anahtarını ya da yönetim adresini forum mesajına yapıştırmayın.
- Varyantları bilinçli deneyin. Sorgu dizesi, dil, cihaz ve çerez değiştiğinde cevap da değişiyorsa hangi öğenin cache key’e girdiğini kurallardan doğrulayın. Rastgele parametreyle “düzeldi” sonucuna varmayın.
- En dar temizliği seçin. Önce tam URL, gerekiyorsa cache key değerleriyle API; sonra prefix veya tag. Tüm alan adını temizlemek son seçenek olsun.
- Temizlikten sonra iki tarafı da doğrulayın. Yalnız paneldeki başarı bildirimine değil, yeni GET cevabına ve içerik sürümüne bakın. Origin hâlâ eski cevap veriyorsa CDN’in temizlenmesi doğal olarak yeni içerik üretmez.
Altyapının diğer parçalarıyla birlikte bir kontrol sırası gerekiyorsa Hosting / CDN / SSL Başlangıç Rotası yardımcı olur. Cache kuralının hız kadar özel veri ve oturum güvenliğini de etkilediğini unutmamak için hızlı ve güvenli site uygulamalarını da birlikte değerlendirmek gerekir.
Küçük bir senaryo: sorun purge değil, hedef olabilir
Bir dağıtımda yeni CSS dosyası sunucuya yüklenmiş olsun. HTML hâlâ `/assets/app.css?v=41` adresini çağırırken ekip `/assets/app.css?v=42` için purge işlemi yaparsa panel başarı döndürür; fakat ziyaretçi eski URL’yi istemeye devam eder. CDN burada yanlış davranmıyordur, kendisine sorulan eski nesneyi sunuyordur.
Başka bir durumda `/kampanya` için cache key’e dil ve cihaz türü eklenmiş olabilir. Masaüstü Türkçe varyantı yenilenirken mobil İngilizce varyantı eski kalabilir. Ekip yalnız kendi tarayıcısında kontrol yaptığında sorun çözülmüş görünür. Bu kez doğru soru “Purge çalıştı mı?” değil, “Hangi varyantı temizledik ve kullanıcı hangisini istiyor?” olur.
Tekrarını azaltan yayın alışkanlıkları
- Statik dosyaları sürümleyin: İçerik hash’i taşıyan `app.8f3c2.css` gibi adlar, eski ve yeni sürümün yanlışlıkla karışmasını azaltır.
- HTML ile varlık TTL’lerini ayırın: Sık değişen HTML ile değişmez isimli statik dosyaya aynı uzun ömrü vermeyin.
- Kişisel yolları açıkça dışarıda bırakın: Giriş, hesap, sepet, ödeme ve yönetim sayfalarını geniş “cache everything” kurallarına bırakmayın.
- Cache key kararını belgeleyin: Hangi query, header, cookie, dil veya cihaz bilgisinin anahtara girdiği ekip içinde görünür olsun.
- Purge’u dağıtımın parçası yapın: Elle hatırlanan toplu temizlik yerine değişen URL’leri ya da cache tag’lerini yayın akışından hedefleyin.
- Bir içerik sürümü taşıyın: Yanıta zararsız bir sürüm başlığı veya sayfaya dağıtım kimliği eklemek, “eski” tartışmasını ölçülebilir hale getirir.
HTTP cache davranışının ortak zemini RFC 9111 içinde tanımlanır. Buradaki önemli dil ayrımı şudur: `no-cache`, cevabın hiçbir yerde saklanamayacağı anlamına gelmez; yeniden kullanılmadan önce doğrulanmasını ister. Hiç saklanmaması isteniyorsa `no-store` ayrı yönergedir. Kural yazarken bu iki ifadeyi eş anlamlı kabul etmek, teşhisi gereksiz yere zorlaştırır.
Purge düğmesinden önce sorulacak son soru
Eski içerik gördüğünüzde önce tam isteği ve dönen cevabı kaydedin. Sonra tarayıcı, service worker, uygulama cache’i, CDN ve origin katmanlarını tek tek ayırın. `HIT` ya da yüksek bir `Age` önemli bir ipucudur; fakat cache key bilinmeden tek başına hüküm değildir.
En sağlam çözüm, “her şeyi temizledik” demek değil; hangi URL’nin, hangi varyantın, hangi veri merkezinde, hangi kuralla eski kaldığını gösterebilmektir. Sizde sorun yalnız belirli cihazda veya dilde ortaya çıkıyorsa yanıt başlıklarını kişisel bilgi bırakmadan paylaşın; birlikte hangi anahtar parçasının ayrım yarattığını daha hızlı bulabiliriz.
Dijital Dünyanıza Yön Veren Pusula
