Cloudflare 520, 521, 522, 523, 524, 525 ve 526 Hataları: Anlamı ve Çözümü

Hata tablosu: kod, anlamı, en sık neden, ilk kontrol

Aşağıdaki tablo, her kodun Cloudflare belgelerindeki karşılığını özetler. Ayrıntılar tablonun altındaki bölümlerde.

Hata Cloudflare'den mi geliyor, sunucunuzdan mı?

Cloudflare belgeleri bu ayrımı birkaç yoldan yapmanızı önerir. Önce şunu bilin: 521 ile 526 arasındaki kodlar Cloudflare'in kendi ürettiği hata sayfalarıdır, çünkü sunucu ya hiç cevap vermemiş ya da cevabı kullanılamaz olmuştur. Yine de sayfayı Cloudflare'in üretmesi, sorunun Cloudflare'de olduğu anlamına gelmez; bu kodların neredeyse tamamı kaynak sunucu tarafındaki bir duruma işaret eder.

• cf-error-type başlığı: Cloudflare'in "Cloudflare error diagnostic headers" belgesine göre cf-error-type ve cf-error-origin başlıkları yalnızca Cloudflare'in ürettiği hata sayfalarında bulunur. 521 ile 526 arası için değer 52x olarak geçer. Hata yanıtında bu başlık yoksa hatayı büyük ihtimalle sunucunuz üretmiştir.
• Sayfa içeriği (500 için): Belgeye göre bir 500 hatasının HTML gövdesinde cloudflare veya cloudflare-nginx geçiyorsa Cloudflare desteğiyle, geçmiyorsa hosting firmanızla görüşmeniz gerekir.
• Markalı 502/504: Cloudflare, sunucunuz standart bir 502 veya 504 döndürdüğünde bunu Cloudflare markalı bir sayfayla gösterir. Belge, markalı 502/504'ün sunucunuzdan geldiğini, markasız boş sayfanın ise Cloudflare tarafındaki bir sorunu gösterdiğini söyler. Ayrıntılar için 502 ve 504 gateway hataları yazımıza bakın.

Başlığı görmek için tarayıcıda Geliştirici Araçları > Network sekmesinde hatalı isteği seçip Headers bölümüne bakabilir veya terminalden şu komutu çalıştırabilirsiniz:

curl -sv -o /dev/null https://www.ornek.com/ 2>&1 | grep -i -E "^< (HTTP|cf-ray|cf-error)"

Ray ID nedir, ne işe yarar?

Cloudflare, ağından geçen her isteğe bir Ray ID atar. Bu değer yanıtta cf-ray başlığı olarak döner, Cloudflare hata sayfalarının alt kısmında da yazar ve Cloudflare'den sunucunuza giden istekte de cf-ray başlığı olarak bulunur. Belgeler Ray ID'lerin her istek için benzersiz olmasının garanti edilmediğini de not eder, yani onu zaman bilgisiyle birlikte kullanın.

Ray ID'yi Cloudflare panelindeki Security Events ekranında arayabilir, sizin hesabınızda Log Explorer eklentisi varsa Observability > Logs altında sorgulayabilirsiniz. En pratik yol ise Ray ID'yi kendi sunucu günlüğünüze yazdırmaktır; böylece hata sayfasındaki Ray ID ile sunucudaki satırı eşleştirirsiniz. Cloudflare belgesindeki değişkenlerle örnek:

# Apache (httpd.conf veya sanal host)
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{CF-Ray}i\"" cfray
CustomLog logs/access_log cfray

# Nginx (http bloğu)
log_format cfray '$remote_addr - [$time_local] "$request" $status $body_bytes_sent "$http_cf_ray"';
access_log /var/log/nginx/access.log cfray;

Kaynak sunucuyu Cloudflare'i atlayarak test edin

