Cloudflare Workers ve BunnyCDN: Edge Kuralları

Cloudflare Workers ve BunnyCDN ile Edge Kuralları

Her istekte tekrarlanan URL eşleme, yönlendirme ve başlık işlemleri web sunucusunda (Nginx/Apache) veya uygulamada (örneğin PHP) yürütülebilir. CDN kullanan, trafiği coğrafi olarak dağılmış sitelerde bu işlerin bir kısmını origin’den ağın kenarına, yani edge’e taşımak merkezi yönetimi kolaylaştırabilir. TTFB (Time to First Byte) ve origin yükü üzerindeki etkisi ise isteğin hâlâ origin’e gidip gitmediğine ve taşınan işlemin maliyetine bağlıdır.

Cloudflare Workers programlanabilir bir çalışma ortamıdır; BunnyCDN Edge Rules ise önceden tanımlanmış koşul ve aksiyonları birleştirir. Yönlendirme, URL eşleme, başlık yönetimi ve bakım yanıtlarını hangi katmanda uygulayacağınız; istek akışına, önbelleğe ve güvenlik sınırlarına bağlıdır.

• Origin’e ulaşmadan yanıtlanan istekler origin yükünü azaltabilir; yalnızca başlık eklemek veya URL değiştirmek origin isteğini ortadan kaldırmaz.
• Origin’e gidişi önleyen işlemler TTFB’yi kısaltabilir; ek edge işlemlerinin toplam gecikmeye etkisi ölçülmelidir.
• Taşınan kuralları Nginx/Apache’den kaldırarak sunucu konfigürasyonunu sadeleştirebilirsiniz.
• Origin değişiminde kuralları koruyabilirsiniz; ancak CDN sağlayıcısını değiştirirken kuralların ve kodun uyarlanması gerekebilir.

Bu rehber, URL rewrite ile tarayıcı yönlendirmesini ayırır; çalışan Worker örneklerini, Bunny değişkenlerini ve güvenli dağıtım adımlarını açıklar. 4 Kasım 2026 güncellemesi: Bunny’nin güncel kural ve middleware belgeleri esas alınmıştır. Örnek alan adları size ait alanlarla değiştirilmelidir; iki CDN’yi peş peşe kullanmanız gerekmez.

Cloudflare Workers ve BunnyCDN Edge Rules Temel Farkları

Önce iki yapının ne olduğunu netleştirelim; çünkü mimariyi doğru kurmak için hangi iş yükünü nereye koymanız gerektiğini iyi bilmeniz gerekiyor.

Cloudflare Workers: Edge’de Gerçek Kod Çalıştırma

Cloudflare Workers, dağıtık altyapıda JavaScript veya TypeScript ile istek/yanıt mantığı çalıştırabilir. Aşağıdaki örnekler güncel ES module biçimini kullanır. Her kod bloğu ayrı bir örnektir; bir dosyada birden fazla export default birleştirmeyin.

• Programlanabilir mantık: Koşullu mantık, döngüler, harici API çağrıları, regex tabanlı routing, A/B test, hatta küçük API uçları bile yazabilirsiniz.
• Request/response işleme: Gelen isteği yakalar, URL’yi değiştirir, headere dokunur, gerekirse hiç origin’e gitmeden yanıt üretebilirsiniz.
• Dağıtık çalışır: Kodunuz dağıtık edge altyapısında çalışır; gecikme kazancı, isteğin izlediği yola ve origin’e ya da harici API’lere yapılan çağrılara bağlıdır.

Workers’ın farklı bir kullanım örneği için SPF flattening, CI/CD ve Cloudflare Workers yazımıza bakabilirsiniz.

BunnyCDN Edge Rules: Koşul + Aksiyon Motoru

BunnyCDN Edge Rules, kural tanımı içinde serbest JavaScript yazdığınız bir ortam değildir. Desteklenen aksiyonlar arasından seçim yaparsınız. Bunny’nin ayrıca programlanabilir Edge Scripting/Middleware ürünü vardır; aşağıdaki SPA örneği bu ayrı özelliği kullanır.

