CDN

CDN nedir?

“Cache stores copies of frequently accessed content (such as images, videos, or webpages) in geographically distributed data centers that are located closer to end users than origin servers, reducing server load and improving website performance.”

Ürün sayfasındaki tanım daha somut:

“Cloudflare’s CDN caches your static and dynamic content in data centers in over 335+ cities worldwide, serving it directly from the edge to accelerate content delivery and absorb traffic from your origin servers.”

“Unlike traditional CDNs that require changing URLs, Cloudflare works as a reverse proxy. Just by switching your DNS, your site is faster.”

Nasıl çalışır?

Varsayılan cache kararı

Cloudflare cache’lemez ise:

• Cache-Control başlığı private, no-store, no-cache veya max-age=0 ise
• Set-Cookie başlığı varsa
• HTTP metodu GET dışında bir şeyse

Cloudflare cache’ler ise:

• Cache-Control public ve max-age sıfırdan büyükse
• Expires gelecekte bir tarihe ayarlıysa

Ve bir de: “Cloudflare does cache the resource even if there is no Cache-Control header based on status codes.” İkisi birden varsa max-age kazanır.

Varsayılan cache’lenen uzantılar

“Cloudflare only caches based on file extension and not by MIME type. The Cloudflare CDN does not cache HTML or JSON by default.”

Liste: 7z avi avif apk bin bmp bz2 class css csv doc docx dmg ejs eot eps exe flac gif gz ico iso jar jpg jpeg js mid midi mkv mp3 mp4 ogg otf pdf pict pls png ppt pptx ps rar svg svgz swf tar tif tiff ttf webm webp woff woff2 xls xlsx zip zst

Ayrıca robots.txt varsayılan olarak cache’leniyor.

Durum koduna göre varsayılan Edge TTL

Origin cache-control veya expires göndermediğinde:

“All other status codes are not cached by default.”

İstek birleştirme — az bilinen gerçek bir avantaj

“When multiple requests arrive simultaneously at a single Cloudflare data center for the same asset that is not in cache (a cache miss), Cloudflare uses a cache lock to avoid sending duplicate requests to your origin. Only the first request is forwarded to the origin to fetch the asset. The remaining requests wait for the first request to complete, after which the response is streamed to all waiting requests.”

Bu, viral bir içerikte origin’ini koruyan mekanizmadır ve çoğu karşılaştırmada bahsedilmez.

Cache anahtarı ve içindeki tuzak

Varsayılan cache anahtarı şunları içerir: tam URL (şema + host + query string dahil URI), CORS için Origin başlığı, x-http-method-override ailesi ve x-forwarded-host ailesi.

Özel anahtara koyamayacağın başlıklar: connection, content-length, cache-control, if-match, if-modified-since, if-none-match, if-unmodified-since, range, upgrade, ayrıca cookie ve host, ve cf- ile başlayan her şey. Origin başlığı ise “always included unless explicitly excluded. Including the Origin header in the Cache Key is important to enforce CORS.”

Cloudflare’in kendi uyarısı: özel anahtarlar “may reduce your cache hit rate and result in cache sharding.”

Tiered Cache — dört topoloji

“Tiered Cache works by dividing Cloudflare’s data centers into a hierarchy of lower-tiers and upper-tiers… If the upper-tier does not have the content, only the upper-tier can ask the origin for content. This practice improves bandwidth efficiency by limiting the number of data centers that can ask the origin for content.”

Bir yan fayda daha: “Tiered Cache concentrates connections to origin servers so they come from a small number of data centers rather than the full set of network locations. This results in fewer open connections using server resources.”

cf-cache-status — dokuz değerin tamamı

Bu tablo, CDN hata ayıklamanın merkezidir.

NONE/UNKNOWN’ın dört belgelenmiş sebebi var ve ilk ikisi Workers kullananlar için kritik: bir Worker alt istek yapmadan yanıt ürettiyse; bir Worker alt istek (fetch) yaptıysa — bu durumda alt istek cache durumuyla loglanır, ana istek none/unknown olur, çünkü “Workers sits in front of cache”; bir WAF custom rule isteği engellediyse; bir redirect rule veya Always Use HTTPS yönlendirme ürettiyse.

