Cloudflare 520, 521 ve 522 Hataları Nedir, Nasıl Çözülür?

Sitenizi açtığınızda karşınıza turuncu bulut logolu, ortasında kocaman bir sayı olan bir sayfa çıkıyor: Error 520, Error 521 Web server is down ya da Error 522 Connection timed out. Sayfanın en can sıcıcı tarafı, hatanın Cloudflare markasıyla gelmesi ve ilk anda "Cloudflare çöktü" izlenimi vermesi. Oysa bu üç kod da tam tersini söyler: Cloudflare ayaktadır, ziyaretçinin isteğini almıştır ve sizin sunucunuza ulaşmaya çalışırken sorun yaşamıştır. Yani arıza neredeyse her zaman origin sunucu tarafındadır.

Bu yazıda üç kodun birbirinden farkını, hangisinin hangi arızaya işaret ettiğini ve en sık karşılaşılan senaryoyu — sunucu güvenlik duvarının Cloudflare IP bloklarını engellemesi — adım adım çözmeyi anlatacağım. Ayrıca origin sunucuyu Cloudflare'i devre dışı bırakmadan test etmeyi, hangi komutla neyi doğrulayacağınızı ve hatanın bir daha çıkmaması için ne yapmanız gerektiğini göstereceğim. Yıllardır gördüğüm dağılım şu: 521'lerin çoğu web sunucusunun durması ya da yanlış portun dinlenmesi, 522'lerin ise ezici çoğunluğu güvenlik duvarı veya brute force koruması kaynaklıdır.

Cloudflare 5xx Hataları Kime Ait#

Cloudflare kendi ürettiği hata sayfalarında sorumluluğu iki kutuya ayırır: "Cloudflare" ve "Host". 520, 521, 522, 523, 524 kodlarının hepsinde işaretli kutu Host, yani sizin sunucunuzdur. Bu ayrımı en baştan oturtmak önemlidir, çünkü ilk refleks çoğu zaman Cloudflare panelinde ayar kurcalamak olur ve orada geçirilen her dakika boşadır.

Cloudflare, proxy modu açık (turuncu bulut) bir alan adında iki ayrı bağlantı yönetir. Birincisi ziyaretçi ile Cloudflare arasındaki bağlantıdır; bu bağlantı kurulmuştur, kanıtı da hata sayfasının size ulaşmasıdır. İkincisi Cloudflare ile sizin origin sunucunuz arasındaki bağlantıdır ve 5xx kodları bu ikinci bacaktaki sorunu anlatır. Mimarinin genel işleyişini hiç kurmadıysanız Cloudflare DNS ve CDN yazısı bu iki bacağın nasıl çalıştığını açıklıyor.

Buradan çıkan pratik sonuç şudur: bu hataları çözmek için Cloudflare hesabınıza değil, sunucunuza SSH ile bağlanmanız gerekir. Panel üzerinden yapılabilecek tek anlamlı şey, teşhis sırasında proxy'yi geçici olarak kapatıp origin'in doğrudan cevap verip vermediğini görmektir.

520, 521 ve 522 Arasındaki Fark#

Üç kod da "origin'e ulaşamadım" der ama ulaşamama biçimleri farklıdır ve bu fark doğrudan çözümü belirler.

521 ile 522 arasındaki ayrım kritiktir ve tek cümleyle özetlenebilir: 521'de sunucu "hayır" der, 522'de sunucu hiç cevap vermez. Bir güvenlik duvarı kuralı REJECT ise 521, DROP ise 522 alırsınız. Aynı şekilde web sunucusu servisi durmuşsa çekirdek o porta gelen bağlantıyı reddeder ve 521 çıkar; ama paket sunucuya hiç varmıyorsa ya da varıp sessizce düşürülüyorsa 522 çıkar.

520 ise diğer ikisinden farklı bir hayvandır: bağlantı kurulmuştur, sunucu bir şeyler göndermiştir ama gönderdiği şey geçerli bir HTTP yanıtı değildir. Boş yanıt, aşırı büyük çerez veya başlık, ya da işlemin ortasında kapanan bir bağlantı bu koda yol açar.

