Load Balancing

Load Balancing nedir?

“Cloudflare Load Balancing distributes traffic across your endpoints, which reduces endpoint strain and latency and improves the experience for end users.”

Ürün sayfasındaki çerçeveleme daha iddialı:

“Cloudflare Load Balancing protects your bottom line by minimizing costly downtime. Our load balancing product directs traffic across your servers, data centers, and cloud environments based on server health and user-to-origin latency, with near-instantaneous global failover.”

“Truly Cloud Agnostic — Unlike cloud-native load balancers that favor their own ecosystem, Cloudflare Load Balancing is vendor-neutral. Developers can seamlessly balance traffic between AWS, GCP, Azure, and on-premise servers.”

Çözdüğü problem iki tarafı olan bir boşluk: DNS round-robin sağlık sinyali taşımaz ve ölü sunucuya trafik göndermeye devam eder. Donanım load balancer tek bir veri merkezinde yaşar ve o veri merkeziyle birlikte ölür. Cloudflare sağlık kararını edge’de, kullanıcının yanında veriyor.

Bu bir eklenti — plan özelliği değil. Enterprise müşteriler sözleşmesiz olarak önizleyebiliyor.

Nasıl çalışır?

Üç bileşen artı monitörler

Hiyerarşi basit: load balancer → havuzlar (pool) → endpoint’ler, ve havuzlara bağlanan monitörler.

“Within Cloudflare, pools represent your endpoints and how they are organized. As such, a pool can be a group of several endpoints, or you could also have only one endpoint per pool — it depends on what best suits your use case.”

“Endpoints refer to any service or hardware that intercepts and processes incoming public or private traffic. Examples of endpoints include origins, hostnames, private or public IP addresses, virtual IP addresses (VIPs), servers, and other dedicated hardware boxes.”

“Finally, monitors are the component you can use to guarantee only healthy pools are considered for traffic distribution.”

Public bir load balancer oluşturduğunda Cloudflare otomatik olarak bir LB DNS kaydı üretiyor. Özel (private) load balancer’lar ise hostname ile ilişkilendirilmiyor — CGNAT veya RFC-1918 IP adresiyle oluşturuluyorlar.

Monitör tipleri ve plan kapısı

“Non-enterprise customers: Choose HTTP, HTTPS, or TCP. Enterprise customers: Choose HTTP, HTTPS, TCP, UDP ICMP, ICMP Ping, or SMTP.”

Sağlık kontrolü bölgeleri — origin’ine ne kadar yük bindiriyor

“For each option selected in a pool’s Health Monitor Regions, Cloudflare sends health monitor requests from three separate data centers in that region.”

“If the majority of data centers for that region pass the health monitor requests, that region is considered healthy. If the majority of regions is healthy, then the endpoint itself will be considered healthy.”

Failover süresinin aritmetiği

Bu, demonun ve üretim planlamasının temeli:

“When a health check times out, Cloudflare sends retries immediately — they do not wait for the next interval. The retries setting defines the number of additional attempts after the initial check. For example, with five retries: Total attempts: 1 (initial) + 5 (retries) = 6; With a 20 s timeout: Cloudflare marks the endpoint unhealthy after approximately 120 s (6 × 20 s); The configured interval (for example, 60 s) only applies between successful probe cycles, not between retries.”

Bunun üstüne consecutive_down sayacı, bölge başına üç veri merkezinin çoğunluğu, bölgelerin çoğunluğu ve yayılma süresi biniyor. Sabit bir rakam vermek mümkün değil — ölçmek gerekiyor.

Bir de sağlık kontrolünün okuduğu gövde sınırlı: “we only read the first 10 KB of the response. If you return a larger response, and the expected_body is not in the first 10 KB, the health monitor request will fail.”

Prob isteklerinin User-Agent’ı da belli:

Mozilla/5.0 (compatible; Cloudflare-Traffic-Manager/1.0; +https://www.cloudflare.com/traffic-manager/; pool-id: $poolid)

$poolid, ilişkili havuzun ilk 16 karakteri. Firewall kuralı yazarken işine yarar.

Sağlık durumları

Havuz durumları:

Üç davranış notu kritik:

“1. When no monitor is attached to a pool, the health status is not considered during steering. 2. Origins are considered down when monitoring is enabled, but the health status is still unknown. 3. If there are no monitors, a fallback pool is still required, but it will only be used if all the default pools have origins with FQDN addresses that cannot be resolved.”

Load balancer durumları: Healthy (tüm havuzlar sağlıklı) · Degraded (en az bir havuz sağlıksız ama trafik henüz fallback’e gitmiyor) · Critical (tüm havuzlar sağlıksız, trafik fallback’e gidiyor).

Steering politikaları

Trafik yönlendirme üç faktöre bağlı: havuz ve endpoint sağlığı, global steering (load balancer üzerinde, havuzlar arasında) ve local steering (havuz üzerinde, endpoint’ler arasında).

Global politikalar — API şemasının kendi tanımlarıyla:

Failover ve failback davranışı:

“In an active/standby setup, with two origin pools: Traffic always routes to Pool 1 (the primary pool) unless it becomes unhealthy. If Pool 1 is marked unhealthy, traffic shifts to Pool 2 (the standby pool). Once Pool 1 becomes healthy again, traffic automatically shifts back to Pool 1… This behavior is known as failback.”

Politikaya göre yeniden dağıtım da farklı: “Off: If the active pool becomes unhealthy, traffic goes to the next pool in order… All other methods: Traffic is distributed across all remaining pools according to the traffic steering policy.”

Dynamic steering RTT profili kuruyor ve ilk kurulumda sabır istiyor:

“Dynamic steering creates Round Trip Time (RTT) profiles based on an exponential weighted moving average (EWMA) of RTT to determine the fastest pool.”

“When enabling Dynamic steering the first time for a pool, allow 10 minutes for the change to take effect while Cloudflare builds an RTT profile for that pool.”

“To ensure dynamic steering works as expected, the Health Monitor Region must be set to All Regions.”

Bir uyarı: “For TCP health monitors, calculated latency may not reflect the true latency to the endpoint if you are terminating TCP at a cloud provider edge location.”

Geo steering 13 bölge kodu kullanıyor: EEU ENAM ME NAF NEAS NSAM OC SAF SAS SEAS SSAM WEU WNAM. Fallback zinciri: veri merkezi → ülke → bölge → varsayılan havuzlar.

Local (endpoint) steering üç politika sunuyor: random (yalnızca ağırlıklara göre), hash (IP’ye göre yapışkan) ve least_outstanding_requests.

Ağırlıklar 0 ile 1 arasında, 0,01 adımlarla. Formül: endpoint ağırlığı ÷ havuzdaki tüm ağırlıkların toplamı. Ve gerçekçi bir uyarı: “A significant amount of traffic is required for the distribution to converge on the expected values.” On istekle test edip “ağırlıklar çalışmıyor” demek yaygın bir hata.

Session affinity

“When you enable session affinity, your load balancer directs all requests from a particular end user to a specific endpoint. This continuity preserves information about the user session — such as items in their shopping cart.”

“Session affinity can also help reduce network requests, leading to savings for customers with usage-based billing.”

Dört tip: none, cookie, ip_cookie, header.

Çerez tabanlı:

“When a client makes its first request, Cloudflare sets a __cflb cookie on the client… If the cookie expires or the endpoint becomes unhealthy, Cloudflare sets a new cookie tracking the new failover endpoint.”

“All cookie-based sessions default to 23 hours unless you set a custom session Time to live.”

“The session cookie is secure when Always Use HTTPS is enabled. Additionally, HttpOnly is always enabled for the cookie to prevent cross-site scripting attacks.”

ip_cookie farkı tek cümlede: “behaves the same as cookie except the initial endpoint selection is stable and based on the client’s IP address.”

Header tabanlı affinity’nin TTL semantiği farklı: “sessions only expire after they haven’t been used for the number of seconds specified” — yani mutlak değil, boşta kalma süresi.

Header sayısı plana bağlı: “The default max number of HTTP header names that can be provided depends on your plan: 5 for Enterprise, 1 for all other plans.”

Adaptive routing — sağlık kontrolünden önce devreye giren kurtarma

“Adaptive routing controls features that modify the routing of requests to pools and endpoints in response to dynamic conditions, such as during the interval between active health monitoring requests.”

“Zero-downtime failover will trigger a single retry only if there is another healthy endpoint in the pool and a 521, 522, 523, 525 or 526 error code is occurring.”

Zero-downtime failover’ın üç modu var: none (varsayılan), temporary (“this can potentially result in heavy origin flapping”) ve sticky (affinity çerezi güncelleniyor).

Ve bir uyumsuzluk: “This feature is currently incompatible with Argo, Tiered Cache, and Bandwidth Alliance.”

HTTP/2 tarafında da ince bir davranış var: “When an origin sends a GOAWAY frame, Cloudflare stops sending new requests on that connection but does not mark the endpoint as unhealthy. Safe-to-retry requests (typically GET) are automatically retried on a new connection. Non-idempotent requests (such as POST or PUT) may not be retried.”

Load shedding

“Use load shedding to prevent an at-risk endpoint from becoming unhealthy and starting the failover process.”

İki politika: random (istek seviyesinde, daha doğru dağılım ama aynı IP farklı endpoint’e düşebilir) ve hash (IP hash alanının yüzdesi, yapışkan ama “can over- or under-shed requests”).

Session affinity trafiği için yalnızca hash kullanılabiliyor.

İki operasyonel tuzak:

“If all pools within a load balancer have Load shedding enabled, some traffic will go to the fallback pool.”

“If you enable load shedding on a pool, it will shed the same percentage of traffic across all your load balancers.”

Proxy modları

İki DNS tuzağı:

“if a DNS-only (grey cloud) CNAME record points to a proxied load balancer, the IP returned for it would be endpoint IP and a HTTP request sent to it would not be proxied.”

“if a load balancer endpoint is a proxied (orange-cloud) CNAME record, the IP returned for it would be Cloudflare’s and a HTTP request sent to it would be proxied accordingly.”

Private Network Load Balancing

“Private Network Load Balancing enables you to load balance traffic between servers within a data center (endpoint steering) and between private applications. This helps you eliminate the need for hardware appliances.”

Özel IP’li origin’ler için: “Cloudflare load balancers require a Cloudflare tunnel with an associated virtual network (VNet). If you are connecting to your endpoints using a published application route a VNet is not necessary.”

Asıl kazanç şu: “have the ability to monitor the health of these IP targets directly, rather than load balancing to a tunnel and only monitoring the health of the tunnel itself.”

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

Kullanılır

• Birden fazla veri merkezin veya bulut sağlayıcın varsa ve aralarında otomatik failover istiyorsan.
• Origin’lerin farklı sağlayıcılarda dağılmışsa. Ürün gerçekten satıcı bağımsız.
• Kademeli dağıtım (canary) yapıyorsan. Ağırlık artı session affinity iyi bir kombinasyon.
• On-prem sunucularını Tunnel arkasında dengelemek istiyorsan.

Kullanılmaz

Tek origin’in var ve yalnızca izlemek istiyorsan. Standalone Health Checks daha ucuz ve eklenti gerektirmiyor — Pro’da 10, Business’ta 50, Enterprise’da 1.000 kontrol.

Gerçek bir load balancer’ın avantajları gerekiyorsa. Somut farklar:

• Bağlantı boşaltma (connection draining) yok. Sağlıksız olan endpoint’e yeni istek gitmiyor ama mevcut bağlantılar — WebSocket dahil — kendiliğinden kapanana kadar açık kalıyor. HAProxy, NGINX ve F5 sonlandırır.
• Sağlık kontrolü tabanı 10–15 saniye. Donanım LB onlarca milisaniyede tepki verir. Mükemmel bir Cloudflare failover’ı bile onlarca saniyedir.
• Origin’den gerçek zamanlı geri baskı sinyali yok. Agent yok, kuyruk derinliği yok, CPU sinyali yok. Tek yük girdisi uçuştaki istek sayısı ve prob RTT’si.
• Custom rules Geo steering ile çalışmıyor, Spectrum ile hiç çalışmıyor.
• Layer 4 yalnızca Spectrum üzerinden ve orada session affinity, havuzlar arası failover ve custom rules düşüyor.

Düz DNS round-robin yeterliyse. Origin’lerin durumsuz, eşit ve nadiren arızalanıyorsa, L7 özelliklerine ihtiyacın yoksa ve zaten DNS-only modda çalışacaksan — iki A kaydı bedava. Cloudflare LB sağlık kontrolü ekliyor ama dokümanların kendisi DNS-only modun dezavantajlarını sıralıyor ve resolver cache’i failover’ı yok sayabiliyor.

Tek veri merkezi içinde sunucu dengeliyorsan. Private Network Load Balancing gerekiyor: Tunnel artı Virtual Network. NGINX kurmaktan çok daha fazla makine.

Argo, Tiered Cache veya Bandwidth Alliance kullanıyorsan ve zero-downtime failover istiyorsan. Uyumsuzlar.

Geo steering ile bölgeler arası failover bekliyorsan. Kendiliğinden olmuyor.

FQDN endpoint adresi kullanmak zorundaysan. SSS net: “Use IP addresses for endpoint configurations. If that is not feasible, use domains for which Cloudflare is authoritative.” Aksi halde tek bir veri merkezindeki başarısız çözümleme sessizce yanlış yönlendirme üretiyor.

Somut örnekler

Aktif/pasif failover — İstanbul birincil, Frankfurt yedek

Token yetkileri: monitör ve havuz için Load Balancing: Monitors and Pools Write, load balancer için Load Balancers Write.

# 1) Monitör
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/load_balancers/monitors" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{
    "type":"https","description":"uygulama sagligi","method":"GET","path":"/healthz",
    "port":443,"timeout":5,"retries":2,"interval":60,
    "expected_codes":"2xx","expected_body":"ok",
    "consecutive_down":2,"consecutive_up":2,
    "header":{"Host":["app.ornek.com.tr"]},
    "probe_zone":"ornek.com.tr"
  }'

