Cloudflare 522 Hatası Nedir, Nasıl Çözülür?

Cloudflare 522 Connection timed out, Cloudflare'in sitenizin asıl barındığı kaynak sunucuya (origin) zamanında bağlanamadığını söyler. Ziyaretçiyle Cloudflare arasında sorun yoktur, kopukluk Cloudflare ile sunucunuz arasındadır. En sık üç neden görülür: sunucudaki güvenlik duvarının Cloudflare IP aralıklarını engellemesi ya da hız sınırına takması, Cloudflare DNS'inde eski veya yanlış kaynak IP'si kalması ve sunucunun yeni bağlantı kabul edemeyecek kadar yüklü olması. Kaynağı Cloudflare'i atlayarak curl --resolve ile test etmek, sorunun hangisi olduğunu birkaç dakikada gösterir.

522 tam olarak ne zaman çıkar?

Cloudflare'in 522 sayfası (Temmuz 2026 güncellemesi) iki ayrı zaman aşımını tarif ediyor. Birincisi bağlantı kurulmadan önce yaşanır: Cloudflare kaynağa SYN paketini gönderir ve 19 saniye içinde SYN+ACK yanıtı alamazsa vazgeçer. İkincisi bağlantı kurulduktan sonradır: Cloudflare isteğini iletir ve 90 saniye içinde bu isteğin alındığına dair onay (ACK) gelmezse yine 522 döner. İki durumda da sunucunuz HTTP düzeyinde hiçbir şey söylememiştir. Hata sayfasındaki üç kutulu şemada tarayıcı ve Cloudflare "Working", sunucunuz (Host) "Error" görünür.

Bu ayrım işinize yarar. 522 bir uygulama hatası sayılmaz. WordPress, PHP ya da veritabanı hata verse sunucu yine de bir HTTP yanıtı (500, 503 gibi) üretir ve Cloudflare onu olduğu gibi iletir. 522'de yanıt hiç gelmemiştir. Bu yüzden ilk bakılacak yer ağ yolu ve güvenlik duvarıdır, uygulama günlükleri sonra gelir.

520, 521, 523 ve 524'ten nasıl ayrılır?

Beşi de Cloudflare'in kaynak sunucuyla yaşadığı sorunu anlatır ama her biri başka bir aşamayı işaret eder. Tanımlar Cloudflare'in güncel sorun giderme sayfalarından:

521 ile 522 arasındaki fark çoğu zaman güvenlik duvarının nasıl davrandığına bağlıdır. Kapalı bir port ya da bağlantıyı reddeden (RST gönderen) bir kural 521 üretir. Paketi hiçbir yanıt vermeden düşüren (DROP) bir kural ise Cloudflare'i bekletir ve 522 olarak döner. Aynı engelleme kuralı, yapılandırmasına göre iki farklı kod gösterebilir. 525 ve 526 ise bağlantı kurulduktan sonraki SSL el sıkışmasıyla ilgilidir, Cloudflare SSL/TLS modu ile kaynak sertifikası arasındaki uyumsuzluklar ayrı bir teşhis sırası ister.

Önce sorunun biçimine bakın

Cloudflare'in olmadığı durumlar için genel site açılmıyorsa izlenecek katman katman teşhis sırası işe yarar. 522'de ise alan çok daha dar. Teşhise başlamadan iki soruyu yanıtlayın: hata bütün sayfalarda ve her istekte mi görülüyor, yoksa aralıklı mı? Sorun başlamadan önce ne değişti? Hosting taşıması, sunucu IP değişikliği, yeni bir güvenlik duvarı kuralı ya da Cloudflare ayarındaki bir oynama çoğu zaman cevabı kendisi verir.

Cloudflare DNS'indeki kaynak IP doğru mu?

Burada çok kişinin takıldığı bir nokta var. Kayıt Cloudflare üzerinden vekil (proxied, turuncu bulut) çalışıyorsa dig ornek.com.tr A +short size Cloudflare'in adreslerini döndürür, kaynak sunucunuzunkini değil. Doğru IP'yi görmek için Cloudflare panelinde alan adının DNS kayıtları ekranını açmanız gerekir. Oradaki değeri hosting panelinizde ya da sunucu teslim bilgilerinde yazan IP ile karşılaştırın. Kayıt türlerinin ve TTL mantığının genel anlatımı DNS kayıt türleri ve yayılma süresi rehberinde var.