Error 521: Web Server Is Down#

521, Cloudflare'in origin sunucunuza bağlanmaya çalıştığını ve açık bir red aldığını söyler. Bu, sunucunun ayakta olduğu ama ilgili portta kimsenin dinlemediği anlamına gelir; makine tamamen kapalı olsaydı genellikle 522 alırdınız.

Sunucuya bağlanıp önce servisin durumuna bakın:

sudo systemctl status nginx
sudo systemctl status apache2   # Debian/Ubuntu
sudo systemctl status httpd     # AlmaLinux/Rocky

# Hangi servis hangi portu dinliyor
sudo ss -tlnp | grep -E ':(80|443)\s'

ss çıktısında 443 satırı hiç yoksa web sunucusu HTTPS dinlemiyordur ve Cloudflare "Full" modda origin'e 443'ten bağlanmaya çalıştığı için red alır. Çıktı şöyle görünmelidir:

LISTEN 0 511 0.0.0.0:80   0.0.0.0:* users:(("nginx",pid=812,fd=6))
LISTEN 0 511 0.0.0.0:443  0.0.0.0:* users:(("nginx",pid=812,fd=8))

Servis çalışıyor ama yine 521 alıyorsanız üç ihtimal kalır. Birincisi, sunucu yalnızca 127.0.0.1 üzerinde dinliyordur; çıktıda 127.0.0.1:443 görüyorsanız dışarıdan gelen bağlantılar reddedilir. İkincisi, güvenlik duvarında ilgili port için REJECT kuralı vardır. Üçüncüsü, servis bir yapılandırma hatası yüzünden başlarken düşmüştür — bunu sudo nginx -t ya da sudo apachectl configtest ile hemen görürsünüz.

521 aldığınızda kontrol edilecek son şey SSL modudur. Cloudflare panelinde SSL/TLS modu Full veya Full (strict) ise Cloudflare origin'e 443 portundan HTTPS ile bağlanır; sunucunuzda yalnızca 80 açıksa red alırsınız. Ya origin'e sertifika kurun ya da moda uygun portu açın. Aynı arızanın tarayıcı tarafındaki kuzeni ERR_CONNECTION_REFUSED hatası yazısında ele alınıyor.

Error 522: Güvenlik Duvarı Cloudflare IP'lerini Engelliyor#

522, Cloudflare'in origin'e paket gönderdiğini ve hiçbir cevap alamadığını söyler. Paketler bir yerde sessizce düşürülmüştür. Türkiye'deki sunucularda bu kodun bir numaralı nedeni, sunucu güvenlik duvarının ya da brute force korumasının Cloudflare'in IP bloklarını engellemesidir.

Neden olur? Çünkü proxy açıkken sunucunuza gelen tüm trafik Cloudflare'in sınırlı sayıdaki IP bloğundan gelir. Sitenizde saniyede yüzlerce istek varsa, sunucu tarafındaki bir hız sınırlayıcı ya da Fail2ban kuralı bu IP'leri "saldırgan" gibi görüp engelleyebilir. Engellenen tek bir Cloudflare IP'si, o IP'ye düşen tüm ziyaretçilerin 522 almasına yol açar — ve arıza kısmi olduğu için "bazı kullanıcılarda açılıyor, bazılarında açılmıyor" gibi kafa karıştırıcı bir tablo oluşur.

Önce engelin var olup olmadığını doğrulayın:

# Fail2ban engelleri
sudo fail2ban-client status
sudo iptables -L -n | grep -c DROP

# Son düşürülen paketleri görmek (kural loglama açıksa)
sudo journalctl -k | tail -n 50

# Belirli bir Cloudflare IP'si engelli mi
sudo iptables -L INPUT -n --line-numbers | grep 172.68.

Kalıcı çözüm, Cloudflare IP bloklarını güvenlik duvarında beyaz listeye almaktır. UFW kullanıyorsanız yaklaşım şudur — IP listesini Cloudflare'in yayımladığı güncel listeden alıp uygulayın:

# Örnek: elinizdeki güncel Cloudflare IPv4 bloklarını bir dosyaya koyup uygulayın
while read -r cidr; do
  [ -z "$cidr" ] && continue
  sudo ufw allow from "$cidr" to any port 80,443 proto tcp
done < /root/cloudflare-ipv4.txt

sudo ufw reload
sudo ufw status numbered

iptables ile çalışıyorsanız aynı mantık şöyle kurulur:

# Cloudflare bloklarını en üste ekleyip diğer kuralların önüne geçirin
sudo iptables -I INPUT -p tcp -s 198.51.100.0/24 -m multiport --dports 80,443 -j ACCEPT
sudo iptables-save > /etc/iptables/rules.v4

Kural sırasının önemi büyüktür: ACCEPT kuralları, engelleme kurallarından önce gelmelidir; iptables ilk eşleşen kuralda karar verir. Güvenlik duvarı mantığını tazelemek isterseniz UFW güvenlik duvarı ve iptables ile güvenlik duvarı yazıları kural sırası dahil temelleri anlatıyor.

Fail2ban tarafında ise Cloudflare bloklarını ignoreip listesine ekleyin. /etc/fail2ban/jail.local içinde:

[DEFAULT]
ignoreip = 127.0.0.1/8 ::1 198.51.100.0/24 203.0.113.0/24
bantime  = 3600
findtime = 600
maxretry = 5

Değişiklikten sonra sudo systemctl restart fail2ban çalıştırın. Yapılandırma ayrıntıları için Fail2ban kurulumu yazısına bakabilirsiniz. cPanel/WHM sunucularında ek olarak cPHulk ve ModSecurity de aynı işi yapabilir; WHM güvenlik cPHulk ekranındaki History Reports bölümü hangi IP'nin ne zaman engellendiğini gösterir.

522'nin ikinci yaygın nedeni sunucunun aşırı yüklenmesidir. Yük ortalaması tavan yapmışsa ya da tüm PHP-FPM işçileri meşgulse, sunucu yeni bağlantıyı kabul edemez ve Cloudflare zaman aşımına düşer. uptime, htop ve ss -s çıktıları bu durumu birkaç saniyede ortaya koyar; kalıcı yavaşlık söz konusuysa site neden yavaş açılıyor yazısındaki ölçüm adımları işe yarar.

Error 520: Beklenmedik Yanıt#

520, üçlünün en belirsizidir ve Cloudflare bunu bilerek "unknown error" olarak tanımlar. Anlamı şudur: bağlantı kuruldu, sunucu bir şey gönderdi ama gönderilen şey geçerli bir HTTP yanıtı değildi.

Pratikte dört tipik neden vardır:

1. Sunucu bağlantıyı ortada kesti. PHP-FPM işçisi segfault verdiyse ya da bellek limitine çarptıysa Nginx boş yanıt döndürür. Bu durumda çoğu zaman aynı anda 502 Bad Gateway hatası da görürsünüz.
2. Yanıt başlıkları çok büyük. Aşırı büyümüş oturum çerezleri ya da çok sayıda Set-Cookie başlığı Cloudflare'in başlık limitini aşabilir.
3. Boş yanıt gövdesi. Uygulama 200 döndürüp hiçbir içerik göndermiyorsa bu geçersiz sayılabilir.
4. Yanlış yapılandırılmış bir ters vekil. Origin'de ayrıca bir Nginx ters vekil katmanı varsa ve arkadaki uygulama düşmüşse, zincirin herhangi bir halkası bozuk yanıt üretebilir; Nginx reverse proxy yapılandırma yazısı doğru başlık aktarımını anlatıyor.

Teşhis için origin'in ham yanıtına bakmak gerekir:

# Sunucunun kendi üzerinde, Cloudflare'i atlayarak
curl -sv -H "Host: ornekalanadi.com" http://127.0.0.1/ -o /dev/null

# Hata günlüklerini eş zamanlı izleyin
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/php-fpm/www-error.log

Günlükte upstream prematurely closed connection ya da signal 11 (SIGSEGV) gibi satırlar görüyorsanız neden PHP tarafındadır. Bellek limiti hikâyesi ise ayrı bir başlıktır ve memory_limit ayarı, çok tüketen bir eklenti ya da kontrolsüz bir döngü tarafından tetiklenir.