BYPASS’ın tam sebep listesi — bu senin kontrol listen:

• Yanıt planın maksimum cache’lenebilir dosya boyutunu aşıyor
• Origin Cloudflare-CDN-Cache-Control veya CDN-Cache-Control içinde no-store ya da yalın private döndürdü. Öncelik sırası: Cloudflare-CDN-Cache-Control > CDN-Cache-Control > Cache-Control — yani origin Cache-Control: public, max-age=3600 ile birlikte CDN-Cache-Control: no-store gönderirse sonuç BYPASS olur
• Origin Cache-Control: no-store veya private döndürdü
• Origin Set-Cookie döndürdü
• Origin Vary: * döndürdü — bu her zaman cache’i atlar
• İstek Authorization başlığı içeriyordu ve Origin Cache Control açıktı (Free, Pro ve Business’ta varsayılan)

Age başlığının kuralları da net: Cloudflare Age’i yalnızca HIT, STALE ve UPDATING yanıtlarına koyuyor. MISS, DYNAMIC, BYPASS ve NONE/UNKNOWN’a koymuyor. Ama bir istisna var: “If the origin sets Age on an uncacheable response, that value is proxied to the client unchanged — a DYNAMIC or BYPASS response can carry an Age that came from the origin, not from Cloudflare.” Ve Tiered Cache açıkken “a HIT served locally can carry an Age inherited from an upper tier, so the value can be older than the last local fill.”

Cache Rules ve eski Page Rules

Edge TTL modları: respect_origin (origin başlığı varsa onu kullan), override_origin (başlığı yok say, bu TTL’i kullan), bypass_by_default (başlık varsa kullan, yoksa cache’i atla). Durum kodu TTL’lerinde 0 = no-cache, -1 = no-store.

Enterprise’a özel Cache Rules ayarları: Caching on Port, Proxy Read Timeout, Origin Cache Control.

stale-while-revalidate

“Revalidation is fully asynchronous. When a cached asset expires and stale-while-revalidate is set, the first request that arrives after expiry triggers revalidation in the background. That request immediately receives stale content with an UPDATING status instead of blocking until the origin responds.”

SWR’ı sessizce öldüren dört direktif var ve bunlar sık birlikte gönderiliyor:

• must-revalidate — bayat içerik sunmayı yasaklar
• proxy-revalidate — aynısı, yalnızca paylaşımlı cache’ler için
• s-maxage — proxy-revalidate semantiği ima eder, yani bayat sunulamaz
• no-cache — her yanıttan önce doğrulama ister

“If any of these directives are present alongside stale-while-revalidate, Cloudflare will not serve stale content — requests will return EXPIRED instead of UPDATING.”

Cloudflare’in kendi önerdiği çözüm: “If you need stale-while-revalidate behavior with a different TTL for Cloudflare than for browsers, do not use s-maxage. Instead, configure your origin to send max-age with stale-while-revalidate, then use Edge Cache TTL in Cache Rules to set a separate TTL for Cloudflare.”

stale-if-error yalnızca 5xx kodlarında devreye giriyor — 404 bu amaçla hata sayılmıyor ve hangi kodların tetikleyeceği özelleştirilemiyor. Always Online açıksa ikisi de yok sayılıyor.

Ne zaman kullanılır, ne zaman kullanılmaz

Kullanılır

Statik varlıkların, ürün görsellerinin, indirilebilir belgelerin varsa; origin’in uzaktaysa ve kullanıcıların dağınıksa; origin yükünü düşürmek istiyorsan. Ücretsiz planda bile bant genişliği ölçülmüyor ve Tiered Cache dahil.

Kullanılmaz

512 MB’tan büyük dosya sunacaksan. Free, Pro ve Business’ta cache’lenebilir dosya sınırı 512 MB; Enterprise varsayılanı 5 GB. Kurulum dosyası, oyun yaması, ISO veya uzun video dağıtıyorsan self-servis katmanlar yapısal olarak yanlış araç.

