Cloudflare Nedir ve Web Sitenizi Nasıl Hızlandırır?

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Yıllar içinde onlarca müşteri sitesini Cloudflare’e taşıdım ve her seferinde aynı soruyla karşılaştım: “Bu ne işe yarıyor tam olarak?” Cevabı vermek için genellikle şöyle bir benzetme kullanıyorum – düşünün ki bir şehirde çok popüler bir restoran açtınız, ama adres olarak sadece koordinat verdiniz. Cloudflare, o koordinatı “Beşiktaş Meydanı’nın hemen karşısı” haline getiren, üstüne de kapıya bir güvenlik görevlisi koyan ve müşterilerin siparişlerini daha hızlı alabilmesi için restoran şubelerini şehrin her yerine açan sistemdir.

Teknik olmayan benzetmeyi bir kenara bırakırsak, Cloudflare temelde bir Ters Proxy (Reverse Proxy) ve CDN (Content Delivery Network) servisidir. Ama bu tanım da yeterince açıklayıcı değil. O yüzden baştan başlayalım.

Cloudflare Tam Olarak Ne Yapar?

Bir kullanıcı web sitenizi ziyaret etmek istediğinde, normalde şu yol izlenir: kullanıcının tarayıcısı DNS üzerinden sitenizin IP adresini öğrenir, doğrudan sunucunuza bağlanır, sunucunuz içeriği üretir ve kullanıcıya gönderir. Basit ama zayıf bir zincir.

Cloudflare bu zincire girdiğinde süreç şöyle değişir: DNS kaydınız artık Cloudflare’in sunucularını gösterir. Kullanıcının isteği önce Cloudflare’in küresel ağına ulaşır (215’ten fazla veri merkezi), orada önbellekte varsa direkt oradan servis edilir, yoksa Cloudflare sizin gerçek sunucunuza bağlanarak içeriği alır ve hem kullanıcıya iletir hem de önbelleğe alır.

Bu süreçte Cloudflare aynı anda şunları yapıyor:

  • Kullanıcıya en yakın veri merkezinden içerik servis ediyor
  • Kötü amaçlı trafiği filtreliyor
  • SSL/TLS sonlandırmasını üstleniyor
  • HTTP başlıklarını optimize ediyor
  • Statik içerikleri sıkıştırıyor ve önbelleğe alıyor
  • DDoS saldırılarını absorbe ediyor

DNS Konfigürasyonu ve İlk Kurulum

Cloudflare’e geçişin ilk adımı domain’inizin nameserver’larını değiştirmek. Bunu yaptıktan sonra DNS kayıtlarınızı Cloudflare panelinden yönetmeye başlıyorsunuz. Turuncu bulut ikonunu gördüğünüzde o kayıt Cloudflare üzerinden proxy ediliyor demek, gri bulut ise sadece DNS çözümlemesi yapılıyor.

Cloudflare API üzerinden DNS yönetimi yapmak için:

# Cloudflare API ile DNS kayıtlarını listele
curl -X GET "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" 
  -H "Authorization: Bearer API_TOKEN" 
  -H "Content-Type: application/json"
# Yeni bir A kaydı ekle (proxy aktif)
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records" 
  -H "Authorization: Bearer API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{
    "type": "A",
    "name": "www",
    "content": "192.0.2.1",
    "ttl": 1,
    "proxied": true
  }'

Burada ttl: 1 “otomatik” anlamına geliyor, proxied kayıtlarda Cloudflare TTL’i kendisi yönetiyor zaten.

Gerçek IP adresinizi gizli tutmak önemli. Aksi hâlde Cloudflare’in önünden geçmeyen doğrudan saldırılar alabilirsiniz. Sunucunuzda yalnızca Cloudflare IP aralıklarından gelen trafiğe izin vermek iyi bir pratik.

# Cloudflare IP aralıklarını çek ve iptables kuralı oluştur
# Önce mevcut kuralları temizle
iptables -F INPUT

# Cloudflare IPv4 aralıkları için izin ver (güncel listeyi cloudflare.com/ips adresinden alın)
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  iptables -A INPUT -p tcp --dport 80 -s $ip -j ACCEPT
  iptables -A INPUT -p tcp --dport 443 -s $ip -j ACCEPT
done

# Diğer kaynaklardan gelen 80/443 trafiğini engelle
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -j DROP

Bu script’i cron’a bağlayıp periyodik olarak güncellemenizi öneririm, Cloudflare IP aralıkları zaman zaman değişiyor.

Cache Stratejisi: Sitenizi Gerçekten Hızlandıran Kısım

