Alan adını Cloudflare'a verdin, turuncu bulutu açtın ve "artık sitem CDN'de" dedin. Sonra cf-cache-status başlığına baktığında her HTML isteğinde DYNAMIC yazdığını gördün. Yani Cloudflare gerçekte hiçbir sayfanı önbelleğe almıyor, sadece trafiğin arasından geçiriyor. Bu, Cloudflare kullanan sitelerin büyük çoğunluğunun içinde bulunduğu durumdur ve varsayılan ayarların böyle çalışması bir hata değil, bilinçli bir tercihtir: Cloudflare senin sitendeki hangi sayfanın kişiye özel olduğunu bilemez, o yüzden HTML'e hiç dokunmaz.
Bu rehberde Cloudflare cache kurallarının nasıl çalıştığını, varsayılan olarak neyin önbelleğe alındığını, Cache Rules motoruyla HTML'i nasıl güvenle önbelleğe alacağını, çerezli isteklerde önbelleği nasıl atlatacağını, cache key'i nasıl sadeleştireceğini ve önbelleği nasıl doğru temizleyeceğini anlatacağım. Örnek ifadeler doğrudan panele yapıştırılabilir durumda.
Cloudflare Varsayılan Olarak Neyi Önbelleğe Alır#
Cloudflare, proxy modunda (turuncu bulut) çalışırken uzantı temelli bir varsayılan liste kullanır. css, js, jpg, jpeg, png, webp, avif, gif, svg, ico, woff, woff2, ttf, pdf, zip, mp4 gibi statik uzantılara sahip dosyaları kendiliğinden önbelleğe alır. Bu listede olmayan her şey, özellikle uzantısız yollar ve .php ile biten adresler, varsayılan olarak önbelleğe alınmaz.
HTML'in listede olmaması kritik bir ayrıntıdır. Ana sayfan, kategori sayfaların, ürün sayfaların hiçbiri sen açıkça söylemedikçe uç sunucularda saklanmaz. Bunun sonucu şudur: Cloudflare kullansan bile her sayfa isteği origin sunucuna kadar gider ve PHP çalışır. Statik varlıklarda kazanç sağlarsın, sayfa üretim süresinde sağlamazsın.
Bunun dışında Cloudflare bazı durumlarda önbelleğe almayı kendiliğinden reddeder. Yanıtta Set-Cookie başlığı varsa, Cache-Control: private, no-store veya no-cache gönderiliyorsa, ya da yanıt bir yetkilendirme gerektiren istekten dönüyorsa önbellekleme atlanır. Bu davranış origin'in sözünü dinlemek anlamına gelir ve genelde doğrudur; ama WordPress gibi sistemler ziyaretçiye gereksiz yere çerez basabildiği için pratikte önbelleği sessizce devre dışı bırakır.
Durumu görmek için tek komut yeter:
# HTML icin onbellek durumunu kontrol et
curl -sSI https://firmaniz.com/ | grep -iE 'cf-cache-status|cache-control|age|set-cookie'
# Ornek cikti (onbellege alinmiyor):
# cf-cache-status: DYNAMIC
# cache-control: no-cache, must-revalidate
# set-cookie: PHPSESSID=...
cf-cache-status Değerlerini Okumak#
Yaptığın her değişikliğin sonucunu bu tek başlıktan okuyacaksın, o yüzden değerleri ezberlemeye değer.
| Değer | Anlamı | Ne yapmalısın |
|---|---|---|
| HIT | Uç sunucudan karşılandı | Hedef bu, bir şey yapma |
| MISS | Önbellekte yoktu, origin'den çekildi | İkinci istekte HIT bekle |
| EXPIRED | Vardı ama TTL doldu, yenilendi | TTL kısa olabilir |
| REVALIDATED | Doğrulandı, origin değişmemiş demiş | Normal davranış |
| UPDATING | Eski kopya sunuluyor, arka planda yenileniyor | Normal, iyi bir işaret |
| STALE | Origin'e ulaşılamadı, eski kopya sunuldu | Origin sağlığını kontrol et |
| BYPASS | Bir kural veya başlık önbelleği atlattı | Kasıtlı mı, kontrol et |
| DYNAMIC | Önbelleğe alınabilir görülmedi | Kural yazman gerekiyor |
DYNAMIC ile BYPASS arasındaki farkı karıştırma: DYNAMIC, "bu içerik önbelleklenebilir listesinde değil" demektir; BYPASS ise "önbelleklenebilirdi ama bir şey atlatılmasını söyledi" demektir. İlkini kural yazarak, ikincisini o kuralı bulup düzelterek çözersin.
Cache Rules ile HTML Önbellekleme#
Cloudflare'ın modern kural motoru Cache Rules'tur; eski Page Rules yerine bunu kullan. Panelde Caching bölümünün altında yer alır ve bir ifade (expression) ile eşleşen isteklere ne yapılacağını belirlersin.
HTML'i önbelleğe almanın adımları şöyle:
- Cloudflare panelinde alan adını seç, Caching altındaki Cache Rules sayfasını aç.
- Create rule ile yeni kural oluştur, anlamlı bir isim ver (örneğin
HTML edge cache). - İfade alanına hangi isteklerin eşleşeceğini yaz.
- Cache eligibility kısmında Eligible for cache seç.
- Edge TTL bölümünde ya origin başlıklarına uymayı ya da sabit bir süre vermeyi seç.
- Browser TTL ile tarayıcının kopyayı ne kadar tutacağını ayarla.
- Kuralı kaydet ve sıralamada doğru yerde olduğundan emin ol; kurallar yukarıdan aşağı değerlendirilir.
Bir örnek ifade, yalnızca ana site içeriğini kapsayan ama panel ve API yollarını dışarıda bırakan biçimde şöyle yazılır:
(http.host eq "firmaniz.com"
and not starts_with(http.request.uri.path, "/wp-admin")
and not starts_with(http.request.uri.path, "/wp-json")
and not starts_with(http.request.uri.path, "/sepet")
and not starts_with(http.request.uri.path, "/hesabim")
and http.request.method eq "GET")
Burada kritik nokta, önbelleğe alınmaması gereken yolları kuralın kendisinde dışarıda bırakmaktır. Sepet, ödeme, üyelik ve yönetim sayfaları uç sunucuda saklanırsa bir kullanıcının sepetini başka birine gösterme riski doğar; bu, önbellekleme dünyasının en pahalı hatasıdır.
Bypass Kuralları ve Çerezler#
Oturum açmış kullanıcılara önbellekten sayfa göstermemek için ikinci bir kural yazarsın. Mantık şudur: giriş yapmış kullanıcı belirli bir çerez taşır; o çerez varsa önbelleği tamamen atlat.
(http.cookie contains "wordpress_logged_in_"
or http.cookie contains "woocommerce_items_in_cart"
or http.cookie contains "comment_author_"
or http.cookie contains "PHPSESSID")
Bu kuralda eylem olarak Bypass cache seçilir ve kural, HTML önbellekleme kuralının üstünde yer alır. Sıralama önemlidir; alttaki kural üsttekini geçersiz kılmaz, ilk eşleşen kazanır.
Çerez temelli bypass'ın bir bedeli vardır ve peşinen bilmelisin: eğer sitene giren herkese daha ilk sayfada çerez basılıyorsa bu kural neredeyse tüm trafiği bypass eder ve önbellekleme hiç devreye girmez. Bu yüzden önce origin'in kime çerez bastığını denetle. Anonim ziyaretçiye analitik dışında çerez basmayan bir yapı, önbellek oranını kat kat yükseltir. Bu konuyu daha geniş biçimde CDN cache hit oranını artırma yazısında ele aldım.
Edge TTL, Browser TTL ve Origin Başlıkları#
Cloudflare'da iki ayrı süre vardır ve ikisini karıştırmak yaygın bir hatadır. Edge TTL kopyanın Cloudflare uç sunucusunda ne kadar duracağını, Browser TTL ise ziyaretçinin tarayıcısında ne kadar duracağını belirler.
Doğru strateji genellikle şudur: Edge TTL uzun, Browser TTL kısa. Uç sunucudaki kopyayı istediğin an temizleyebilirsin, ama kullanıcının tarayıcısındaki kopyaya erişimin yoktur. İçeriği güncelledikten sonra ziyaretçinin günlerce eski sayfayı görmesini istemezsin.
| İçerik türü | Edge TTL | Browser TTL | Gerekçe |
|---|---|---|---|
| Hash'li JS/CSS | Çok uzun (1 yıl) | Çok uzun (1 yıl) | Dosya adı değişiyor, riski yok |
| Görseller | Uzun (1 ay) | Orta (1 gün) | Nadiren değişir |
| Blog / kategori HTML | Orta (birkaç saat) | Çok kısa (dakikalar) | Güncelleme sonrası purge edilir |
| Ürün sayfası HTML | Kısa | Çok kısa | Fiyat ve stok değişir |
| Sepet, hesap, API | Önbellekleme yok | Yok | Kişiye özel |
Edge TTL için "Use cache-control header if present" seçeneği, kararı origin'e bırakır. Kendi başlıklarını doğru yönetiyorsan en temiz yöntem budur, çünkü tek bir gerçeğin olur: sunucun. Başlıkların anlamını netleştirmek istersen Cache-Control başlıkları rehberine, doğrulama mekaniği için ETag ve Last-Modified farkı yazısına bak.
Origin tarafında HTML için mantıklı bir başlık şöyle görünür:
# Anonim ziyaretcilere kisa omurlu ama uc sunucuda uzun yasayan HTML
location / {
add_header Cache-Control "public, max-age=60, s-maxage=7200, stale-while-revalidate=120";
}
Buradaki s-maxage yalnızca paylaşımlı önbellekleri (yani Cloudflare'ı) ilgilendirir, max-age ise tarayıcıyı. Böylece tek başlıkla iki farklı ömür tanımlarsın.
Cache Key, Query String ve Purge#
Cloudflare bir isteği önbellekte ararken bir cache key üretir; varsayılan olarak bu anahtar tam URL'i, sorgu dizesini ve bazı başlıkları içerir. Sorgu dizesindeki her farklı değer ayrı bir kayıt demektir. Reklam kampanyalarından gelen utm_source, utm_medium, fbclid gibi parametreler içerik açısından hiçbir şeyi değiştirmez, ama her biri yeni bir önbellek girdisi doğurur ve hit oranını çökertir.
Cache Rules içinde Cache Key bölümünden sorgu dizesi davranışını ayarlayabilirsin: ya tüm sorgu dizesini yok say, ya yalnızca belirli parametreleri dahil et. Doğru yaklaşım genellikle bir izin listesi tutmaktır; yani sayfa ve arama gibi gerçekten içeriği değiştiren parametreleri anahtara dahil eder, gerisini görmezden gelirsin.
Önbelleği temizlemenin üç yolu var ve hangisini seçtiğin önemlidir:
- Tek URL temizleme. Bir yazıyı güncelledin, sadece onu temizle. En güvenli ve en hızlı yöntemdir.
- Önek veya hostname temizleme. Bir bölümü tamamen yenilemek gerektiğinde kullanılır, üst planlarda bulunur.
- Her şeyi temizleme. Tüm kopyaları siler; ardından her istek origin'e gider ve sunucun ani bir yük dalgası alır. Yalnızca gerçekten gerekliyse kullan.
API üzerinden tek URL temizlemek dağıtım (deploy) sonrası otomasyona bağlanabilir:
# Tek bir adresi onbellekten temizle
curl -sS -X POST \
"https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
-H "Authorization: Bearer API_TOKEN" \
-H "Content-Type: application/json" \
--data '{"files":["https://firmaniz.com/blog/yeni-yazi"]}'
Geliştirme sırasında geçici olarak her şeyi atlatmak istersen panelin Development Mode anahtarını kullan; belirli bir süre sonra kendiliğinden kapanır, o yüzden açık unutma riski düşüktür.
Sık Yapılan Hatalar#
En yaygın hata, "Cache Everything" benzeri geniş bir kuralı istisna tanımlamadan yazmaktır. Bunu yaptığında panel sayfaları, sepet ve giriş ekranı da uç sunucularda saklanır; bir kullanıcının oturumlu görünümü başka birine gösterilebilir. Geniş kural yazacaksan istisnaları önce yaz.
İkinci hata, Cloudflare'ı açıp origin başlıklarını hiç düzeltmemektir. Origin no-cache gönderiyorsa Cloudflare çoğu senaryoda buna uyar ve kural yazsan bile beklediğin davranışı göremezsin. Önce curl -sSI ile origin'in ne söylediğine bak.
Üçüncü hata, test ederken tarayıcıyı kullanmaktır. Tarayıcının kendi önbelleği araya girer ve yanlış sonuç görürsün. Ölçümü daima curl ile yap ve aynı adresi arka arkaya iki kez iste.
Dördüncü hata, purge'ü dağıtım sürecine bağlamamaktır. Yeni sürümü yayınlarsın, uç sunucular eski HTML'i dağıtmaya devam eder ve "değişiklik görünmüyor" telaşı başlar. Dağıtım betiğinin son adımı hedefli bir purge olmalıdır.
Beşinci hata, gri buluta alınmış bir kaydın önbelleklendiğini sanmaktır. DNS kaydı gri bulutta ise trafik Cloudflare'dan hiç geçmez, hiçbir cache kuralı çalışmaz. Hangi kaydın proxy'lendiğini Cloudflare DNS ve CDN yazısındaki mantıkla kontrol et.
Sıkça Sorulan Sorular#
Cloudflare HTML sayfalarımı neden önbelleğe almıyor#
Çünkü varsayılan davranış budur. Cloudflare yalnızca statik uzantılı dosyaları kendiliğinden önbelleğe alır; HTML bu listede yoktur çünkü sayfaların kişiye özel olup olmadığını bilemez. HTML'i önbelleğe almak için açıkça bir Cache Rule yazman ve o kuralda önbelleklenmemesi gereken yolları dışarıda bırakman gerekir.
Cache Rules ile Page Rules arasındaki fark nedir#
Page Rules eski nesil, tek bir URL kalıbına göre çalışan basit kurallardı ve sayıları sınırlıydı. Cache Rules ise ifade tabanlıdır; yol, başlık, çerez, istek yöntemi gibi onlarca alanı birleştirerek çok daha hassas eşleşme yazabilirsin. Yeni yapılandırmalarda Cache Rules kullanmalısın, mevcut Page Rules varsa zamanla taşımanı öneririm.
Önbelleği temizlemek sitemi yavaşlatır mı#
Kısa süreliğine evet. "Purge everything" dediğinde tüm uç kopyalar silinir ve o andan itibaren gelen her istek origin'e gider. Yoğun trafikli bir sitede bu, sunucuda ani bir yük dalgası yaratır. Bu yüzden mümkün olduğunca tek URL veya önek bazlı temizleme kullan, tam temizlemeyi düşük trafikli saatlere bırak.
cf-cache-status DYNAMIC yazıyorsa ne yapmalıyım#
DYNAMIC, isteğin önbelleklenebilir kabul edilmediği anlamına gelir. Önce origin'in gönderdiği Cache-Control ve Set-Cookie başlıklarını kontrol et; no-store veya çerez varsa önce onları düzelt. Sonra ilgili yol için bir Cache Rule yazıp "Eligible for cache" seçeneğini işaretle. İki adımı da yaptıysan durum MISS, ardından HIT olmalıdır.
WooCommerce veya üyelikli sitede önbellekleme güvenli mi#
Doğru istisnalarla evet. Sepet, ödeme, hesap ve yönetim yollarını önbelleğe hiç almamalı, oturum çerezi taşıyan istekleri de bypass etmelisin. Bu iki kuralı kurduktan sonra anonim ziyaretçilerin gördüğü kategori ve ürün listeleme sayfalarını güvenle önbelleğe alabilirsin. Canlıya almadan önce ikinci bir tarayıcıda oturum açıp sepetin karışmadığını mutlaka doğrula.
Ücretsiz planda hangi cache özellikleri var#
Ücretsiz planda temel Cache Rules, Edge ve Browser TTL ayarları, tek URL ve tam önbellek temizleme bulunur. Cache key'in ileri düzey özelleştirilmesi, önek ve etiket bazlı temizleme, katmanlı önbellek gibi özellikler üst planlara aittir. Küçük ve orta ölçekli siteler için ücretsiz plandaki kurallar genellikle fazlasıyla yeterlidir.
Kapanış#
Cloudflare'ın önbelleği güçlüdür ama varsayılan hâliyle sitenin ağır kısmına, yani HTML'e hiç dokunmaz. İşin özü dört alışkanlıkta toplanıyor: cf-cache-status başlığını okumayı alışkanlık hâline getir, geniş önbellek kurallarını her zaman istisnalarla birlikte yaz, Edge TTL'i uzun Browser TTL'i kısa tut, dağıtım sürecinin son adımına hedefli bir purge koy. Bu dördü yerine oturduğunda hem sunucun rahatlar hem de sayfa açılış süren belirgin biçimde düşer.
Origin tarafını da hızlandırmak istersen sunucu seviyesinde önbellekleme büyük fark yaratır: Nginx FastCGI cache veya LiteSpeed Cache yazılarımız iyi bir başlangıç. Barındırma tarafında hız arıyorsan WordPress hosting ve e-ticaret hosting paketlerimize, tam kontrol istiyorsan VDS sunucularımıza göz atabilirsin. Saldırı trafiğini uç katmanda durdurmak istersen DDoS koruma hizmetimiz bu yükü senin yerine üstlenir.