Origin Sunucuyu Cloudflare'i Kapatmadan Test Etmek#

Teşhis sırasında en sık yapılan hata, proxy'yi (turuncu bulutu) kapatıp beklemektir. Bu hem DNS yayılımı yüzünden dakikalar alır hem de origin IP'nizi açığa çıkarır. Daha temiz yol, curl ile Cloudflare'i atlayıp doğrudan origin'e istek atmaktır:

# Origin IP'si 203.0.113.10 varsayımıyla
curl -sv --resolve ornekalanadi.com:443:203.0.113.10 https://ornekalanadi.com/ -o /dev/null
curl -sv --resolve ornekalanadi.com:80:203.0.113.10  http://ornekalanadi.com/  -o /dev/null

--resolve parametresi DNS'i yok sayıp isteği belirttiğiniz IP'ye gönderir ama Host başlığını ve TLS'deki sunucu adını doğru tutar; yani sanal host eşleşmesi bozulmaz. Sonucu şöyle yorumlayın:

• Bu komut da başarısızsa sorun kesinlikle origin'dedir ve Cloudflare'de ayar kurcalamanın anlamı yoktur.
• Bu komut çalışıyor ama site 522 veriyorsa origin sizin bulunduğunuz ağdan erişilebilir ama Cloudflare'in IP'lerinden erişilemiyor demektir. Bu, güvenlik duvarı beyaz listesi senaryosunu neredeyse kesinleştirir.

Ağ katmanında nerede takıldığını görmek için yol izleme de yararlıdır; ağ tanılama ping traceroute mtr yazısı bu araçların çıktısını okumayı anlatıyor. Bağlantının hiç kurulmadığı genel durumlar için ERR_CONNECTION_TIMED_OUT hatası yazısı da tamamlayıcıdır.

Cloudflare Panelinde Kontrol Edilecekler#

Arıza origin'de olsa da panel tarafında birkaç yapılandırma yanlışı bu hataları tetikleyebilir. Sırayla bakın.

DNS kaydındaki IP. DNS sekmesinde alan adının A kaydı gerçekten origin sunucunuzun güncel IP'sine mi bakıyor? Sunucu taşıdıysanız ve kaydı güncellemediyseniz Cloudflare eski, artık yanıt vermeyen bir makineye bağlanmaya çalışır ve 522 üretir.

SSL/TLS modu. Modun "Full (strict)" olması, origin'de geçerli bir sertifika bulunmasını zorunlu kılar. Sertifika yoksa ya da süresi dolmuşsa Cloudflare origin'e bağlanamaz. "Flexible" moda geçmek geçici bir çözüm gibi görünür ama Cloudflare ile sunucunuz arasını şifresiz bırakır ve WordPress gibi uygulamalarda sonsuz yönlendirme döngüsü üretir. Doğru çözüm origin'e sertifika kurmaktır.

Port. Cloudflare proxy'si yalnızca belirli portları vekiller. Uygulamanız standart dışı bir portta (örneğin 8080) çalışıyorsa ve DNS kaydı turuncu bulutluysa istek origin'in 80/443 portuna gider, orada kimse dinlemediği için 521 alırsınız. Bu durumda ya origin'de bir ters vekil kurup 80/443'ü uygulamaya yönlendirin ya da Cloudflare'in desteklediği portlardan birini kullanın.

Yeni eklenen kurallar. WAF kuralları, Rate Limiting ve Origin Rules bölümlerine son 24 saatte eklenen bir kayıt varsa geri alıp test edin. Özellikle Origin Rules ile portu veya origin adresini değiştiren kurallar sessiz biçimde 521 üretebilir.

Hata Bir Daha Çıkmasın: Kalıcı Önlemler#

Bu üç hatanın tekrarını önlemenin yolu, origin tarafını Cloudflare'in çalışma biçimine göre yapılandırmaktan geçer. Beş kalıcı önlem sıralayayım.