# 2) Havuz
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/load_balancers/pools" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{
    "name":"ist-birincil","description":"Istanbul veri merkezi",
    "monitor":"'"$MONITOR_ID"'","minimum_origins":1,
    "check_regions":["EEU","WEU","ME"],
    "origins":[{"name":"ist-1","address":"203.0.113.10","enabled":true,"weight":1,
                "header":{"Host":["app.ornek.com.tr"]}}],
    "origin_steering":{"policy":"random"}
  }'

# 3) Load balancer — steering off, havuz sırası failover sırasıdır
curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/load_balancers" \
  --request POST --header "Authorization: Bearer $CF_API_TOKEN" \
  --json '{
    "description":"IST birincil / FRA yedek","name":"app.ornek.com.tr",
    "enabled":true,"ttl":30,"proxied":true,
    "steering_policy":"off",
    "default_pools":["'"$IST_POOL"'","'"$FRA_POOL"'"],
    "fallback_pool":"'"$FRA_POOL"'",
    "adaptive_routing":{"failover_across_pools":true}
  }'

Veri yerelliği için geo steering

{
  "steering_policy": "geo",
  "default_pools": ["FRA_HAVUZ"],
  "fallback_pool": "FRA_HAVUZ",
  "country_pools": { "TR": ["IST_HAVUZ", "FRA_HAVUZ"] }
}