Video veya orantısız oranda büyük dosya sunacaksan. Bu bir folklor değil, yürürlükteki sözleşme maddesi — ayrıntı Lisanslama bölümünde.

Özel cache anahtarı gerekiyorsa. Query string, Headers, Cookie, Host ve User features ayarlarının hepsi yalnızca Enterprise. Fastly, VCL seviyesinde req.hash kontrolünü satış görüşmesi olmayan bir hesapta veriyor. Bu, ileri seviye ekipler için Cloudflare’in Fastly karşısındaki en büyük yetenek açığı.

Gerçek bir edge yapılandırma dili istiyorsan. Cache Rules bildirimsel ve sabit bir ayar kümesiyle sınırlı. Fastly’nin VCL’i ve Akamai’nin Property Manager + EdgeWorkers ikilisi belirgin şekilde daha ifade gücü yüksek. Cloudflare’in cevabı Workers — farklı ve daha pahalı bir programlama modeli, üstelik Workers cache’in önünde olduğu için cache durumu semantiğini değiştiriyor.

Origin Cache Control’ü kapatman gerekiyorsa. Free, Pro ve Business’ta varsayılan açık ve kapatılamıyor.

Pro planda 5 dakikalık Edge TTL gerekiyorsa. Free’de taban 2 saat, Pro’da 1 saat.

Cache Analytics’e ihtiyacın varsa ve Free’desin. Ücretsiz planda hiç yok. Pro’da 7 gün saklama.

Yoğun purge yapan bir yayın platformuysan. Free’de dakikada 5 istek. Pro 5/sn, Business 10/sn, Enterprise 50/sn.

Küresel kitlen ve tek bölgeli origin’in varsa. Tam da bu duruma yarayan Regional ve Generic Global topolojiler yalnızca Enterprise — ki bu, origin’i İstanbul veya Frankfurt’ta olan Türk şirketlerinin yaygın durumu.

Vary başlığına güveniyorsan. Varsayılan olarak yok sayılıyor; açıkça devreye alman gerekiyor.

Somut örnekler

Anonim ziyaretçiye HTML cache’le, oturum açmışa bypass et

{
  "rules": [
    {
      "expression": "(http.cookie contains \"session=\" or starts_with(http.request.uri.path, \"/admin\"))",
      "description": "oturum acmis kullaniciya asla cache'leme",
      "action": "set_cache_settings",
      "action_parameters": { "cache": false }
    },
    {
      "expression": "(http.host eq \"ornek.com.tr\")",
      "description": "anonim HTML, kisa edge TTL",
      "action": "set_cache_settings",
      "action_parameters": {
        "cache": true,
        "edge_ttl":    { "mode": "override_origin", "default": 300 },
        "browser_ttl": { "mode": "bypass_by_default" }
      }
    }
  ]
}

Hash’li build varlıkları — bir yıl cache

{
  "expression": "(http.request.uri.path matches \"^/assets/.*\\\\.[a-f0-9]{8,}\\\\.(js|css|woff2)$\")",
  "action": "set_cache_settings",
  "action_parameters": {
    "cache": true,
    "edge_ttl":    { "mode": "override_origin", "default": 31536000 },
    "browser_ttl": { "mode": "override_origin", "default": 31536000 },
    "respect_strong_etags": true
  }
}

Pazarlama parametrelerini cache anahtarından atmak (Enterprise)

"action_parameters": {
  "cache": true,
  "cache_key": {
    "ignore_query_strings_order": true,
    "custom_key": {
      "query_string": {
        "exclude": ["utm_source","utm_medium","utm_campaign","utm_term","utm_content","fbclid","gclid"]
      }
    }
  }
}

Gerçek dünyada düşük cache hit oranının bir numaralı sebebi budur. Enterprise değilsen alternatif: Cache Rules → Cache Key → Ignore query string.