1. Cloudflare IP bloklarını güvenlik duvarında kalıcı olarak izinli tutun ve bu listeyi otomatik güncelleyen bir görev yazın. Listeler nadiren değişir ama değiştiğinde haberiniz olmaz; aylık çalışan bir cron görevi yeterlidir. Aynı işi çok sunuculu bir ortamda tek merkezden yapmak isterseniz Ansible ile sunucu otomasyonu yaklaşımı işinizi kolaylaştırır.
2. Fail2ban ve benzeri araçların gerçek ziyaretçi IP'sini görmesini sağlayın. Web sunucusunda real_ip yapılandırmasını Cloudflare bloklarına göre kurarsanız, engelleme kararları ziyaretçinin gerçek IP'sine göre verilir ve Cloudflare IP'leri asla engellenmez. Bu, 522 sorununu kökten bitiren tek ayardır.
3. Servisleri izleyin. Web sunucusu ve PHP-FPM için systemd yeniden başlatma politikası tanımlayın; bir çöküşte servis kendiliğinden ayağa kalksın. Ayrıca dışarıdan bir uptime izlemesi kurup 521/522 anında haberdar olun.
4. Origin'e geçerli sertifika kurun ve Full (strict) modda kalın. Bu hem güvenlik hem kararlılık kazandırır; sertifikanın süresi dolduğunda 521/526 almamak için otomatik yenilemeyi doğrulayın.
5. Kaynak yeterliliğini gözden geçirin. Trafik büyüdükçe 522'ler yük kaynaklı olmaya başlar. Yük ortalaması sürekli çekirdek sayısının üzerindeyse, ayar değil kapasite sorununuz vardır.

Sıkça Sorulan Sorular#

Cloudflare 521 hatası Cloudflare'in çökmesi anlamına mı gelir#

Hayır, tam tersine Cloudflare'in sorunsuz çalıştığını gösterir. Hata sayfasının size ulaşabilmesi, ziyaretçi ile Cloudflare arasındaki bağlantının kurulduğunun kanıtıdır. 521, Cloudflare'in sizin origin sunucunuza bağlanmayı denediğini ve açık bir red aldığını söyler. Dolayısıyla çözüm Cloudflare panelinde değil, sunucunuzda web servisinin çalışıp çalışmadığını ve doğru portu dinleyip dinlemediğini kontrol etmekten geçer.

521 ile 522 arasındaki fark nedir#

Fark, sunucunuzun Cloudflare'e nasıl karşılık verdiğidir. 521'de sunucu bağlantıyı açıkça reddeder, yani ağ düzeyinde bir red paketi döner; bu genellikle web sunucusunun durduğunu ya da o portu dinlemediğini gösterir. 522'de ise sunucudan hiçbir cevap gelmez ve Cloudflare beklemekten vazgeçer; bu da paketlerin sessizce düşürüldüğü anlamına gelir ve en sık nedeni güvenlik duvarının Cloudflare IP'lerini engellemesidir. İkisinin çözümü tamamen farklı olduğu için kodu doğru okumak zaman kazandırır.

Sitem bazı kullanıcılarda açılıyor bazılarında 522 veriyor, neden#

Bu tablo neredeyse her zaman kısmi IP engellemesine işaret eder. Cloudflare isteklerinizi çok sayıda kenar sunucudan geçirir ve her ziyaretçi farklı bir Cloudflare IP'sine düşer; sunucunuzdaki güvenlik duvarı bu IP'lerden yalnızca birkaçını engellemişse, o IP'lere düşen kullanıcılar hata alırken diğerleri siteyi normal görür. Fail2ban ve iptables kayıtlarını inceleyip engellenen Cloudflare adreslerini kaldırmak ve blokları kalıcı olarak izinli listeye almak sorunu bitirir.

Cloudflare proxy'sini kapatınca site açılıyor, bu ne demek#