Hatanın sunucuda mı, aradaki yolda mı olduğunu anlamanın en hızlı yolu, sunucuya Cloudflare olmadan bağlanmaktır. Cloudflare'in "Gathering information for troubleshooting sites" belgesi bunun için curl'ün --connect-to seçeneğini gösterir. Alan adı aynı kalır, sadece bağlantı doğrudan sunucu IP'sine gider. Aşağıda 203.0.113.34 yerine kendi sunucu IP'nizi yazın (IP'yi hosting panelinizde veya Cloudflare DNS kaydınızda bulursunuz):

# HTTP üzerinden doğrudan sunucuya
curl -svo /dev/null http://www.ornek.com/ --connect-to ::203.0.113.34

# HTTPS üzerinden doğrudan sunucuya (sertifikayı da gösterir)
curl -svo /dev/null https://www.ornek.com/ --connect-to ::203.0.113.34

# Aynı testin --resolve ile yazımı (port belirtilir)
curl -svo /dev/null https://www.ornek.com/ --resolve www.ornek.com:443:203.0.113.34

--resolve, curl'ün kendi seçeneğidir (curl man sayfası): verilen ad ve port için DNS yerine sizin yazdığınız IP'yi kullanır, SNI ve Host başlığı yine alan adınız olur. Doğrudan testte de hata alıyorsanız sorun sunucudadır ve hosting firmanıza gitmelisiniz. Doğrudan test temiz geçiyor ama Cloudflare üzerinden hata alıyorsanız, sunucunun Cloudflare IP'lerine farklı davrandığından (güvenlik duvarı, hız sınırı) veya Cloudflare ayarlarından şüphelenin.

Tarayıcıda test etmek isterseniz kendi bilgisayarınızdaki hosts dosyasına geçici bir satır ekleyebilirsiniz (Windows'ta C:\Windows\System32\drivers\etc\hosts, macOS ve Linux'ta /etc/hosts). Bu değişiklik yalnızca sizin bilgisayarınızı etkiler; işiniz bitince satırı silin.

203.0.113.34  www.ornek.com

520: sunucudan boş veya beklenmeyen yanıt

520, belgeye göre kaynak sunucunun Cloudflare'e "boş, bilinmeyen veya beklenmeyen" bir yanıt döndürdüğü durumdur. Bir tür genel kategori olduğu için nedenleri geniştir:

• Sunucu veya uygulama çöküyor ya da yanlış yapılandırılmış; PHP uygulamaları sık görülen bir tetikleyicidir.
• Güvenlik duvarı veya güvenlik eklentisi Cloudflare IP'lerini engelliyor.
• 128 KB'ı aşan header'lar; belge bunun çoğunlukla aşırı cookie'den kaynaklandığını söyler.
• Durum kodu veya gövdesi olmayan boş ya da bozuk yanıtlar, eksik yanıt başlıkları.
• Sunucuda hatalı HTTP/2 yapılandırması.
• Cloudflare tarafında Authenticated Origin Pulls açık ama sunucu istemci sertifikasını kabul edecek şekilde ayarlı değil.

Sunucu HTTP/2 kabul ediyor ama düzgün desteklemiyorsa, belgeye göre HTTP/2 to Origin ayarını Cloudflare panelinde Speed > Settings > Protocol Optimization altından kapatabilirsiniz. Cookie şişmesi şüphesi varsa tarayıcının Geliştirici Araçları > Application bölümünde alan adınıza ait cookie'lere bakın; bir eklentinin sürekli büyüyen cookie yazması tipik bir örnektir. Sunucu tarafındaki PHP hataları için 500 Internal Server Error çözümü yazımızdaki günlük kontrolleri burada da işe yarar.

Cloudflare analizinde sunucunun 200 döndürdüğünü ama kenarda (edge) 520 verildiğini görüyorsanız, belgeye göre yanıt büyük ihtimalle bozuktur; örneğin aşırı büyük header veya bağlantının erken kapanması.

521: web sunucusu bağlantıyı reddediyor

521, Cloudflare'in sunucunuza ulaşabildiğini ama web sunucusunun bağlantıyı reddettiğini gösterir. İki ana neden vardır: web sunucusu veya uygulama kapalı ya da çökmüş, veya sunucu Cloudflare'in isteklerini engelliyor. Belgedeki kontrol listesi:

• Web sunucusunun (Apache, Nginx, LiteSpeed) çalıştığını ve yanıt verdiğini doğrulayın.
• Sunucunun hata günlüklerinde çökme veya kesinti izi arayın.
• Cloudflare IP adreslerinin engellenmediğinden veya hız sınırına takılmadığından emin olun; IP aralıklarını güvenlik duvarında izinli yapın.
• SSL/TLS modu Full veya Full (strict) ise sunucunun HTTPS desteklediğini doğrulayın; gerekiyorsa Cloudflare Origin CA sertifikası veya bu modların şartlarını karşılayan başka bir sertifika kurun.
• Sunucunun doğru portu dinlediğini kontrol edin: Flexible için 80, Full ve Full (strict) için 443.

Cloudflare IP aralıkları zaman zaman değiştiği için onları elle kopyalamak yerine güncel listeyi Cloudflare IP ranges sayfasından alın. Bu sayfa düz metin listelere de bağlantı verir. Örneğin UFW kullanan bir Ubuntu sunucuda listeyi her seferinde kaynaktan okuyarak 80 ve 443 için izin verebilirsiniz:

for ip in $(curl -s https://www.cloudflare.com/ips-v4/) $(curl -s https://www.cloudflare.com/ips-v6/); do
  sudo ufw allow proto tcp from "$ip" to any port 80,443
done
sudo ufw status numbered

cPanel sunucularda CSF, Imunify360 veya ModSecurity gibi araçlar Cloudflare IP'lerini "çok fazla istek atan" adresler olarak engelleyebilir. Paylaşımlı hostingde bu ayara genelde siz erişemezsiniz; hosting firmanızdan Cloudflare aralıklarının izinli olduğunu teyit etmesini isteyin. UFW için daha fazla örnek UFW güvenlik duvarı rehberinde.

522: bağlantı zaman aşımı

522, Cloudflare'in sunucuya bağlanmaya çalışırken zaman aşımına uğradığı anlamına gelir. Belge iki aşamayı ayırır: TCP bağlantısı kurulmadan önce Cloudflare, SYN gönderdikten sonra 19 saniye boyunca SYN+ACK bekler; bağlantı kurulduktan sonra ise gönderdiği isteğin onayını (ACK) 90 saniye bekler.

Belgeye göre en sık neden, Cloudflare IP'lerinin .htaccess, iptables veya güvenlik duvarında engellenmesi ya da hız sınırına takılmasıdır. Diğer nedenler:

• Sunucu aşırı yüklü veya kapalı olduğu için istekleri düşürüyor.
• Sunucuda keepalive kapatılmış.
• Cloudflare DNS'teki sunucu IP'si, hosting firmanızın şu an verdiği IP ile eşleşmiyor (taşıma sonrası sık görülür).
• Paketler sunucuda düşürülüyor.

Hosting değiştirdiyseniz ilk iş Cloudflare panelinde DNS kayıtlarını açıp A ve AAAA kayıtlarının yeni sunucu IP'sini gösterdiğini kontrol edin. Eski bir AAAA (IPv6) kaydı unutulmuşsa bazı istekler o adrese gidebilir. DNS kayıt türleri için A, CNAME, MX, TXT kayıtları yazısına bakabilirsiniz. Coğrafi kısıtlama yapmak istiyorsanız, belgenin önerdiği gibi Cloudflare IP'lerini engellemek yerine bir WAF custom rule kullanın.

523: sunucuya ulaşılamıyor

523, Cloudflare'in sunucunuzla hiç temas kuramadığını gösterir. Belgeye göre tipik neden, Cloudflare ile sunucu arasındaki bir ağ cihazının sunucu IP'sine giden yolu (route) bilmemesidir. Önce Cloudflare DNS'teki A veya AAAA kaydında doğru IP olduğunu doğrulayın, ardından sunucu ile Cloudflare arasında bir yönlendirme sorunu olup olmadığını inceleyin. AWS kullanıyorsanız belge, 172.0.0.0/8 gibi geniş bir VPC route girdisinin Cloudflare'in 172.64.0.0/13 aralığını yutabileceğini ve bu aralık için İnternet Gateway'e giden daha belirgin bir route eklenebileceğini belirtir.

524: sunucu zamanında yanıt vermedi

524'te bağlantı kurulmuştur ama sunucu, Cloudflare'in bekleme süresi içinde yanıt göndermemiştir. Pek çok eski kaynakta bu süre 100 saniye olarak geçer; ancak Ekim 2026 itibarıyla Cloudflare'in Error 524 belgesinde varsayılan Proxy Read Timeout 125 saniye olarak yazılıdır. Proxy Write Timeout ise 30 saniyedir (Cloudflare Images için 6,5 saniye) ve değiştirilemez.

Okuma zaman aşımını yalnızca Enterprise müşteriler 6.000 saniyeye kadar artırabilir. Belgede iki yol var: Proxy Read Timeout ayarını içeren bir Cache Rule (kuralın tetiklenmesi için içeriğin önbelleğe alınabilir olması gerekir, gerçekten önbellekte olması gerekmez) ya da API üzerinden proxy_read_timeout zone ayarı. Belge ayrıca hatanın ayarlı sürenin yaklaşık 1 saniye sonrasında görünebileceğini, bu yüzden süreyi 1 saniye fazla (örneğin 125 yerine 126) ayarlamayı önerir. Free, Pro ve Business planlarda bu süre değiştirilemez; çözüm sunucu tarafındadır.

• Uzun süren raporlama, dışa aktarma veya yedekleme işlemlerini tek bir HTTP isteğinde beklemek yerine arka planda çalıştırıp durumunu kısa isteklerle sorgulayın (polling).
• Sunucuda yanıt sürelerini günlüğe yazıp hangi adreslerin yavaş olduğunu bulun; yavaş veritabanı sorguları ilk şüphelidir.
• Sunucu kaynakları yetmiyorsa (CPU, RAM, giriş/çıkış sınırı) hosting firmanızdan aşırı yük ve uzun süren süreçleri kontrol etmesini isteyin.
• Önbelleğe alınabilen sayfaları önbellekten sunun; LiteSpeed Cache ve Cloudflare Cache Rules sunucuya giden istek sayısını azaltır.

Belge, düzenli olarak 125 saniyeyi aşan istekler için (büyük dışa aktarmalar gibi) bu işleri DNS only (gri bulut) bir alt alan adına taşımayı da önerir. Bunu yaparsanız o alt alan adının IP'si, yani büyük ihtimalle ana sunucunuzun IP'si herkese görünür olur. Bu yolu ancak alt alan adı ayrı bir sunucudaysa veya yalnızca yönetici IP'lerine açıksa düşünün. Yavaşlık konusunda web sitesi yavaş açılıyor yazımız da yardımcı olur.

525 ve 526: SSL el sıkışması ve geçersiz sertifika

525 (SSL handshake failed), SSL modu Full veya Full (strict) iken Cloudflare ile sunucu arasındaki TLS el sıkışmasının başarısız olduğunu gösterir. Belgedeki olası nedenler: sunucuda geçerli SSL sertifikası yok, 443 (veya kullandığınız özel güvenli port) kapalı, sunucu SNI desteklemiyor ya da Cloudflare'in şifre takımlarıyla (cipher suites) sunucununkiler uyuşmuyor. Aralıklı 525'lerde hatanın görüldüğü saatlerdeki Apache mod_ssl veya Nginx hata günlüklerine bakın.

526 (Invalid SSL certificate), Full (strict) modunda sunucu sertifikasının doğrulanamadığını gösterir. Belgeye göre sertifika şu şartları karşılamalıdır:

• Süresi dolmamış ve iptal edilmemiş olmalı.
• Kendinden imzalı değil, bir sertifika otoritesi tarafından imzalanmış olmalı (Cloudflare Origin CA sertifikası da kabul edilir).
• Alan adı Common Name veya Subject Alternative Name içinde yer almalı.
• Sunucu tam zinciri, yani sitenin sertifikasıyla birlikte ara sertifikaları da göndermeli.
• Sunucu 443 portunda bağlantı kabul etmeli.

Sunucunun gerçekte hangi sertifikayı sunduğunu yukarıdaki doğrudan bağlantı testiyle görebilirsiniz:

curl -svo /dev/null https://www.ornek.com/ --connect-to ::203.0.113.34 2>&1 | grep -i -E "subject|issuer|expire|SSL certificate"

Belge 526 için hızlı geçici çözüm olarak modu Full (strict)'ten Full'a almayı listeler. Full modu sertifikayı doğrulamadığı için bunu yalnızca birkaç dakikalık bir ara çözüm olarak görün; sunucuya ücretsiz bir Let's Encrypt veya Cloudflare Origin CA sertifikası kurup Full (strict)'e geri dönün. cPanel'de sertifika yenileme ve kurulum için Let's Encrypt SSL kurulumu, sertifika hatalarının genel teşhisi için SSL sertifika hataları yazılarımıza bakın.

530 ve 1xxx hataları

530, Cloudflare'in kaynak sunucunun hostname'ini çözümleyemediği için ona bağlanamadığını gösterir. Belge bunu genel bir kategori olarak tanımlar: asıl neden, yanıt gövdesindeki 1xxx kodunda yazar ve o kodun kendi sorun giderme sayfasına bakmanız gerekir. Diagnostic headers belgesine göre örneğin 1000 bir A kaydının Cloudflare IP'sini gösterdiği DNS hatası, 1016 ise CNAME hedefinin çözümlenmediği bir origin DNS hatasıdır. Her iki durumda da Cloudflare DNS kayıtlarınızı kontrol edin. DNS temelleri için DNS nedir yazısına göz atabilirsiniz.

Hosting firmanıza ne göndermelisiniz?

Cloudflare belgeleri 5xx hatalarının çoğunda ilk adım olarak hosting firmanıza veya site yöneticinize başvurmanızı önerir ve şu bilgileri istemenizi söyler. Destek talebinizi bu bilgilerle açarsanız sorun çok daha hızlı çözülür:

• Hata kodu ve mesajı (örneğin "Error 522 Connection timed out").
• Hatanın oluştuğu saat ve saat dilimi (örneğin 31.10.2026 14:05, UTC+3).
• Hatayı veren tam URL.
• Hata sayfasındaki Ray ID (cf-ray).
• Doğrudan sunucuya yaptığınız curl testinin çıktısı (hatayı sunucunun kendisinin verip vermediğini gösterir).
• 522 ve 523 için: belgenin istediği gibi, sunucudan yakın zamanda bağlanmış bir Cloudflare IP'sine MTR veya traceroute çıktısı. Bu IP'yi sunucu günlüklerinden bulabilirler.

Belge ayrıca hatanın nedeninin her zaman sunucunun kendi hata günlüğünde görünmeyebileceğini, Cloudflare ile sunucu arasındaki yük dengeleyici, önbellek, proxy veya güvenlik duvarı günlüklerinin de incelenmesi gerektiğini belirtir. Sorun sürerse Cloudflare desteğine giderken 520 için belgenin istediği ek bilgiler şunlardır: hatalı URL'ler, cf-ray değeri, alan adınızdaki /cdn-cgi/trace çıktısı ve biri Cloudflare açıkken, biri geçici olarak kapalıyken alınmış iki HAR dosyası. HAR dosyası hassas veri içerebilir; belge göndermeden önce temizlemenizi önerir.

Panelden hata dağılımını görmek için belge, paneldeki HTTP Traffic sayfasında Add filter ile Edge status code veya Origin status code filtresi ekleyip ilgili 5xx kodunu seçmeyi tarif eder. Bu veriler trafiğin yüzde 1'lik bir örneklemine dayanır.

Sık Sorulan Sorular

Cloudflare hata sayfası gösteriyorsa sorun Cloudflare'de mi?

Genellikle hayır. 520 ile 526 arasındaki sayfaları Cloudflare üretir ama Cloudflare belgelerine göre nedenlerin büyük kısmı kaynak sunucu tarafındadır: kapalı web sunucusu, Cloudflare IP'lerini engelleyen güvenlik duvarı, yavaş yanıt veya hatalı sertifika. Doğrudan sunucuya curl testi yaparak bunu birkaç saniyede ayırt edebilirsiniz.

524 süresini Free planda uzatabilir miyim?

Hayır. Error 524 belgesine göre Proxy Read Timeout'u yalnızca Enterprise müşteriler (6.000 saniyeye kadar) değiştirebilir. Diğer planlarda varsayılan süre (Ekim 2026 itibarıyla belgede 125 saniye) geçerlidir; uzun işlemleri arka plana alıp kısa isteklerle durum sorgulamak en sağlıklı çözümdür.

521 ile 522 arasındaki fark nedir?

521'de sunucu bağlantıyı aktif olarak reddeder (web sunucusu kapalı veya Cloudflare engelleniyor). 522'de ise bağlantı denemesi cevapsız kalır ve zaman aşımına uğrar; çoğunlukla güvenlik duvarının paketleri sessizce düşürmesi, aşırı yük veya DNS'te yanlış IP söz konusudur.

Sorunu çözmek için turuncu bulutu kapatmalı mıyım?

Kalıcı çözüm olarak hayır. Kaydı DNS only yapmak sunucu IP'nizi herkese açar ve Cloudflare'in koruma ile önbelleğini devre dışı bırakır. Teşhis için curl --connect-to / --resolve veya hosts dosyası yöntemini kullanın, sorunu sunucuda düzeltin ve proxy'yi açık tutun.

Ray ID'yi nerede bulurum?

Cloudflare hata sayfasının alt kısmında yazar; ayrıca her yanıtta cf-ray başlığı olarak döner. Tarayıcının Geliştirici Araçları > Network sekmesinden veya curl -sv çıktısından görebilirsiniz.

Cloudflare ve adı geçen diğer hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; Cloudflare ile ortaklık veya bayilik ilişkisi bulunduğu anlamına gelmez.

İlgili içerikler: Cloudflare nasıl kurulur · Cloudflare SSL modları · Proxied ve DNS only · Gerçek ziyaretçi IP adresi · 502 ve 504 hataları · ERR_CONNECTION_REFUSED ve TIMED_OUT