Durum koduna göre TTL — origin hatası cache’te kalmasın

"edge_ttl": {
  "mode": "respect_origin",
  "status_code_ttl": [
    { "status_code_range": { "to": 299 },              "value": 86400 },
    { "status_code_range": { "from": 300, "to": 499 }, "value": 0 },
    { "status_code_range": { "from": 500 },            "value": -1 }
  ]
}

Cloudflare’in kendi notasyonu: 0 = no-cache, -1 = no-store.

Origin tarafında cache tag’i ile cerrahi geçersiz kılma

Origin Cache-Tag: urun-4821,kategori-ayakkabi,marka-nike gönderir, sonra:

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"tags":["marka-nike"]}'

Tek bir markanın tüm ürün sayfaları geçersiz olur, gerisi cache’te kalır.

Cache Reserve’ü yalnızca büyük ve nadiren değişen nesneler için

"action_parameters": {
  "cache": true,
  "cache_reserve": { "eligible": true, "minimum_file_size": 104857600 }
}

Demo 1: Cache hit oranını ölçmek, düzeltmek ve tekrar ölçmek

Bu demonun kuralı şu: önce ölç, sonra değiştir, sonra tekrar ölç. Aksi halde iyileştirdiğini kanıtlayamazsın.

Adım 1 — On URL’yi sınıflandır

Her URL’ye iki kez vur; ikinci istek kararlı durumu gösterir.

while read u; do
  curl -sSI "$u" -o /dev/null -D /tmp/h1
  curl -sSI "$u" -o /dev/null -D /tmp/h2
  printf "%-45s 1.=%-10s 2.=%-10s yas=%-6s ray=%s\n" "$u" \
    "$(grep -i '^cf-cache-status' /tmp/h1 | tr -d '\r' | awk '{print $2}')" \
    "$(grep -i '^cf-cache-status' /tmp/h2 | tr -d '\r' | awk '{print $2}')" \
    "$(grep -i '^age:'            /tmp/h2 | tr -d '\r' | awk '{print $2}')" \
    "$(grep -i '^cf-ray'          /tmp/h2 | tr -d '\r' | awk '{print $2}')"
done < urls.txt

Beklenen “kötü” başlangıç:

https://ornek.com.tr/                 1.=DYNAMIC   2.=DYNAMIC   yas=      ray=...-IST
https://ornek.com.tr/urunler          1.=DYNAMIC   2.=DYNAMIC   yas=      ray=...-IST
https://ornek.com.tr/assets/app.css   1.=MISS      2.=HIT       yas=12    ray=...-IST

Döngünün çıktısı; HTML sayfalarında DYNAMIC, statik varlıklarda MISS→HIT geçişi ve cf-ray'in son üç karakteri

DYNAMIC okuması net: “cache’lenmeye uygun değil, cache’e bakılmadı bile” — çünkü HTML varsayılan uzantı listesinde yok.

Adım 2 — Query string parçalanmasını kanıtla

curl -sSI "https://ornek.com.tr/assets/app.css"                     | grep -i cf-cache-status
curl -sSI "https://ornek.com.tr/assets/app.css?utm_source=twitter"  | grep -i cf-cache-status
curl -sSI "https://ornek.com.tr/assets/app.css?utm_source=twitter"  | grep -i cf-cache-status
curl -sSI "https://ornek.com.tr/assets/app.css?utm_source=linkedin" | grep -i cf-cache-status

Dört curl çıktısı; sırayla HIT, MISS, HIT, MISS — her benzersiz query string ayrı cache kaydı

Adım 3 — Başlangıç hit oranını GraphQL ile ölç

echo '{ "query":
"{ viewer { zones(filter: {zoneTag: \"'$ZONE_ID'\"}) {
    httpRequestsAdaptiveGroups(limit: 20,
      filter: { datetime_geq: \"2026-08-31T00:00:00Z\", datetime_lt: \"2026-09-01T00:00:00Z\" }
    ) { count sum { edgeResponseBytes } dimensions { cacheStatus } }
} } }" }' | tr -d '\n' | curl -s https://api.cloudflare.com/client/v4/graphql \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  --header "Content-Type: application/json" --data @- | python3 -m json.tool