TR listesindeki ikinci girdi, bölgeler arası failover’ı sağlayan şey. Onsuz TR havuzu düştüğünde trafik Frankfurt’a değil, global fallback’e gider. Ve unutma: bu load balancer’da custom rules çalışmayacak.

%10 canary dağıtımı

{
  "steering_policy": "random",
  "default_pools": ["v1_havuz", "v2_havuz"],
  "random_steering": {
    "default_weight": 0.0,
    "pool_weights": { "v1_havuz": 0.9, "v2_havuz": 0.1 }
  },
  "session_affinity": "cookie",
  "session_affinity_ttl": 3600
}

Affinity, canary kullanıcısının oturum ortasında v1’e geri sıçramasını engelleyen şey.

Yol tabanlı yönlendirme

İfade:  (http.request.uri.path contains "/api/v2") and (http.request.method eq "POST")
Aksiyon: Override > Pools      -> ["api_v2_havuz"]
         Override > Terminates -> true

Enterprise olmayan planlarda load balancer hostname’i başına tek kural hakkın var.

Kesintisiz planlı bakım

Resmî prosedür: session affinity’yi aç → Endpoint drain duration gir → değişikliği kaydet → Manage Pools’tan endpoint’i devre dışı bırak → geri sayan Drain Time’ı izle → Complete olduğunda o endpoint’e bağlantı kalmamıştır.