Taşımalardan sonra en sık rastlanan tablo, aynı ad için iki A kaydının birlikte kalmasıdır: biri yeni sunucuyu, biri eskisini gösterir. Cloudflare belgesine göre aynı adda birden çok A veya AAAA kaydı varsa ve biri vekilliyse hepsi vekil kabul edilir. Sonuç, isteklerin bir kısmının artık yanıt vermeyen eski sunucuya gitmesi ve hatanın "bazen" görünmesidir. Eski kaydı silin.

AAAA kaydına da bakın. Sunucunuz IPv6 üzerinden hizmet vermiyorsa ya da kayıttaki IPv6 adresi eski bir sunucuya aitse, Cloudflare kaynağa bu adres üzerinden bağlanmayı denediğinde zaman aşımı yaşanabilir. IPv6'yı gerçekten sunmuyorsanız AAAA kaydını tutmanın bir faydası yok. Alan adının hangi yöntemle hostinge bağlandığından emin değilseniz isim sunucusu ve A kaydı yöntemlerinin farkına göz atın.

Kaynağı Cloudflare'i atlayarak test edin

Bu adım teşhisin belkemiği. curl komutunun --resolve seçeneği, alan adını DNS'e sormadan doğrudan verdiğiniz IP'ye bağlanmanızı sağlar. Böylece istek Cloudflare'e uğramaz ama sunucu, doğru alan adının sitesini döndürür. Örnekte kaynak IP 203.0.113.10:

curl -sv -o /dev/null --connect-timeout 10 \
  --resolve ornek.com.tr:443:203.0.113.10 \
  https://ornek.com.tr/

Çıktıda üç sonuçtan birini görürsünüz. "Connected to ornek.com.tr (203.0.113.10) port 443" satırının ardından bir HTTP durum kodu geliyorsa sunucu sizden bağlantı kabul ediyordur. On saniye sonra "Connection timed out" görüyorsanız paketler bir yerde düşürülüyordur. "Connection refused" ise portun kapalı olduğunu ya da bir kuralın bağlantıyı reddettiğini gösterir, bu da 521 tarafına daha yakındır.

Sitede kendinden imzalı ya da Cloudflare Origin CA sertifikası varsa curl sertifikayı doğrulayamayıp duracaktır. Yalnız bağlantıyı test ettiğiniz için o durumda komuta -k ekleyebilirsiniz. Sertifikanın kendisini incelemek ayrı bir iştir.

Sonucu doğru yorumlamak için şunu bilin: kendi bilgisayarınızdan bağlanabiliyor olmanız Cloudflare'in de bağlanabildiği anlamına gelmez. Güvenlik duvarı sizin IP'nize izin verip Cloudflare'in adreslerini engelliyor olabilir. Doğrudan bağlantı başarılı ama Cloudflare üzerinden 522 alıyorsanız şüphe neredeyse kesin olarak güvenlik duvarına yönelir. Bağlantı sizden de zaman aşımına düşüyorsa sunucu ya kapalıdır, ya aşırı yüklüdür ya da IP yanlıştır.

Bağlantının hangi aşamada ne kadar sürdüğünü görmek isterseniz zaman değişkenlerini yazdırın:

curl -s -o /dev/null --resolve ornek.com.tr:443:203.0.113.10 \
  -w "%{time_connect} %{time_appconnect} %{time_starttransfer} %{http_code}\n" \
  https://ornek.com.tr/

Çıktıdaki ilk üç değer TCP bağlantısının, TLS el sıkışmasının ve ilk baytın kaçıncı saniyede tamamlandığını, dördüncüsü durum kodunu verir. İlk değer birkaç saniyeyi buluyorsa SYN paketleri kayboluyor ya da sunucunun kuyruğunda bekliyordur. Bağlantı hızlı ama ilk bayt uzunsa sorun uygulamadadır ve Cloudflare tarafında 522'den çok 524 görmeniz beklenir.

Güvenlik duvarı Cloudflare'i engelliyor mu?

Cloudflare'in kendi belgesi bunu 522'nin en yaygın nedeni olarak sayıyor ve çözümü tek cümleyle veriyor: Cloudflare'in bütün IP aralıklarına izin verin. Neden bu kadar sık olduğunu anlamak kolay. Site Cloudflare arkasına alındığında binlerce ziyaretçinin isteği sunucuya görece az sayıda Cloudflare adresinden gelir. IP başına bağlantı sayısını sınırlayan bir kural, kısa sürede çok istek gören bir saldırı tespit mekanizması ya da giriş denemelerini sayan bir yasaklama sistemi bu adresleri saldırgan sanıp engeller. O andan sonra sunucu Cloudflare'in paketlerini düşürür ve bütün ziyaretçiler 522 görür.