Cloudflare’in hız kazanımının büyük bölümü cache’den geliyor. Ama varsayılan cache ayarları her zaman optimal değil. Özellikle dinamik içerik ağırlıklı sitelerde bunu doğru yapılandırmazsanız ya hiç cache’lemiyorsunuz ya da yanlış şeyleri cache’liyorsunuz.

Cache Level ayarı üç modda geliyor:

  • Bypass: Cache yok, her istek sunucuya gidiyor
  • Standard: Statik uzantıları cache’liyor (.jpg, .css, .js vb.)
  • Ignore Query String: Query string’i dikkate almadan cache’liyor

WordPress gibi siteler için özel bir Cache Everything kuralı oluşturmak mantıklı. Bunun için Page Rules veya yeni nesil Cache Rules kullanabilirsiniz.

Cloudflare Workers üzerinden özel cache mantığı yazmak ise en güçlü yaklaşım:

// Cloudflare Worker - Akıllı cache stratejisi
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)
  
  // Admin ve login sayfalarını asla cache'leme
  if (url.pathname.startsWith('/wp-admin') || 
      url.pathname.startsWith('/wp-login') ||
      url.pathname.startsWith('/cart') ||
      url.pathname.startsWith('/checkout')) {
    return fetch(request)
  }

  // Cookie'si olan kullanıcıları (giriş yapmış) bypass et
  const cookie = request.headers.get('Cookie')
  if (cookie && (cookie.includes('wordpress_logged_in') || 
                 cookie.includes('woocommerce_cart_hash'))) {
    return fetch(request)
  }

  // Diğer tüm istekler için cache kullan
  const cacheKey = new Request(url.toString(), request)
  const cache = caches.default
  
  let response = await cache.match(cacheKey)
  
  if (!response) {
    response = await fetch(request)
    // Cache-Control başlığını override et
    const headers = new Headers(response.headers)
    headers.set('Cache-Control', 'public, max-age=3600')
    response = new Response(response.body, { ...response, headers })
    event.waitUntil(cache.put(cacheKey, response.clone()))
  }
  
  return response
}

Bu Worker, WordPress sitelerinde sıkça yapılan hatayı önlüyor: giriş yapmış kullanıcılara veya alışveriş sepeti olan ziyaretçilere cache’lenmiş sayfa sunmak ciddi sorunlara yol açar.

Cache Purge Otomasyonu

İçerik güncellemelerinde cache’i temizlemek şart. Bunu Manuel yapmak hem zahmetli hem hata prone. CI/CD pipeline’ınıza veya deployment script’inize cache purge adımı ekleyin:

#!/bin/bash
# deploy-and-purge.sh
# Deployment sonrası Cloudflare cache temizleme

ZONE_ID="your_zone_id_here"
API_TOKEN="your_api_token_here"

echo "Deployment tamamlandı, Cloudflare cache temizleniyor..."

# Tüm cache'i temizle
PURGE_RESPONSE=$(curl -s -X POST 
  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -H "Content-Type: application/json" 
  --data '{"purge_everything": true}')

# Yanıtı kontrol et
SUCCESS=$(echo $PURGE_RESPONSE | python3 -c "import sys, json; print(json.load(sys.stdin)['success'])")

if [ "$SUCCESS" = "True" ]; then
  echo "Cache başarıyla temizlendi."
else
  echo "Cache temizleme başarısız: $PURGE_RESPONSE"
  exit 1
fi

Tüm cache’i silmek yerine sadece güncellenen URL’leri hedeflemek daha performanslı:

# Belirli URL'lerin cache'ini temizle
curl -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://siteniz.com/",
      "https://siteniz.com/blog/",
      "https://siteniz.com/css/main.css"
    ]
  }'

SSL/TLS Yapılandırması ve Güvenlik

Cloudflare SSL konusunda dört mod sunuyor ve yanlış modu seçmek ciddi sorunlara yol açabiliyor:

  • Off: SSL yok (kesinlikle kullanmayın)
  • Flexible: Kullanıcı ile Cloudflare arası şifreli, Cloudflare ile sunucunuz arası şifresiz. Yani orjin sunucunuzda SSL sertifikası olmasa bile HTTPS gösteriliyor. Pratik görünüyor ama güvensiz.
  • Full: Her iki bağlantı da şifreli, ama sunucudaki sertifika geçerliliği kontrol edilmiyor. Öz imzalı sertifika kullananlar için uygun.
  • Full (Strict): En güvenli mod. Her iki taraf da şifreli ve sunucudaki sertifika geçerli olmalı. Bu modu kullanın.

Origin server’ınız için Cloudflare’in ücretsiz Origin CA sertifikası oluşturabilirsiniz. Bu sertifika tarayıcılar tarafından doğrudan güvenilir değil ama Cloudflare tarafından güvenilir, yani perfect combination.