Uyarı: “If this value is less than the Session TTL value, you will affect existing sessions.”

Demo 1: Bir origin’i kasten öldürüp failover’ı ölçmek

Amaç: monitör durumunun dönmesini, trafiğin kaymasını ve geri dönmesini doğrudan gözlemlenebilir ve zamanlanabilir kılmak.

Adım 1 — Başlangıç dağılımını ölç

for i in $(seq 1 100); do
  curl -sS -o /dev/null -D - https://app.ornek.com.tr/ \
  | tr -d '\r' | awk 'tolower($1)=="x-origin:"{print $2}'
done | sort | uniq -c

Beklenen: 100 ist-1. 5xx sayısını (0) ve %{time_starttransfer} medyanını da kaydet.

100 isteklik döngünün çıktısı; hepsinin ist-1'den geldiğini gösteren sayım

Adım 2 — Havuz sağlığını bölge bölge izle

Bu uç, bölge bölge dönüşü görmenin tek resmî yolu:

while true; do
  date -u +%H:%M:%S
  curl -sS "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/load_balancers/pools/$IST_POOL/health" \
    -H "Authorization: Bearer $CF_API_TOKEN" \
  | jq -c '.result.pop_health | to_entries[] | {bolge:.key, saglikli:.value.healthy}'
  sleep 10
done

pop_health çıktısı; her bölge için healthy durumu, origin yanıt kodu, RTT ve failure_reason

Adım 3 — Trafiği sürekli izle

while true; do
  printf '%s ' "$(date -u +%H:%M:%S)"
  curl -sS -o /dev/null -D - -w '%{http_code} %{time_starttransfer}\n' https://app.ornek.com.tr/ \
  | tr -d '\r' | awk 'tolower($1)=="x-origin:"{o=$2} /^[0-9]{3} /{print o, $0}'
  sleep 2
done | tee failover.log

Adım 4 — Origin’i kasten boz

Üç varyant, her biri farklı bir failure_reason üretiyor:

# (a) servisi durdur      -> "TCP connection failed"
ssh ist-1 'sudo systemctl stop nginx'

# (b) paketleri düşür     -> "HTTP timeout occurred"
ssh ist-1 'sudo iptables -I INPUT -p tcp --dport 443 -j DROP'