GraphQL yanıtı; cacheStatus boyutuna göre istek sayıları — hit, miss, dynamic dağılımı

Pro ve üstündeysen panelde de bak:

Caching → Overview → Cache Analytics; Served by Cloudflare ve Served by Origin oranı, Dynamic dilimi

Cloudflare’in kendi tanı reçetesi de bu: “Not caching HTML. Identify the issue: Select Add filter and select Cache status equals Dynamic.”

Adım 4 — Üç kuralı yayına al

Yukarıdaki “Somut örnekler” bölümündeki üç kuralı sırayla uygula: kimlik doğrulamalı trafiği bypass et, statik varlıkları uzun TTL ile ve utm_* atılmış anahtarla cache’le, anonim HTML’i kısa TTL ile cache’le.

Caching → Cache Rules ekranı veya API yanıtı; üç kuralın sırası ve ifadeleri

Adım 5 — Kuralın gerçekten çalıştığını Trace ile doğrula

Panelde Rules → Trace ile bir URL’yi izle.

Trace çıktısındaki Cache Parameters bölümü ve View parameter detail ile açılan cache anahtarı bileşenleri

Bu adım, “kural yazdım ama çalışmıyor” döngüsünü kısaltıyor — hangi kuralın eşleştiğini ve hangi cache anahtarı bileşenlerinin kullanıldığını doğrudan gösteriyor.

Adım 6 — Purge et ve yeniden ölç

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"purge_everything":true}'
sleep 20
# Adım 1 ve 2'deki döngüleri aynen tekrarla

Aynı döngünün yeni çıktısı; HTML'de artık MISS→HIT, utm'li isteklerde dört HIT — adım 1 ve 2 ile yan yana karşılaştırılabilir olmalı

Cache Analytics ekranı; Served by Cloudflare payının arttığı ve Dynamic diliminin küçüldüğü, adım 3 ile karşılaştırmalı

Bu demoda ölçülenler: URL bazında cache durumu (önce/sonra) · utm parçalanmasının kaybolması · GraphQL’den hesaplanan hit oranı farkı · panelde Served by Cloudflare payı · origin erişim log’undaki istek sayısı.

Demo 2: Tag ile purge’ü kanıtlamak ve Tiered Cache’i origin’de saymak

İki bağımsız kanıt, tek oturumda.

Bölüm A — Tag ile purge

Adım 1 — Origin’den tag gönder ve doğrudan doğrula

location /urunler/ {
    add_header Cache-Tag "urun-$arg_id,kategori-ayakkabi,marka-nike" always;
    add_header Cache-Control "public, max-age=3600, stale-while-revalidate=600" always;
}

curl -sSI --resolve ornek.com.tr:443:203.0.113.10 https://ornek.com.tr/urunler/?id=4821 \
  | grep -iE 'cache-tag|cache-control'

Cloudflare'i atlayarak doğrudan origin'e yapılan curl çıktısı; cache-tag ve cache-control başlıkları görünüyor

Adım 2 — Cloudflare’in tag’i sildiğini doğrula

curl -sSI https://ornek.com.tr/urunler/?id=4821 | grep -i 'cache-tag'
# Hiçbir şey dönmemeli

curl çıktısında cache-tag başlığının bulunmadığı — bu, çalıştığının kanıtı

Adım 3 — Cache’i ısıt, tek tag’i purge et, kontrol grubuyla karşılaştır

# Üç ürünü ısıt, hepsi HIT olmalı
for id in 4821 4822 4823; do
  curl -sSI "https://ornek.com.tr/urunler/?id=$id" -o /dev/null
  echo "id=$id $(curl -sSI "https://ornek.com.tr/urunler/?id=$id" | grep -i cf-cache-status | tr -d '\r')"
done

# Yalnızca bir tag'i purge et
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"tags":["marka-nike"]}'