# Nginx'te Cloudflare Origin CA sertifikası kullanımı
# /etc/nginx/sites-available/siteniz.com

server {
    listen 443 ssl http2;
    server_name siteniz.com www.siteniz.com;

    # Cloudflare Origin CA sertifikaları
    ssl_certificate /etc/ssl/cloudflare/origin-cert.pem;
    ssl_certificate_key /etc/ssl/cloudflare/origin-key.pem;

    # Güçlü SSL ayarları
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

    # HSTS (Cloudflare panelinden da aktifleştirebilirsiniz)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    # Sadece Cloudflare IP'lerinden bağlantı kabul et
    include /etc/nginx/cloudflare-ips.conf;
    deny all;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $http_cf_connecting_ip;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Dikkat: X-Real-IP başlığında $remote_addr yerine $http_cf_connecting_ip kullanmak şart. Aksi hâlde log’larınızda ve uygulamanızda Cloudflare’in IP’sini görürsünüz, gerçek kullanıcı IP’sini değil.

Performans Optimizasyon Ayarları

Cloudflare panelinde Speed sekmesi altında bir sürü optimizasyon seçeneği var. Hangilerini aktifleştireceğinizi biraz kafanız karışabilir.

Auto Minify: HTML, CSS ve JavaScript dosyalarını minify ediyor. Aktifleştirin. Nadiren sorun çıkarıyor ve küçük de olsa fayda sağlıyor.

Brotli: Brotli sıkıştırma. Gzip’ten daha iyi sıkıştırma oranı sunuyor, modern tarayıcıların hepsi destekliyor. Aktifleştirin.

HTTP/2: Varsayılan aktif geliyor. Birden fazla isteği aynı bağlantı üzerinden paralel işliyor.

Early Hints (103): Cloudflare, tarayıcıya sayfa tam yüklenmeden önce hangi kaynakları önyüklemesi gerektiğini söylüyor. Core Web Vitals üzerinde ciddi etkisi var.

Rocket Loader: JavaScript yüklenmesini asenkron hale getiriyor. WordPress sitelerinde bazen sorun çıkarabiliyor, test ederek kullanın.

Polish: Pro planda geliyor. Görüntüleri otomatik optimize ediyor, WebP’ye dönüştürüyor. Eğer Pro planınız varsa mutlaka aktifleştirin.

Cloudflare’in gerçekten hız kazandırdığını ölçmek için:

# Cache HIT kontrolü - Cloudflare header'larını incele
curl -sI https://siteniz.com/ | grep -E "cf-cache-status|cf-ray|server"

# Beklenen çıktı:
# cf-cache-status: HIT
# cf-ray: 7a3b4c5d6e7f8a9b-IST
# server: cloudflare

# Birden fazla lokasyondan test için
for i in 1 2 3 4 5; do
  echo "İstek $i:"
  curl -sI https://siteniz.com/ | grep "cf-cache-status"
  sleep 1
done

cf-cache-status değerleri şu anlama geliyor:

  • HIT: Cloudflare cache’inden servis edildi, sunucunuza dokunulmadı
  • MISS: İlk istek, sunucudan alındı ve cache’lendi
  • BYPASS: Cache kullanılmadı (Worker veya kural nedeniyle)
  • EXPIRED: Cache vardı ama süresi dolmuş, yenilendi
  • DYNAMIC: Dinamik içerik, cache’lenmiyor

Rate Limiting ve Bot Yönetimi

Cloudflare’in güvenlik katmanları da sitenizi dolaylı yoldan hızlandırıyor çünkü kötü amaçlı veya gereksiz trafik sunucunuza ulaşmıyor.

Basit bir rate limiting kuralı (WAF Rules üzerinden):

# Cloudflare API ile rate limiting kuralı oluştur
curl -X POST 
  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets/phases/http_ratelimit/entrypoint/rules" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -H "Content-Type: application/json" 
  --data '{
    "description": "Login sayfası rate limit",
    "expression": "(http.request.uri.path eq "/wp-login.php")",
    "action": "block",
    "ratelimit": {
      "characteristics": ["ip.src"],
      "period": 60,
      "requests_per_period": 5,
      "mitigation_timeout": 600
    }
  }'

Bu kural, aynı IP’den 60 saniye içinde 5’ten fazla login denemesi gelirse o IP’yi 10 dakika engelliyor. WordPress sitelerinde brute force saldırılarını neredeyse tamamen kesiyor.

Cloudflare Analytics ile Performans İzleme

Neyin işe yarayıp neyin yaramadığını anlamak için Cloudflare’in analytics verilerini kullanın. Free planda bile oldukça değerli veriler var.