# (c) YALNIZCA /healthz'i boz, site ayakta kalsın -> "Response code mismatch error"
ssh ist-1 'sudo sed -i "s|return 200 \"ok|return 503 \"kotu|" /etc/nginx/conf.d/app.conf && sudo nginx -s reload'

Adım 5 — Gözlem sırası

pop_health döngüsünün çıktısı; bazı bölgelerin diğerlerinden önce healthy:false'a döndüğü an

Bazı bölgeler diğerlerinden önce dönüyor ve bu belgelenmiş davranış:

“You occasionally might see traffic routed away from a pool if a health monitor request fails from a specific data center (even if the endpoint is still healthy). That data center may direct a small number of requests to another pool that is considered healthy by that data center.”

Yani failover.log içinde kısa bir karışık dönem görmen normal — hata değil.

failover.log çıktısı; X-Origin değerinin ist-1'den fra-1'e döndüğü zaman damgası

Load Balancing panelinde havuzun Healthy'den Critical'a, load balancer'ın Healthy'den Degraded'a geçtiği

Traffic → Load Balancing Analytics → Logs; durum değişikliği olayı ve failure_reason alanı

Loglama konusunda önemli bir not: “Load Balancing only logs events that represent a status change for an endpoint, from healthy to unhealthy or vice versa.” Yani her prob loglanmıyor, yalnızca dönüşler.

Adım 6 — Geri dönüşü (failback) izle

Origin’i düzelt, consecutive_up sayısı kadar başarılı döngüyü bekle.

failover.log çıktısı; X-Origin'in tekrar ist-1'e döndüğü zaman damgası ve bozulmadan bu ana kadar geçen toplam süre

Bu demoda ölçülenler:

Demo 2: Session affinity’yi kontrol grubuyla kanıtlamak

Amaç: yapışkanlığı sağlayan şeyin çerez olduğunu, istemci IP’si olmadığını deneysel olarak kanıtlamak.

Kurulum: tek havuz, iki endpoint (web-a, web-b), origin_steering.policy = "random", eşit ağırlıklar, ikisi de X-Origin gönderiyor.

Adım 1 — Affinity kapalıyken başlangıç

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/load_balancers/$LB_ID" \
  --request PATCH -H "Authorization: Bearer $CF_API_TOKEN" --json '{"session_affinity":"none"}'

for i in $(seq 1 100); do
  curl -sS -o /dev/null -D - https://app.ornek.com.tr/ \
  | tr -d '\r' | awk 'tolower($1)=="x-origin:"{print $2}'
done | sort | uniq -c

Yaklaşık 50/50 dağılım gösteren sayım çıktısı ve Set-Cookie başlığında __cflb bulunmadığı

Yüz istek kullan; on istekle test edip “ağırlıklar çalışmıyor” demek yaygın bir hata.

Adım 2 — Affinity açık, çerez taşınıyor

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/load_balancers/$LB_ID" \
  --request PATCH -H "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"session_affinity":"cookie","session_affinity_ttl":1800,
           "session_affinity_attributes":{"samesite":"Auto","secure":"Auto",
                                          "drain_duration":60,"zero_downtime_failover":"sticky"}}'

rm -f kavanoz.txt
curl -sS -c kavanoz.txt -D - -o /dev/null https://app.ornek.com.tr/ \
  | tr -d '\r' | grep -Ei '^(set-cookie|x-origin)'

Set-Cookie başlığında __cflb değeri; SameSite, Secure, HttpOnly ve Expires nitelikleriyle

for i in $(seq 1 100); do
  curl -sS -b kavanoz.txt -c kavanoz.txt -o /dev/null -D - https://app.ornek.com.tr/ \
  | tr -d '\r' | awk 'tolower($1)=="x-origin:"{print $2}'
done | sort | uniq -c

Tek satırlık sayım çıktısı: 100 web-b

Adım 3 — Kontrol grubu: aynı IP, çerez yok