Bu, sorunun Cloudflare ile sunucunuz arasındaki bacakta olduğunu kesinleştirir. Proxy kapalıyken ziyaretçi doğrudan sunucunuza bağlanır ve o yol çalışıyordur; proxy açıkken bağlantı Cloudflare IP'lerinden geldiği için engellenmekte ya da farklı bir porta gitmektedir. En olası iki neden güvenlik duvarının Cloudflare bloklarını engellemesi ve SSL modunun origin'deki yapılandırmayla uyuşmamasıdır. Proxy'yi kapalı bırakmak bir çözüm değildir, çünkü DDoS koruması ve önbellek avantajlarını da kaybedersiniz.

520 hatası neden bu kadar belirsiz#

Çünkü 520, Cloudflare'in diğer kodlara sığdıramadığı origin yanıtları için ayırdığı genel bir kategoridir. Bağlantı kurulmuş, sunucu bir şeyler göndermiş ama gönderilen veri geçerli bir HTTP yanıtı olarak ayrıştırılamamıştır. Boş yanıt, aşırı büyük başlıklar, işlemin ortasında kapanan bir bağlantı ve çöken bir uygulama işçisi bu kodun tipik nedenleridir. Teşhis için sunucunun kendi üzerinde curl ile ham yanıta bakmak ve web sunucusu ile uygulama hata günlüklerini eş zamanlı izlemek gerekir.

Cloudflare IP listesini güvenlik duvarına elle mi eklemem gerekir#

Elle ekleyebilirsiniz ama listeyi otomatik güncelleyen bir görev kurmak daha sağlıklıdır. Bloklar sık değişmez, ancak değiştiğinde size bildirim gelmez ve bir gün beklenmedik bir 522 dalgası olarak geri döner. Daha iyi bir yaklaşım, güvenlik duvarı izinlerine ek olarak web sunucusunda gerçek ziyaretçi IP'sini geri kazandıran yapılandırmayı kurmaktır; böylece hız sınırlama ve engelleme kararları Cloudflare adresleri yerine gerçek ziyaretçi adreslerine göre verilir.

Bu hataları alırken ziyaretçilerim sitemi hiç göremez mi#

Tamamen göremez demek doğru olmaz, çünkü Cloudflare önbelleğinde duran statik içerikler bir süre daha sunulmaya devam edebilir. Ancak dinamik sayfalar, giriş işlemleri ve form gönderimleri origin'e ulaşmak zorunda olduğu için çalışmaz. Cloudflare'in "Always Online" özelliği etkinse bazı sayfaların arşivlenmiş kopyaları gösterilebilir, ama bu bir çözüm değil geçici bir perdedir; asıl arızayı kapatmadan sitenizin işlevsel olduğunu varsaymayın.

Kapanış#

Cloudflare 520, 521 ve 522 hatalarının hepsi aynı cümleyi farklı biçimlerde söyler: Cloudflare çalışıyor, sizin sunucunuza ulaşılamıyor. Kodu doğru okumak teşhisin yarısıdır — 521 açık bir red, 522 sessiz bir zaman aşımı, 520 ise bozuk bir yanıt demektir. Sunucuda web servisinin durumunu ve dinlenen portları doğrulamak, ardından curl --resolve ile origin'i Cloudflare'i devre dışı bırakmadan test etmek, vakaların büyük kısmını on dakikada ayırır. Türkiye'deki sunucularda 522'nin bir numaralı nedeni güvenlik duvarının veya brute force korumasının Cloudflare IP bloklarını engellemesidir; bu blokları kalıcı olarak izinli listeye almak ve web sunucusunda gerçek ziyaretçi IP'sini geri kazandırmak, sorunu tekrar etmeyecek biçimde kapatır.

Bu tür arızaları kendiniz kovalamak yerine devretmek istiyorsanız, güvenlik duvarı kuralları, servis izleme ve otomatik yeniden başlatma politikalarını üstlenen bir yapı işinizi kolaylaştırır. Kendi kaynaklarınıza sahip bir ortamda çalışmak için VDS sunucu veya esnek ölçeklenen bulut sunucu seçeneklerine, sunucunun güvenlik ve bakım tarafını tamamen bırakmak için sunucu yönetimi hizmetine bakabilirsiniz. Hataların kaynağı yoğun saldırı trafiğiyse DDoS koruma sayfasındaki çözümler origin'inizin nefes almasını sağlar.