Örnek araçlar sunucudan sunucuya değişir: CSF gibi iptables tabanlı güvenlik duvarları ve bağlantı sınırları, fail2ban, Imunify360, Plesk'in güvenlik duvarı ve IP Address Banning (Fail2Ban) ekranı. Hangisi kullanılıyorsa yapılacak iş aynıdır:

1. Engellenen IP listesinde Cloudflare aralıklarından adres olup olmadığına bakın ve varsa engeli kaldırın.
2. Cloudflare'in yayımladığı güncel IPv4 ve IPv6 aralıklarını aracın izin ya da güvenilir IP listesine ekleyin. Plesk'te bu, Tools & Settings altındaki IP Address Banning (Fail2Ban) ekranının Trusted IP Addresses sekmesidir ve CIDR biçiminde aralık kabul eder. fail2ban'i doğrudan kullanıyorsanız karşılığı ignoreip ayarıdır.
3. Listeyi elle bir kez girip unutmayın. Cloudflare aralıkları zamanla değişebilir, listeyi belli aralıklarla yayımlanan sayfayla karşılaştırın.

Paylaşımlı hostingdeyseniz sunucu güvenlik duvarına erişiminiz olmaz. Bu durumda hatanın saatini ve Ray ID'sini destek talebine yazıp Cloudflare aralıklarının engellenip engellenmediğini sorun. Netx müşterisiyseniz talebi müşteri panelinden açabilirsiniz.

VPS ya da VDS'te paketleri izlemek

Root erişiminiz varsa tahmin yürütmek yerine paketlerin gelip gelmediğine bakın. Aşağıdaki komut 443 portuna gelen SYN paketlerini ve sunucunun verdiği yanıtları gösterir:

tcpdump -ni any -c 40 \
  'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Gelen satırlarda Flags [S], sunucunun yanıtında Flags [S.] (SYN+ACK) görmeniz gerekir. Cloudflare adreslerinden [S] geliyor ama karşılığında [S.] çıkmıyorsa paket sunucunun kendi güvenlik duvarında düşüyordur. Hiç SYN gelmiyorsa sorun sunucuya ulaşmadan, ağda ya da DNS'teki IP'dedir. Web sunucusunun ilgili portu gerçekten dinlediğini de doğrulayın:

ss -ltn '( sport = :443 or sport = :80 )'

Sunucu yükü ve kapanan bağlantı kuyruğu

Hata yalnız yoğun saatlerde ve aralıklı görülüyorsa sunucunun kendisi yeni bağlantıları zamanında kabul edemiyor olabilir. Apache'de işçi sayısı tükendiğinde hata günlüğüne "server reached MaxRequestWorkers setting" satırı düşer. PHP-FPM havuzunun dolması, belleğin bitip takasa düşülmesi ya da diskin yanıt veremez hâle gelmesi de aynı sonucu doğurur. Bu belirtilerin sunucu tarafında nasıl okunacağını steal, I/O wait ve load average değerlerini yorumlayarak adım adım çıkarabilirsiniz.

Cloudflare'in listesinde iki madde daha var: kaynakta keepalive'ın kapalı olması ve paketlerin kaynakta düşmesi. Keepalive kapalıyken Cloudflare her istek için yeni TCP bağlantısı açmak zorunda kalır, bu da yoğun anlarda kuyruğu hızla doldurur. Web sunucunuzda keepalive açık mı, bir bakın. Saldırı kaynaklı bir yük artışından şüpheleniyorsanız katmanları ayırmak için katman 3/4 ve katman 7 saldırılarının farkını bilmek işinizi kolaylaştırır.

Port ve SSL modu uyumu

Cloudflare'in 521 sayfası kaynağın doğru portu dinlemesi gerektiğini açıkça yazıyor: Flexible modda 80, Full ve Full (strict) modlarda 443. Diyelim ki sunucunuzda yalnız 80 açık ve birisi Cloudflare'de modu Full'e çevirdi. Güvenlik duvarı 443'ü reddediyorsa 521, sessizce düşürüyorsa 522 görürsünüz. Çözüm Flexible'a geri dönmek olmamalı, çünkü o modda Cloudflare ile sunucunuz arasındaki trafik şifresizdir. Doğrusu kaynakta geçerli bir sertifikayla 443'ü açmak ve Full (strict) kullanmaktır. Cloudflare belgesinde varsayılan olarak geçen Automatic SSL/TLS ayarı, kaynağın desteklediği en güvenli modu kendisi seçer. Origin Rules ile hedef portu değiştirdiyseniz kaynakta o portun da açık olduğunu kontrol edin.