• HTTP→HTTPS için Force SSL ve URL taşımak için Redirect to URL
• Set Response Header / Set Request Header ile başlık yönetimi
• Override Cache Time ve Override Browser Cache Time ile ayrı süreler; Vary Cache ayarlarıyla desteklenen varyantlar
• Change Origin URL ile origin seçimi; bu bir tarayıcı yönlendirmesi değildir
• Ülke, istek yöntemi, URL veya başlık koşullarıyla kapsamlandırılmış erişim kuralları

Bu motoru Nginx yapılandırmasının bire bir karşılığı gibi düşünmeyin. Aksiyon isimleri, değişken sözdizimi ve hangi aşamada çalıştıkları ürüne özgüdür. Örneğin origin yönlendirmesi önbellek isabetinde çalışmaz; response header kuralları aynı akışta birden fazla kez uygulanabilir.

Origin’den Edge’e Taşınabilecek İşler

Her şeyi edge’e taşımak doğru değil; ama bazı kalıplar neredeyse her projede tekrar ediyor ve bunlar edge için biçilmiş kaftan:

1. URL Rewrite ve Routing

• Eski URL şemasından yeni yapıya kalıcı geçişlerde 301/308; geçici yönlendirmelerde 302/307
• Single Page Application (SPA) için istemci tarafında işlenen sayfa yollarını /index.html veya /app.html’e eşlemek; statik dosya ve API yollarını bu kuralın dışında tutmak
• Backend framework’ünüzün (Laravel, Symfony, Ruby vb.) URL yapısını sade göstermek için /urun/slug → /index.php?route=product&slug=slug gibi dönüşümler
• Coğrafi veya dil bazlı yönlendirme (tr.example.com, en.example.com vb.)

Rewrite, tarayıcının adresini değiştirmeden upstream isteğini değiştirir; redirect, 3xx ve Location ile tarayıcıya yeni bir istek yaptırır. Rewrite sonrası origin’e hâlâ gidilebilir. Kalıcı URL taşınmasını yalnızca içeride rewrite ederek tamamlamış saymayın.

2. Güvenlik Başlıkları

HTTP güvenlik başlıkları politika tanımlar; ancak doğru değerleri uygulamanın kaynakları, çerçeveleme ihtiyaçları ve HTTPS kapsamıyla uyumlu olmalıdır:

• Strict-Transport-Security (HSTS)
• Content-Security-Policy (CSP)
• X-Frame-Options
• X-Content-Type-Options
• Referrer-Policy
• Permissions-Policy

Bunları her sunucuda ayrı ayrı konfigüre etmek yerine, edge seviyesinde standartlaştırmak çoğu zaman daha sağlıklıdır. Detayları bizim HTTP güvenlik başlıkları rehberimizde uzun uzun anlattık; burada özellikle Workers ve Edge Rules üzerinden pratik örneklere odaklanacağız.

3. Basit Koşullu Mantık

İstekten karar verilebilen küçük işler edge için aday olabilir. Erişim yetkisi, durum tutma ve önbellek etkisini ayrıca tasarlayın:

• Kullanıcı tercihine saygılı bölge veya dil seçimi
• Bakım sırasında 503, Retry-After ve no-store ile kısa süreli yanıt
• Doğrudan origin erişimi de kapatılmış bir sistemde ek IP kısıtlaması
• Kararlı bir atama çerezi ve doğru önbellek ayrımıyla A/B testi; her istekte yeniden rastgele seçim yapmak oturumu tutarsızlaştırabilir

Bu tarz mantıklar Workers ile kod seviyesinde ele alınabilir. BunnyCDN Edge Rules seçeneği ise gereken koşul ve aksiyonların kural motorunda desteklenmesine bağlıdır; yalnızca mantığın basit olması yeterli değildir.

Cloudflare Workers ile URL Rewrite ve Güvenlik Başlıkları

Bu Worker örnekleri mevcut bir origin önünde Workers Route kullanır. Zone aktif olmalı, ilgili DNS kaydı Cloudflare üzerinden proxy edilmeli ve origin TLS bağlantısı doğrulanmalıdır. Workers Custom Domain veya workers.dev dağıtımının aynı proxy davranışını göstereceğini varsaymayın.