sleep 5
for id in 4821 4822 4823; do
  echo "id=$id $(curl -sSI "https://ornek.com.tr/urunler/?id=$id" | grep -i cf-cache-status | tr -d '\r')"
done
# Kontrol grubu: tag'siz bir sayfa
curl -sSI "https://ornek.com.tr/hakkimizda" | grep -i cf-cache-status

Purge öncesi üç HIT, purge sonrası üç MISS, ve tag'siz kontrol sayfasının hâlâ HIT olduğu çıktı

Kontrast kanıttır: etiketli üç URL MISS’e döner, etiketsiz kontrol sayfası HIT kalır. Tiered Cache açıksa MISS yerine EXPIRED görürsün — bu da belgeli.

Adım 4 — Purge everything’in farklı davrandığını göster

purge_everything sonrası aynı URL'nin MISS değil EXPIRED döndüğü çıktı

Adım 5 — Rate limit duvarına bilerek çarp

Ücretsiz planda dakikada 5 istek, kova 25:

for i in $(seq 1 30); do
  code=$(curl -s -o /dev/null -w '%{http_code}' \
    "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" --request POST \
    --header "Authorization: Bearer $CF_API_TOKEN" --json '{"tags":["marka-nike"]}')
  echo "$i -> $code"
done

30 çağrılık döngünün çıktısı; ilk ~25'inin başarılı olduğu, sonra kısıtlamaya takıldığı

Belgelenen token bucket modeli tam olarak bunu öngörüyor.

Bölüm B — Tiered Cache’i origin’de saymak

Bu, yalnızca kendi sunucundan kanıtlanabilecek olan.

Adım 6 — Origin’i işaretle

log_format cftrace '$time_iso8601 $remote_addr "$request" $status ray="$http_cf_ray"';
access_log /var/log/nginx/cftrace.log cftrace;

Sana getiren veri merkezi, cf-ray’in son üç karakteridir.

Adım 7 — Tiered Cache KAPALI iken ölç

curl ".../zones/$ZONE_ID/argo/tiered_caching" --request PATCH \
  --header "Authorization: Bearer $CF_API_TOKEN" --json '{"value":"off"}'
curl ".../zones/$ZONE_ID/purge_cache" --request POST \
  --header "Authorization: Bearer $CF_API_TOKEN" --json '{"purge_everything":true}'
: > /var/log/nginx/cftrace.log

Şimdi coğrafi olarak farklı yerlerden trafik üret — demonun püf noktası bu, çünkü Tiered Cache’in tüm amacı veri merkezleri arasında ne olduğu. Farklı bölgelerdeki birkaç ucuz VPS yeterli.

awk -F'ray="' '{split($2,a,"\""); n=split(a[1],b,"-"); print b[n]}' /var/log/nginx/cftrace.log \
  | sort | uniq -c | sort -rn
echo "TOPLAM ORIGIN İSTEĞİ: $(grep -c 'buyuk.jpg' /var/log/nginx/cftrace.log)"

awk çıktısı; her farklı Cloudflare veri merkezinden ayrı bir origin isteği geldiğini gösteren liste ve toplam sayı

Adım 8 — Smart Tiered Cache’i aç ve aynı trafiği tekrarla

curl ".../zones/$ZONE_ID/argo/tiered_caching" --request PATCH \
  --header "Authorization: Bearer $CF_API_TOKEN" --json '{"value":"on"}'
curl ".../zones/$ZONE_ID/cache/tiered_cache_smart_topology_enable" --request PATCH \
  --header "Authorization: Bearer $CF_API_TOKEN" --json '{"value":"on"}'

# Origin AWS/GCP/Azure/OCI'daysa region hint ŞART:
curl ".../zones/$ZONE_ID/cache/origin_cloud_regions" --request PATCH \
  --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"ip":"203.0.113.10","vendor":"aws","region":"eu-central-1"}'

Aynı awk çıktısı; bu kez tek bir veri merkezinden tek bir origin isteği — adım 7 ile yan yana karşılaştırılabilir olmalı