Demoyu kanıta dönüştüren adım budur.

for i in $(seq 1 100); do
  curl -sS -o /dev/null -D - https://app.ornek.com.tr/ \
  | tr -d '\r' | awk 'tolower($1)=="x-origin:"{print $2}'
done | sort | uniq -c

Yaklaşık 50/50 dağılım; aynı makine, aynı IP, affinity hâlâ açık — tek değişen çerezin taşınmaması

Aynı makine, aynı IP, aynı load balancer, affinity hâlâ açık. Çıkarılan tek değişken çerez. Yapışkanlık çerezden geliyor, IP’den değil.

Adım 4 — ip_cookie farkı izole et

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/load_balancers/$LB_ID" \
  --request PATCH -H "Authorization: Bearer $CF_API_TOKEN" --json '{"session_affinity":"ip_cookie"}'
# Adım 3'ü aynen tekrarla — çerez kavanozu olmadan

Çerez taşınmamasına rağmen tek origin'e yapışan dağılım

cookie ile ip_cookie arasındaki farkı ayıran tek deney budur.

Adım 5 — Header affinity ve plan sınırı

curl "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/load_balancers/$LB_ID" \
  --request PATCH -H "Authorization: Bearer $CF_API_TOKEN" \
  --json '{"session_affinity":"header","session_affinity_ttl":1800,
           "session_affinity_attributes":{"headers":["X-Kiraci"],"require_all_headers":true}}'

for i in $(seq 1 40); do curl -sS -o /dev/null -D - -H 'X-Kiraci: acme' https://app.ornek.com.tr/ \
  | tr -d '\r' | awk 'tolower($1)=="x-origin:"{print $2}'; done | sort | uniq -c
for i in $(seq 1 40); do curl -sS -o /dev/null -D - -H 'X-Kiraci: beta' https://app.ornek.com.tr/ \
  | tr -d '\r' | awk 'tolower($1)=="x-origin:"{print $2}'; done | sort | uniq -c

İki farklı X-Kiraci değeri için iki farklı origin'e yapışan dağılımlar

Sonra ikinci bir header adı eklemeyi dene — Enterprise dışı planlarda reddedilecek.

Adım 6 — Endpoint drain

Panelde devre dışı bırakılan endpoint'in yanında geri sayan Drain Time göstergesi

Çerez kavanozuyla çalıştırdığın döngü drain süresince web-b’de kalıyor; kavanozsuz döngü hemen web-a’ya geçiyor.

Drain durumu Complete olduğunda o endpoint'e bağlantı kalmadığını gösteren panel görünümü

Bu demoda ölçülenler:

Fiyatlandırma

Yayımlanan

Load Balancing her planın üstüne alınan bir eklenti. Enterprise müşteriler sözleşmesiz olarak önizleyebiliyor: “provides full access, free of metered usage fees, limits, and certain other restrictions.”

Ne faturalanabilir istek sayılıyor

“Load balancing requests are the number of uncached requests made by your load balancer. By default, Cloudflare caches resolved IP addresses for up to five seconds. This built-in caching is often the cause of a discrepancy.”

Üç maliyet kaldıracı, hepsi resmî:

• Proxy’li (L7) mod: “Reduces authoritative queries against Cloudflare, which can potentially save money.”
• DNS-only mod: “Increases authoritative queries against Cloudflare, which can potentially cost more.”
• Session affinity: “can also help reduce network requests, leading to savings.”

Limitler

Plan ve eklenti kapıları

Lisanslama ve hukuki çerçeve

Hizmet tescillidir ve Cloudflare Hizmet Şartları’na tabidir.