1. Test hostname’i ve ona ait Worker Route oluşturun; örneğin www.example.com/*.
2. Bir örneği modül olarak dağıtın. Route kapsamını gereksiz hostname ve uçlara genişletmeyin.
3. İstek değiştirilecekse özgün Request’ten yeni Request oluşturun. Örnekler upstream yönlendirmesini manual tutar; başka hosta otomatik takip sırasında Cookie/Authorization taşınmasını önler.
4. Origin yanıtı, önbellek ve son kullanıcıya çıkan durumu birlikte inceleyin.

Workers ile Basit URL Rewrite Örneği

Örnek yalnızca GET/HEAD ile gelen, www.example.com/blog/yeni-urunler biçimindeki küçük harfli ASCII slug’ları /index.php?route=blog&slug=yeni-urunler biçimine eşler. Sondaki tek eğik çizgi kabul edilir. Blog kökü, çok seviyeli yollar, farklı hostname ve diğer HTTP yöntemleri değiştirilmez. PHP uygulaması bu parametre sözleşmesini desteklemelidir.

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const pageMethod = request.method === 'GET' || request.method === 'HEAD';
    const match = url.pathname.match(/^\/blog\/([a-z0-9]+(?:-[a-z0-9]+)*)\/?$/);
    if (url.hostname === 'www.example.com' && pageMethod && match) {
      url.pathname = '/index.php';
      url.searchParams.set('route', 'blog');
      url.searchParams.set('slug', match[1]);
    }
    const upstream = new Request(url.toString(), new Request(request, {
      redirect: 'manual'
    }));
    return fetch(upstream);
  }
};

İstek üzerindeki diğer query parametreleri korunur; route ve slug eşlemenin değerleriyle değiştirilir. Bu örnek cache’i zorlamaz. Dinamik veya kişisel içerik için origin no-store/private politikasını ve CDN bypass kurallarını ayrıca doğrulayın.

• Tarayıcı adresinde temiz URL kalır; 301 gönderilmez.
• Origin bu özel eşleme için ayrı rewrite kuralı gerektirmeyebilir; uygulama routing’i yine çalışır.
• Gelecekte yalnızca origin’in URL eşlemesi değişirse Worker’daki mapping’i güncelleyebilirsiniz; platform değişiminin diğer gereksinimleri ayrıca ele alınmalıdır.

Workers ile Güvenlik Başlıkları Ekleme

Aşağıdaki ayrı Worker, HTTP yanıtını kopyalar ve mevcut başlıkları koruyarak eksik değerler ekler. HTML’in yalnızca aynı origin içinde çerçevelenmesinin uygulamanız için doğru olduğunu önceden doğrulayın; farklı sitelerde gömme gerekiyorsa bu örneği uyarlayın. HSTS yalnız HTTPS yanıtına, kısa başlangıç süresiyle eklenir. Bu örnek WebSocket proxy’si için kullanılmaz.

export default {
  async fetch(request) {
    if (request.headers.has('Upgrade')) return fetch(request);
    const response = await fetch(new Request(request, { redirect: 'manual' }));
    const result = new Response(response.body, response);
    const headers = result.headers;
    if (new URL(request.url).protocol === 'https:' &&
        !headers.has('Strict-Transport-Security')) {
      headers.set('Strict-Transport-Security', 'max-age=300');
    }
    if ((headers.get('Content-Type') || '').toLowerCase().includes('text/html')) {
      if (!headers.has('X-Content-Type-Options')) {
        headers.set('X-Content-Type-Options', 'nosniff');
      }
      if (!headers.has('Referrer-Policy')) {
        headers.set('Referrer-Policy', 'strict-origin-when-cross-origin');
      }
      if (!headers.has('X-Frame-Options') && !headers.has('Content-Security-Policy')) {
        headers.set('X-Frame-Options', 'SAMEORIGIN');
      }
    }
    return result;
  }
};

Başlıkların dağıtımı merkezileşir; uygulama bağımlılığı ortadan kalkmaz. Örnek mevcut CSP’yi değiştirmez. Yeni CSP’yi önce Report-Only ile, kurulu bir rapor endpoint’i ve report-to bağlantısıyla değerlendirin; bu mod engelleme yapmaz. Nonce/hash değerleri HTML ile eşleşmelidir. HSTS includeSubDomains/preload kapsamını bütün ilgili hostların HTTPS hazırlığı doğrulanmadan açmayın.

Ülke Bilgisini Kullanıcı Tercihiyle Birlikte Kullanmak

Worker içindeki güvenilir konum alanı request.cf.country üzerinden okunur. CF-IPCountry origin’e aktarılan bir başlıktır ve IP Geolocation veya konum başlıkları ayarına bağlıdır; rastgele bir istemci başlığını doğrulanmış ülke kabul etmeyin. Dashboard/Playground önizlemesinde request.cf bulunmayabilir. Bu ayrı örnek, kullanıcının açtığı /go-regional seçim uç noktasında çalışır; mevcut dil sayfalarını zorla yönlendirmez.

export default {
  async fetch(request) {
    const url = new URL(request.url);
    if (url.hostname !== 'www.example.com' || url.pathname !== '/go-regional' ||
        !['GET', 'HEAD'].includes(request.method)) {
      return fetch(request);
    }
    const selected = url.searchParams.get('lang');
    const cookie = (request.headers.get('Cookie') || '')
      .match(/(?:^|;\s*)site_lang=(tr|en)(?:;|$)/)?.[1];
    const language = ['tr', 'en'].includes(selected) ? selected : cookie;
    const country = request.cf?.country;
    const destination = language || (country === 'TR' ? 'tr' : null);
    if (!destination) return fetch(request);
    return new Response(null, {
      status: 302,
      headers: {
        Location: `https://${destination}.example.com/`,
        'Cache-Control': 'private, no-store'
      }
    });
  }
};

Geçerli lang=tr/en tercihi, ardından site_lang çerezi ülke bilgisinden önce gelir. Tercih yoksa yalnız TR için bölge önerisine geçilir; ülke eksik, bilinmiyor veya diğer bir değer ise origin’deki seçim sayfası devreye girer. Konum doğruluğu garanti değildir. Kişiye göre üretilen 302 yanıtını ortak cache’e koymayın; açık dil bağlantıları ve hreflang kullanın.

BunnyCDN: Yönlendirme, Middleware ve Başlık Kuralları

Bunny’de basit kural işlemleri ile programlanabilir middleware ayrı seçeneklerdir. Önce Pull Zone’a hangi hostname’lerin bağlı olduğunu ve kuralların sırasını belirleyin. Aşağıdaki geçiş örneği www.example.com üzerindeki birinci yol segmentini değiştirir.

BunnyCDN ile Eski Blog Yolunu 301 Yönlendirmek

/eski-blog/yazi yolunu /blog/yazi adresine taşımak için Request URL eşleşmesi ile Path değişkenlerini birlikte kullanın. Bir prefix koşulu kendiliğinden $1 yakalama grubu oluşturmaz; belgelenmiş değişken biçimi %{Path.1-}’dır.

1. CDN → ilgili Pull Zone → Edge Rules → Add Edge Rule yolunu açın.
2. Request URL koşulunu *://www.example.com/eski-blog/* olarak, Request Method koşulunu GET/HEAD olarak tanımlayın; URL ve yöntem koşulları birlikte sağlanmalıdır.
3. Aksiyon: Redirect to URL, durum: 301, hedef: https://www.example.com/blog/%{Path.1-}.
4. /eski-blog/yazi?utm_source=bulten için hedef /blog/yazi?utm_source=bulten olur: ilk yol segmenti çıkar, kalan dosya/yol korunur. Belgeler, dosya adı değişmeyen Path çıkarımında query’nin korunduğunu belirtir; query’yi hedefe ikinci kez eklemeyin.
5. /eski-blog ve /eski-blog/ köklerinin hedefini ayrıca açıkça belirleyin; sondaki slash, boş suffix ve query davranışını staging’de doğrulayın. /eski-blogger/ bu prefix’e girmemelidir.

Bunny belgelerindeki Change Origin URL, origin seçimi için ayrı bir aksiyondur. Buradaki SPA yol eşlemesi örneği ise ayrı Middleware ürününü kullanır; SPA routing’ini origin’de uygulamak da mümkündür. SPA’da yalnız bilinen sayfa yollarını HTML kabuğuna eşlemek için aşağıdaki Bunny Middleware örneği kullanılabilir. Bu bir Edge Rule formuna yapıştırılacak ayar değildir: Edge Script olarak dağıtıp Pull Zone’a bağlayın ve General → Origin altında Run script before cache seçeneğini açın. Aksi halde onClientRequest çalışmaz. Üretimde origin, Pull Zone ayarından alınır; servePullZone içindeki URL yerel geliştirme içindir.

import * as BunnySDK from '@bunny.net/edgescript-sdk@0.13.0';

const pagePaths = new Set(['/app/', '/app/dashboard', '/app/settings']);

function mapSpaRequest(request: Request): Request {
  const url = new URL(request.url);
  if (url.hostname === 'www.example.com' &&
      ['GET', 'HEAD'].includes(request.method) && pagePaths.has(url.pathname)) {
    url.pathname = '/app/index.html';
    return new Request(url.toString(), request);
  }
  return request;
}

BunnySDK.net.http
  .servePullZone({ url: 'https://origin.example.com' })
  .onClientRequest((ctx) => mapSpaRequest(ctx.request));

Yalnız /app/, /app/dashboard ve /app/settings eşlenir. API, varlık dosyaları, POST ve bilinmeyen yollar değişmeden ilerler; eksik JS dosyaları veya gerçek 404’ler 200 HTML’e çevrilmez. Rota listesi uygulamayla birlikte sürümlenmelidir. Bu önbellek öncesi eşleme cache kimliğini de etkiler; HTML kabuğu kişiye özel veri içermemeli, API yanıtları ayrı korunmalıdır.

BunnyCDN ile Güvenlik Başlığı Ekleme

Bunny Set Response Header aksiyonu bir başlık adı/değeri tanımlar. Her başlık için kapsamı ve gerekiyorsa ayrı aksiyonu belirleyin; üç farklı HTTP başlığını tek değer alanına birleştirmeyin.

• HSTS: yalnız HTTPS hazır hostlarda; başlangıçta kısa süre ve alt alanları kapsamayan politika
• X-Frame-Options: uygulamanın çerçevelenme ihtiyacına uygun değer
• Referrer-Policy ve X-Content-Type-Options: mevcut uygulama politikasına uygun kapsam

Bunun için:

1. Set Response Header aksiyonunda başlık adı ve değerini ayrı alanlara girin.
2. HTML’e özgü başlıklar için Response Header koşulunda Content-Type değerinin text/html içerdiğini denetleyin; HSTS için ayrıca HTTPS kapsamını kullanın.
3. Her başlık için ilgili aksiyonu ayrı tanımlayın; sıra ve mevcut origin başlıklarıyla çakışmayı denetleyin.

Strict-Transport-Security: max-age=300
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
X-Content-Type-Options: nosniff

Bunlar onaylanmış uygulama politikasına göre ayrı aksiyonlarda girilecek örnek değerlerdir. Kural sırası belgesi, response header aksiyonlarının birden fazla kez çalışabildiğini açıklar; HIT ve MISS üzerinde sonuçları ölçün. Uygulamanın CSP’sini veya nonce içeren başlığını üzerine genel bir değer yazarak geçersiz kılmayın. HTTP güvenlik başlıkları rehberi politika planlamasına yardımcı olur.

Edge Rules ile Cache Davranışını Ayarlamak

Edge kurallarını doğru cache politikası ile birlikte kullanmak en az URL rewrite kadar kritik. Örneğin:

• Oturum, Authorization, sepet/ödeme ve kişisel API yanıtlarını paylaşılan önbellek dışında tutun.
• İçerik hash’iyle sürümlenen herkese açık varlıklarda uzun TTL değerlendirilebilir.
• Herkese aynı içeriği veren HTML için kısa TTL ancak uygulama denetimi sonrası seçilmelidir; TTL tek başına stale-while-revalidate sağlamaz.

Authorization veya oturum çerezini hit oranını artırmak için yok saymayın. Bunny Vary Cache query, hostname ve desteklenen diğer varyantları yönetir; bu, her Edge Rule’da sınırsız cache-key ifadesi bulunduğu anlamına gelmez. Bunny belgelerinde query varsayılanı ve bazı varyantların erişilebilirliği hakkında farklı açıklamalar vardır: aktif Pull Zone ayarını doğrulayın, içeriği değiştiren parametreler için ayrı varyantları açıkça etkinleştirin ve iki farklı yanıtla sınayın. Override Cache Time=0 mevcut cache girdisini tek başına temizleme garantisi değildir; hassas kapsamı kapatırken eski kopyaları purge edin. CDN cache rehberi bu tasarımı tamamlar.

Edge Kurallarını SEO ve CDN Önbellekleme ile Uyumlu Kullanmak

URL rewrite ve güvenlik başlıklarını edge’e taşıdığınızda, SEO ve cache davranışı açısından dikkat etmeniz gereken birkaç kritik nokta var.

301/302 Yönlendirme Kuralları

Eski URL’den yeni URL’ye kalıcı geçiş yapıyorsanız:

• Kalıcı sayfa taşınmasında 301/308, geçici hedef değişiminde 302/307 kullanın; POST yöntemini koruma gereksinimini ayrıca değerlendirin.
• Eski URL’yi doğrudan nihai HTTPS/hostname/yol birleşimine taşıyın; üç ayrı yönlendirmeyle zincir kurmayın.
• Tek bir kural sahibi belirleyin. Test bitmeden origin güvenlik kontrollerini kaldırmayın; doğrudan origin erişimi kısıtlı kalmalıdır.

Örneğin dil yönlendirmesi yapıyorsanız, tarayıcı diline göre otomatik redirect yerine, genellikle ilk ziyarette banner veya kullanıcıya seçenek sunmak daha sağlıklı. Aksi halde arama motoru botları yanlış varyanta kilitlenebilir.

Canonical ve İç Linkler

Edge’de yaptığınız rewrite, uygulama tarafındaki URL mantığıyla çelişmemeli. Örneğin:

• Kullanıcı /blog/yazi-1 görüyor, ama uygulama canonical’ı /index.php?route=blog&id=1 olarak set ediyorsa SEO tarafında karışıklık çıkar.
• Edge’de /eski-urun → /urun/yeni-urun redirect yaparken, sayfa içinde hala /eski-urun linklerini kullanıyorsanız, botlar her taramada ekstra yönlendirme yaşar.

Bu nedenle, edge kurallarını uygularken uygulama tarafındaki canonical, sitemap ve iç link yapısını da güncellemek şart.

Rewrite Sonrası Cache Kimliği ve Eski İçerik

stale-while-revalidate ve stale-if-error, TTL’den ayrı davranışlardır. Kullanılan CDN, ürün ve cache API’si için desteği doğrulayın; Bunny’de kısa TTL ayarlamak bu direktifleri otomatik etkinleştirmez. Stale içerik rehberi, bu kararların uygulama açısından anlamını açıklar.

Cloudflare zone cache akışında kurallar Worker’ın fetch() ile gönderdiği URL’ye uygulanır. /index.php?route=blog&slug=a ile slug=b farklı içerikse aynı cache anahtarına düşmemelidir. Orijinal URL’yi anahtar yapmak tek başına doğru çözüm değildir: içerik kimliğini, dil/ülke varyantını, yetkiyi ve purge kapsamını birlikte koruyun. Ayrı Workers Cache özelliği etkinse Worker çalışmadan önce yanıt dönebilir; yetkilendirme ve kişisel yönlendirmeler için bu katmanı da denetleyin.

DCHost Origin Altyapısı ile Örnek Mimari

Örnek mimaride origin uygulamayı ve veri katmanını çalıştırır; CDN yalnız uygun istekleri karşılar. Sağlayıcının ürün özelliklerini bu mimari açıklamadan çıkarmayın:

• DCHost VPS veya fiziksel sunucu üzerinde gereksinimlerinize uygun uygulama katmanı
• Önde seçilen CDN; statik dosyalar ve açıkça denetlenmiş herkese açık içerik için cache
• Workers, Edge Rules veya ayrı middleware ile kapsamlandırılmış dönüşümler; origin erişim doğrulaması ve TLS

Çok bölgeli bir tasarımda origin konumu, veri çoğaltma ve hata anında yönlendirme birlikte planlanır. Bu yazı belirli bir sağlayıcıda hazır çok bölgeli küme bulunduğunu iddia etmez. GeoDNS ve çok bölgeli mimari rehberi genel ilkeleri açıklar.

Origin taşınırken kuralların bir bölümü korunabilir; fakat origin hostname’i, TLS, Host başlığı, izinler, cache purge ve veri taşıma ayrıca test edilmelidir. Edge kullanımı tek başına risksiz geçiş sağlamaz.

Gerçek Dünya Senaryoları: Hangi İşi Nereye Koymalı?

Aşağıdaki örneklerde kural sahipliğini ve korunan veri sınırını açık tutun:

1. WordPress + WooCommerce Sitesi

• Origin: WordPress, WooCommerce, PHP-FPM ve veritabanı.
• CDN: Sürümlenmiş statik dosyalar; HTML cache’i yalnız uygulama ve oturum koşulları doğrulanmışsa.
• Edge: Herkese açık URL yönlendirmeleri ve kapsamı tanımlanmış başlık politikaları.

• Sepet, ödeme, hesap, giriş ve oturum/Authorization taşıyan yanıtları cache dışında tutun; yalnız path eşleşmesi yeterli değildir.
• Admin erişiminde kimlik doğrulamasını koruyun; IP/ülke kuralı ek sinyaldir, asıl yetkilendirme değildir.
• Başlıkları uygulama ihtiyacına göre yönetin; kullanıcıya göre değişen içerikleri paylaşmayın.
• Eski blog URL’leri için tek atlamalı, bire bir kalıcı eşleme yapın.

Öncesi/sonrası cache HIT, origin istek sayısı, gecikme ve hata oranı ölçülerek sonuç değerlendirilir. WordPress sunucu optimizasyonu edge yapılandırmasını tamamlayan ayrı bir katmandır.

2. Laravel / Özel PHP Uygulaması

• Origin: Tüm routing Laravel üzerinde.
• Workers:

• Bakım yanıtını yalnız planlı kapsama 503, Retry-After ve no-store ile uygulayın; kritik webhook/sağlık uçlarını ayrı değerlendirin.
• Webhook’larda sağlayıcı imzasını ve yeniden oynatma kontrollerini koruyun; IP listesi tek doğrulama olmamalıdır.
• Oran sınırlamasında paylaşılan durum ve ürünün kota/algoritmasını kullanın; Worker global değişkeni bütün edge noktalarında tutarlı sayaç değildir.

API ve mikroservisler için daha ince ayarlı trafik kontrolü gerektiğinde, edge katmanını Nginx/Redis temelli oran sınırlama ile birleştirmek mantıklı. Bunu da API ve mikroservisler için rate limiting stratejileri yazımızda detaylandırdık.

3. Statik veya Jamstack Site

Statik HTML/Jamstack projelerde aslında origin neredeyse “build artifact deposu” haline geliyor.

• Origin: Sadece dosya sunumu.
• Edge kuralları:

• Dil varyantları için açık bağlantılar ve kullanıcı seçimi; zorunlu ülke yönlendirmesinden kaçınma
• Uygulamaya uygun başlık politikaları
• Gerçek 404/5xx durumlarını koruyan hata sayfaları; her hatayı SPA HTML’iyle 200’e dönüştürmeme

Origin kapasitesi dosya büyüklüğü, istek oranı, cache isabeti ve dinamik iş yüküne göre ölçülmelidir. Statik site için bile belirli bir küçük VPS’in her trafiğe yeteceği sonucu çıkarılamaz.

Pratik İpuçları ve Sık Yapılan Hatalar

1. Aynı Kuralı Birden Fazla Katmanda Tekrarlamayın

Aynı redirect veya başlığı origin ve birden fazla CDN kuralı birlikte değiştiriyorsa şu sorunlar oluşabilir:

• Redirect loop’lar
• İki farklı CSP’nin üst üste binmesi ve beklenmedik JS hataları
• HSTS’nin iki farklı yerde farklı değerlerle set edilmesi

Her politika için sorumlu katmanı belirleyin. Uygulamanın dinamik CSP’sini koruyun; birden fazla CSP genel olarak birlikte kısıtlayıcı uygulanır, son başlığın öncekini gevşettiğini varsaymayın. Origin kurallarını ancak kapsam ve bypass davranışı doğrulandıktan sonra sadeleştirin.

2. Loglama ve Debug Mekanizması Kurun

Hangi Worker/kuralın devreye girdiğini, edge ve origin hata oranını ve upstream süresini izleyin. Loglama için ürünün güncel gözlem araçlarını ve kontrollü örneklemeyi kullanın:

• Kural kimliği, durum kodu ve gecikme gibi gerekli alanları kaydedin; Authorization, oturum çerezi ve hassas query değerlerini loglamayın.
• Harici log servisi geciktiğinde kullanıcı isteğinin süresini sınırsız uzatmayın; örnekleme, erişim denetimi ve saklama süresi belirleyin.

Merkezi log altyapısına güncel ve desteklenen bir kolektörle aktarım yapılabilir. Edge, CDN cache ve origin ölçümlerini ortak istek kimliği üzerinden ilişkilendirin.

3. Küçükten Başlayın, Kapsamı Yavaş Genişletin

Geçişi küçük kapsamlara bölün; her aşamada geri dönüş için önceki kural ve kod sürümünü saklayın:

1. Önce envanter ve staging karşılaştırmasını tamamlayın.
2. Bir açık sayfa yönlendirmesini, normal ve sınır URL’leriyle doğrulayın.
3. Uygulama onayı alınmış başlıkları ekleyin.
4. Sonra rewrite, SPA ve bakım gibi davranışları küçük trafik kapsamında deneyin; HIT/MISS, kullanıcı oturumu ve hata durumlarını ayrı kontrol edin.

Her adımda, HTTP status kodlarını ve response header’larını dikkatlice izleyerek ilerlemek, canlı sitede sorun çıkma riskini ciddi şekilde azaltıyor.

4. Versiyonlama ve Ortam Ayrımı Yapın

Özellikle Cloudflare Workers tarafında, staging ve prod için ayrı Workers ve ayrı Route’lar kullanmak çok faydalı. Staging ortamınız için ayrı bir subdomain (örneğin staging.example.com) ve buna özel edge kuralları tanımlayarak, değişiklikleri gerçek trafik almadan önce test edebilirsiniz. Bu yaklaşımı genel olarak yayın süreçleri için geliştirme–staging–canlı yolculuğu rehberimizde detaylandırmıştık; edge kuralları da bu akışın bir parçası olmalı.

Yayın Öncesi Son Kontrol

Edge katmanına taşınan her kural için tetikleyiciyi, beklenen sonucu, cache etkisini ve sorumlu kişiyi kaydedin. Kontrol listesi:

• Doğru hostname/path/yöntem; prefix benzerleri ve boş yol sınırları
• Bir atlamalı 301, query korunması, canonical/hreflang/sitemap tutarlılığı
• Oturum, Authorization, ayrı içerik varyantları ve eski cache temizliği
• Başlık çakışması, gerçek 404/503, doğrudan origin erişimi ve geri dönüş planı

Yönlendirme ve edge’de üretilen yanıt origin çağrısını önleyebilir; rewrite ve başlık ekleme bunu her zaman yapmaz. Sonucu origin istek sayısı, HIT/MISS, TTFB ve hata oranıyla ölçün.

Sunucu seçimini uygulama, veri ve arka plan işlerinin kalan yüküne göre yapın. CDN kuralları için de kod ve yapılandırmayı sürümleyin; hosting değişikliği ya da CDN geçişinde bu kayıtlar aynı davranışı yeniden kurmanızı sağlar.