Bu tek sayı — örneğin 9’dan 1’e düşüş — demonun kendisidir. Belgelenen mekanizma tam olarak budur: “only the upper-tier can ask the origin for content.”

On-prem sunucudaki toplam gönderilen byte karşılaştırması; Tiered Cache açıldıktan sonraki düşüş

Bu demoda ölçülenler: tag purge’ünden etkilenen ve etkilenmeyen URL’ler · purge everything ile tag purge’ün durum kodu farkı · purge rate limitinin devreye girdiği istek sayısı · Tiered Cache kapalı ve açıkken origin’e ulaşan farklı veri merkezi sayısı · toplam origin isteği ve bant genişliği farkı.

Fiyatlandırma

Plan fiyatları

Boyut ve kota sınırları

Purge limitleri — hesap başına, aynı plandaki zone’lar arasında paylaşılır

Hostname / tag / prefix / everything:

Tek dosya (URL) purge:

Cache anahtarı özellik kapıları

Cache Analytics

Cache Reserve fiyatı

Cloudflare’in kendi iki örneği:

• Örnek 1: 1.000 adet 1 GB’lık varlık, her biri ayda 1.000 kez okunuyor → toplam $19.86
• Örnek 2: 1.000.000 adet 1 MB’lık varlık, günde bir kez yeniden yazılıyor, günde iki kez okunuyor → toplam $171.60 (bunun $135’i yazma işlemleri)

Eklentiler

Tiered Cache ücretsizdir ve dört planda da mevcuttur.

Lisanslama ve hukuki çerçeve

Bu bölüm, bu sayfadaki en önemli bilgiyi taşıyor.

“Hizmet Şartları 2.8” artık yok

Türkçe ve İngilizce kaynakların yıllardır atıf yaptığı madde, bulunduğu belgeden kaldırıldı.

Güncel Self-Serve Subscription Agreement (cloudflare.com/terms/, son güncelleme 12 Eylül 2025) 2. bölümü şöyle ilerliyor: 2.1 Access to Services · 2.2 Use of Services · 2.3 Credentials · 2.4 Subscription Terms · 2.5 Customer Content and Network Data · 2.6 Free & Trial Services · 2.7 Acceptable Use — ve doğrudan 3. bölüme geçiyor.

2.8 diye bir bölüm yok. “Limitation on Serving Non-HTML Content” diye bir başlık yok. “non-HTML” ifadesi sözleşmede hiç geçmiyor.

Kısıt kaldırılmadı, taşındı

Madde şimdi Service-Specific Terms içinde, Application Services sekmesinde, “Content Delivery Network (Free, Pro, or Business)” başlığı altında. Üst sayfa 2 Haziran 2026 tarihli.

Tam metin:

“Cloudflare’s content delivery network (the “CDN”) Service can be used to cache and serve web pages and websites. Unless you are an Enterprise customer, Cloudflare offers specific Paid Services (e.g., the Developer Platform, Images, and Stream) that you must use in order to serve video and other large files via the CDN. Cloudflare reserves the right to disable or limit your access to or use of the CDN, or to limit your End Users’ access to certain of your resources through the CDN, if you use or are suspected of using the CDN without such Paid Services to serve video or a disproportionate percentage of pictures, audio files, or other large files. We will use reasonable efforts to provide you with notice of such action.”

Maddeyi satır satır okumak

Yasak olan: Free, Pro veya Business planında, ilgili ücretli ürünü (Stream, Images, Developer Platform) almadan video veya “orantısız oranda görsel, ses dosyası veya diğer büyük dosyalar” sunmak.

Muaf olan: “Unless you are an Enterprise customer” — madde Enterprise’ı bağlamıyor.

“Orantısız” tanımsız. Eşik yok, GB/ay rakamı yok, yüzde yok. Tamamen takdire bağlı.

Yaptırım fatura değil, kesinti. “disable or limit your access to or use of the CDN.” Aşım ücreti ödemezsin — kısıtlanır veya kapatılırsın.