Düzeldiğini doğrulamak

Tek bir başarılı sayfa açılışıyla yetinmeyin, çünkü aralıklı 522 tam da böyle yanıltır. Cloudflare üzerinden birkaç dakika boyunca düzenli istek gönderip durum kodlarını sayın:

for i in $(seq 1 30); do
  curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://ornek.com.tr/
  sleep 5
done | sort | uniq -c | sort -rn | head

Otuz satırın hepsi 200 (ya da sitenizin beklenen kodu) olmalı. Aralarında tek bir 522 bile varsa sorun sürüyordur, büyük olasılıkla bayat bir DNS kaydı ya da yalnız bazı Cloudflare adreslerini etkileyen bir kural vardır. Kalıcı çözümden sonra sunucunun erişim günlüğünde Cloudflare adreslerinden gelen isteklerin yeniden göründüğünü de kontrol edin. Hata yoğun saatlere bağlıysa doğrulamayı bir sonraki yoğun dönemde tekrarlayın.

Geri alma gerektiğinde değiştirdiğiniz tek şeyi geri çevirin. DNS kaydını düzelttiyseniz eski değeri not etmiş olun. Güvenlik duvarına eklediğiniz izin satırlarını toplu silmek yerine yalnız sorunlu satırı kaldırın.

Destek talebinde hangi bilgiler olmalı?

Cloudflare, hosting sağlayıcısına iletilmesi gereken asgari bilgileri hata kodu ve mesajı, hatanın saati ve saat dilimi ve hatayı veren tam adres olarak sayıyor. Biz bunlara birkaç kalem eklemenizi öneririz:

• Hata sayfasının altında ya da yanıtın cf-ray başlığında yazan Ray ID
• Cloudflare DNS'inde tanımlı kaynak IP'si ve SSL/TLS şifreleme modu
• Yukarıdaki curl --resolve komutunun çıktısı ve hangi ağdan çalıştırdığınız
• Hatanın sürekli mi aralıklı mı olduğu, başlamadan önce yapılan değişiklikler
• Güvenlik duvarı izin listesine Cloudflare aralıklarını ekleyip eklemediğiniz

Cloudflare ayrıca kaynaktan, günlükte bağlantı kuran bir Cloudflare IP'sine doğru MTR ya da traceroute çıktısı istiyor. Kendi sunucunuzdaysanız bunu siz alabilirsiniz, örnekteki adresin yerine günlüğünüzde görülen bir Cloudflare adresini yazın:

mtr -rwc 50 198.51.100.25

Paylaşımlı hostingde bu çıktıyı destek ekibinden istemeniz gerekir. Kendi VPS ya da VDS'inizde güvenlik duvarı, web sunucusu ve izleme ayarlarıyla uğraşmak istemiyorsanız sunucu yönetimi hizmetinin kapsamını teklif aşamasında yazılı olarak belirleyebilirsiniz.

Sık sorulan sorular

Cloudflare'i duraklatınca site açılıyor, sorun Cloudflare'de mi?

Genellikle hayır. Duraklattığınızda ziyaretçiler sunucuya kendi IP'lerinden bağlanır, Cloudflare adreslerinin engellenmesi bu yolu etkilemez. Site bu şekilde açılıyorsa en güçlü şüpheli, Cloudflare aralıklarını engelleyen ya da sınırlayan bir sunucu kuralıdır. Duraklatma kaynak IP'nizi herkese açık hâle getirdiği için onu kalıcı çözüm gibi kullanmayın.

Kaynağı yalnız Cloudflare'e açmak mantıklı mı?

Kaynak IP'niz sızmışsa saldırganın Cloudflare'i atlamasını zorlaştırdığı için mantıklıdır. Ama sırası önemli. Önce Cloudflare'in bütün IPv4 ve IPv6 aralıklarına izin verin, sonra 80 ve 443'ü diğer herkese kapatın. Bu kısıtlamadan sonra yukarıdaki curl --resolve testi sizin bilgisayarınızdan zaman aşımına düşecektir, kendi yönetim IP'nizi de listeye eklemeyi planlayın.