__cflb çerezi ve KVKK. Bu çerez teknik olarak zorunlu bir yük dengeleme çerezidir: hangi endpoint’in seçildiğini kodluyor, takip kimliği taşımıyor, HttpOnly her zaman açık ve Always Use HTTPS açıksa Secure de ekleniyor. Çerez politikanda zorunlu çerezler altında listelemen ve amacını (oturum sürekliliği) belirtmen yeterli olur. Cloudflare bu çerez için Türkiye’ye özgü hiçbir metin yayımlamamıştır.

Veri yerelliği. Geo steering ile TR trafiğini bir TR havuzuna yönlendirebiliyorsun — ama bu yalnızca origin seçimini kontrol ediyor. İstek yine en yakın Cloudflare PoP’undan geçiyor. Gerçek bölgesel işleme kontrolü için Data Localization Suite gerekiyor; Load Balancing oluşturma akışında ayrı bir “Data Localization” seçeneği var ve o ayrı bir üründür. Türkiye Regional Services bölgesi olarak destekleniyor, ama Customer Metadata Boundary Türkiye’yi desteklemiyor — ayrıntı için CDN.

Sağlık kontrolü logları. Prob istekleri origin’inin erişim loglarına düşüyor ve Cloudflare-Traffic-Manager/1.0 User-Agent’ıyla geliyorlar. Log saklama politikanda bunları hesaba kat; “All Regions” seçersen dakikada yüzlerce satır üretebilirler.

Çin ağı. China Network’e dağıtım için iki şart var: geçerli ICP lisansı ve zone’un China Network erişimine sahip olması. Kısıtlar: yalnızca çerez tabanlı session affinity, özel ağ off-ramp’leri (Tunnel, GRE, IPsec) desteklenmiyor ve Private Network Load Balancing Çin ağında yok. Ayrıntı için China Network.

Sık yapılan hatalar

Fallback havuzunu unutmak veya devre dışı bırakmak. Tüm havuzlar sağlıksızsa ve fallback de kapalıysa proxy’li modda 530 / HTTP 1016, gri bulutta SOA kaydı dönüyor.

Geo steering ile custom rule’u birlikte kullanmak. Sessizce çalışmıyor — hata mesajı yok.

Geo steering’de bölgeler arası failover beklemek. Her bölgenin listesine yedek havuzu elle eklemen gerekiyor.

Resmî hızlı başlangıçtan "steering_policy": "random_steering" kopyalamak. Geçerli değer "random". Bu bir Cloudflare doküman hatası.

All Data Centers izlemeyi seçmek. Cloudflare’in kendi ifadesi: “Do not use All-Datacenters monitoring.”

FQDN endpoint adresi kullanmak. Tek bir veri merkezindeki başarısız çözümleme sessizce yanlış yönlendirme üretiyor ve “the resolved endpoint IP will be missing from the request log.”

expected_body’yi sayfanın ilk 10 KB’ının dışına koymak.

Geo steering yapılandırmasında hâlâ geçen bir havuzu silmeye çalışmak. Önce yapılandırmadan çıkarılmalı.

Worker arkasında Hash steering kullanıp x-forwarded-for’u düzeltmemek.

Timeout’u 1-2 saniyeye ayarlamak. Sorun giderme sayfası bunu doğrudan bir arıza sebebi olarak sayıyor.

Self-signed sertifikaya HTTPS monitör bağlamak allow_insecure: true olmadan → “TLS untrusted certificate error”.

HTTPS’e yönlendiren bir origin’e HTTP monitör bağlamak → 301/302 ile “Response code mismatch error”.

LB hostname’ini Spectrum uygulama hostname’iyle aynı yapmak. DNS çözümlemesini bozuyor.

Sağlık kontrolü başarısızlığından bağlantı boşaltma beklemek. “If you need graceful connection draining, use endpoint drain to proactively take endpoints out of rotation before maintenance, rather than relying on health check failures alone.”

drain_duration’ı session TTL’inden kısa ayarlamak. Mevcut oturumları etkiliyor.

Her havuzda load shedding’i açmak. Trafik fallback havuzuna gitmeye başlıyor.