Bildirim yalnızca makul çaba: “We will use reasonable efforts to provide you with notice.”

Türkiye ve veri yerelliği

Türkiye, Data Localization Suite’te Regional Services bölgesi olarak destekleniyor:

“Turkey — Cloudflare will only use data centers that are physically located within Turkey to decrypt and service HTTPS traffic.”

Ve cache bu kapsamın içinde — dokümanlar bölgeye hapsedilen işlemler arasında “Storing and retrieving content from Cache” ifadesini WAF, Bot Management, Workers ve Load Balancing ile birlikte sayıyor.

Radar verisi kullanacaksan lisansa dikkat: Radar API verisi CC BY-NC 4.0 ile sunuluyor — atıf zorunlu, ticari kullanım yasak. Ticari bir raporda Radar rakamı yayımlayacaksan bu madde seni bağlar.

Sık yapılan hatalar

Page Rules’tan Cache Rules’a iki kurallı koruma olmadan geçmek. “Eligible for cache” artık varsayılan olarak Cache Everything anlamına geliyor; insanlar kazara tüm kimlik doğrulamalı sitelerini cache’liyor.

Oturum açmış trafiği hariç tutmadan HTML cache’lemek. Cloudflare’in kendi uyarısı: “visitors may receive information not intended for them.”

SSL modunu değiştirip tüm cache’i uçurmak. Flexible → Full origin şemasını değiştiriyor ve o şema varsayılan cache anahtarında.

s-maxage ile stale-while-revalidate’i birlikte göndermek ve SWR’ın neden çalışmadığını merak etmek. s-maxage proxy-revalidate ima ediyor ve bayat sunumu öldürüyor.

Ondalıklı max-age=2.5 göndermek. “not valid and will be ignored, potentially causing cache bypass.”

CDN-Cache-Control: no-store ile Cache-Control: public, max-age=3600’ı birlikte göndermek. Sonuç BYPASS ve Cloudflare-CDN-Cache-Control istemciye iletilmediği için curl -I ile göremiyorsun.

Özel cache anahtarıyla cache’lenmiş bir nesneyi tek dosya purge ile temizlemeye çalışmak. Panel gerekli başlıkları sağlayamıyor; API ile eşleşen başlıkları göndermen ya da prefix/tag/host purge kullanman gerekiyor.

Yalnızca GET eşleştiren bir Cache Rule yazmak. Purge istekleri farklı bir iç metot kullanıyor; ifadeye or http.request.method eq "PURGE" eklenmeli.

Transform Rule URL yönünü ters yapmak. Tek dosya purge dönüştürülmemiş (son kullanıcı) URL ister; prefix purge dönüştürülmüş (origin) URL ister. Birbirinin tersi.

Content-Length’i korumak için cache-control: no-transform eklemek ve sonra Cache Reserve’ün nesneyi neden almadığını merak etmek. Cache Reserve Content-Length gerektiriyor, ama no-transform sıkıştırmayı da engelliyor.

Cache Reserve’ü Tiered Cache olmadan açmak. Belgelenmiş maliyet tuzağı.

Kimlik doğrulamalı bir sitede Early Hints açmak. Kimliği doğrulanmamış ziyaretçiler, 403 öncesinde cache’lenmiş Link başlıkları taşıyan bir 103 alabiliyor.

İki MISS’i sorun kanıtı saymak. Farklı veri merkezlerinden gelmiş olabilir; cf-ray’in son üç karakterini karşılaştır.

Tiered Cache açıkken Age’i yerel tazelik kanıtı saymak. Üst katmandan miras alınmış olabilir.

Smart Tiered Cache açıkken origin IP’sini değiştirmek. Üst katman yeniden seçiliyor ve MISS oranı fırlıyor.

DNS-only bir kayıtta cache beklemek. Turuncu bulut yoksa CDN yok.

Workers’ın cache’in önünde olduğunu unutmak. Ana istek none/unknown loglanıyor; gerçek cache durumunu yalnızca alt istek taşıyor.