# GraphQL API ile Cloudflare analytics sorgula
curl -X POST 
  "https://api.cloudflare.com/client/v4/graphql" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -H "Content-Type: application/json" 
  --data '{
    "query": "{ viewer { zones(filter: {zoneTag: "ZONE_ID"}) { httpRequests1dGroups(limit: 7, filter: {date_gt: "2024-01-01"}) { sum { requests cachedRequests bytes cachedBytes } } } } }"
  }'

Bu sorgu son 7 günün cache oranını veriyor. cachedRequests / requests oranı ne kadar yüksekse o kadar iyi. %70’in altındaysa cache stratejinizi gözden geçirin.

Terraform ile Cloudflare Yönetimi

Birden fazla domain yönetiyorsanız veya ekip olarak çalışıyorsanız Cloudflare’i Infrastructure as Code olarak yönetmek çok daha sağlıklı.

# Terraform Cloudflare provider konfigürasyonu
# main.tf

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

# DNS kaydı
resource "cloudflare_record" "www" {
  zone_id = var.zone_id
  name    = "www"
  value   = "192.0.2.1"
  type    = "A"
  proxied = true
}

# Cache kuralı
resource "cloudflare_ruleset" "cache_rules" {
  zone_id     = var.zone_id
  name        = "Cache Rules"
  description = "Özel cache kuralları"
  kind        = "zone"
  phase       = "http_request_cache_settings"

  rules {
    action = "set_cache_settings"
    action_parameters {
      edge_ttl {
        mode    = "override_origin"
        default = 3600
      }
      cache = true
    }
    expression  = "(http.request.uri.path.extension in {"jpg" "jpeg" "png" "gif" "webp" "svg" "css" "js"})"
    description = "Statik dosyaları cache'le"
    enabled     = true
  }
}
# Terraform ile deploy
terraform init
terraform plan -var="cloudflare_api_token=TOKEN" -var="zone_id=ZONE_ID"
terraform apply

Bu yaklaşımın güzelliği şu: tüm Cloudflare yapılandırmanız git’te versiyonlanıyor, değişiklikler PR süreciyle geçiyor ve gerektiğinde kolayca rollback yapabiliyorsunuz.

Dikkat Edilmesi Gereken Noktalar

Cloudflare her şeyin çözümü değil ve birkaç gotcha var:

Gerçek IP sorunları: Cloudflare arkasında Nginx veya Apache çalıştırıyorsanız, CF-Connecting-IP başlığını okuyacak şekilde yapılandırmanız şart. Aksi hâlde rate limiting, GeoIP ve erişim logları yanlış çalışıyor.

Origin pull trafiği: Cloudflare önbellekte bulamadığı içerikleri sunucunuzdan çekiyor. Yoğun trafik dönemlerinde bu “origin pull” yükü beklenenden fazla olabilir. Sunucu kapasitesini Cloudflare olmadan hesaplamayın.

WebSocket desteği: Cloudflare WebSocket bağlantılarını destekliyor ama bazı planlarda sınırlamalar var. Uygulamanızda WebSocket kullanıyorsanız önceden test edin.

Free plan limitleri: Free planda Workers 100.000 istek/gün, Cache Rules 10 kural gibi limitler var. Bunlara çarpmadan önce planlama yapın.

Sonuç

Cloudflare kurulumu ile başladım bu yazıya, ama asıl anlatmak istediğim şey şu: Cloudflare’i “kurduk bitti” olarak görmek yanlış. DNS’i yönlendirip geride bırakmak yerine cache stratejinizi oturup düşünmek, Workers ile özel mantık yazmak, Terraform ile yönetimi kodlamak ve analytics’i düzenli izlemek gerekiyor.

Bunu doğru yaptığınızda gerçekten etkileyici sonuçlar alıyorsunuz. Kendi deneyimimden vereceğim rakamla kapatalım: bir e-ticaret sitesinde sadece cache stratejisini optimize etmemiz, yani yukarıdaki Worker mantığının benzerini uygulamak, sunucu yükünü %60 düşürdü ve TTFB’yi İstanbul’dan ölçümde 340ms’den 40ms’ye indirdi. Sunucu aynı sunucu, kod aynı kod, sadece Cloudflare’in neyi cache’leyeceğini ve nasıl servis edeceğini doğru söyledik.

Küçük bir statik blog mu? Free plan yeterli, birkaç saat içinde kurarsınız. Yüksek trafikli e-ticaret veya SaaS? Pro veya Business plan, Workers, Terraform entegrasyonu ve ciddi bir planlama. Her iki durumda da Cloudflare, toolbox’ınızın olmazsa olmaz bir parçası.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir