Cloudflare 522 Connection Timed Out Hatası Nasıl Çözülür?

Cloudflare 522 Connection timed out hatası, ziyaretçinin tarayıcısı ile Cloudflare arasındaki değil, Cloudflare ile sitenizin origin (kaynak) sunucusu arasındaki TCP bağlantısının zamanında kurulamadığını gösterir. Başka bir ifadeyle Cloudflare isteği sunucunuza iletmeye çalışır; ancak origin IP adresi bağlantıya yanıt vermez veya yanıt, ağ yolunda engellenir. Sorun; hatalı güvenlik duvarı kuralı, durmuş web servisi, yüksek kaynak kullanımı, yanlış origin IP ya da ağ yönlendirmesi kaynaklı olabilir. Bu rehberde Cloudflare 522 Connection timed out hatasını, veri kaybı ve gereksiz yapılandırma değişikliği oluşturmadan hızlıca ayırmayı ve kalıcı olarak çözmeyi ele alıyoruz.

Belirti ve kapsam: 522 hatası neyi ifade eder?

Hata sayfasında genellikle ziyaretçi tarayıcısı ve Cloudflare tarafı çalışır durumda, origin host tarafı ise sorunlu olarak görünür. Bu durum, alan adının Cloudflare proxy üzerinden yayınlandığı senaryolarda görülür. Sorun tek bir alan adını, aynı origin IP üzerindeki tüm siteleri veya yalnızca belirli HTTP/HTTPS portlarını etkileyebilir.

522, uygulamanın mutlaka çöktüğü anlamına gelmez. Web sunucusu yerelde çalışıyor olsa bile dış ağdan gelen Cloudflare bağlantıları firewall tarafından düşürülüyor, sunucu bağlantı kuyruğu doluyor veya yanlış IP’ye yönlendirme yapılıyor olabilir.

Hızlı teşhis özeti

• Cloudflare DNS kaydındaki origin IP’nin güncel ve doğru olduğunu doğrulayın.
• Origin sunucuda HTTP/HTTPS servisinin dinlediğini ve yerel isteklere yanıt verdiğini kontrol edin.
• Sunucuya Cloudflare dışındaki bağımsız bir ağdan, origin IP ve doğru Host başlığıyla test yapın.
• Güvenlik duvarı, fail2ban, WAF veya sağlayıcı ağ güvenliğinin Cloudflare IP bloklarını engellemediğini inceleyin.
• CPU, RAM, disk alanı, bağlantı sayısı ve çekirdek günlüklerinde kaynak/ağ sorunlarını araştırın.

Kontrol	Beklenen durum	Şüpheli sonuç
Origin IP erişimi	80/443 TCP bağlantısı kurulmalı	Timeout veya connection refused
Web servisi	Apache, Nginx veya LiteSpeed dinlemeli	Servis durmuş ya da yanlış portta
Firewall günlükleri	Cloudflare kaynakları kabul edilmeli	DROP, REJECT veya otomatik ban
Sunucu kaynakları	Boş disk ve yeterli RAM/CPU bulunmalı	OOM, disk doluluğu, aşırı yük
DNS origin kaydı	Güncel public origin IP	Eski, özel veya yanlış IP

Cloudflare 522 Connection timed out hatasının yaygın nedenleri

Origin IP adresi değişmiş veya yanlış tanımlanmış olabilir

Sunucu taşıma, IP değişimi, yük dengeleyici güncellemesi veya hatalı DNS düzenlemesi sonrasında Cloudflare eski origin IP’ye bağlanmaya çalışabilir. Cloudflare panelindeki A/AAAA kaydının origin adresini kontrol edin. IPv6 için AAAA kaydı varsa, origin sunucunun IPv6 üzerinden de 80 ve 443 portlarına gerçekten erişilebilir olduğundan emin olun. Çalışmayan bir AAAA kaydı, bazı isteklerde erişim sorununa yol açabilir.

Firewall veya saldırı önleme aracı Cloudflare’i engelliyor olabilir

UFW, firewalld, nftables, iptables, CSF/LFD, fail2ban veya sunucu sağlayıcısının ağ güvenlik duvarı Cloudflare kaynak IP’lerini engelliyorsa Cloudflare origin’e ulaşamaz. Özellikle agresif bağlantı limiti, ülke tabanlı engel, SYN flood koruması ve otomatik ban kuralları bu sonucu doğurabilir.

Yalnızca tek bir Cloudflare IP’sini izinli listeye almak yeterli değildir; Cloudflare değişken IP aralıklarıyla istek iletir. Güncel Cloudflare IP aralıklarını resmi dokümantasyondan alıp hem sunucu hem sağlayıcı firewall’ında 80 ve 443 için izinli listeye ekleyin. Eski veya elle tutulmuş IP listelerine güvenmeyin.

Web sunucusu yanıt veremiyor veya bağlantı kuyruğu doluyor olabilir

Apache, Nginx ya da LiteSpeed durmuş olabilir. Servis ayakta olsa dahi çok düşük worker/connection limitleri, uzun süren PHP işlemleri, veritabanı beklemeleri veya ani trafik nedeniyle yeni TCP bağlantıları işlenemeyebilir. Bu durumda 522 aralıklı biçimde ortaya çıkabilir.

Kaynak tükenmesi ve işletim sistemi sorunları

Diskin dolması, RAM yetersizliği nedeniyle OOM killer’ın süreç sonlandırması, aşırı CPU kullanımı, dosya tanımlayıcı sınırları veya ağ arayüzü hataları origin’in yanıt kabiliyetini etkiler. Sorun yalnızca Cloudflare’e özgü görünse bile kök neden sunucu kapasitesi olabilir.

Ağ rotası veya sağlayıcı katmanında filtreleme

Sunucu çalıştığı hâlde veri merkezi firewall’ı, DDoS azaltma profili, hatalı rota veya upstream ağ olayı Cloudflare ile origin arasındaki trafiği bozabilir. Sunucudan dışarı bağlantı kurulması, Cloudflare’in sunucuya ulaşabildiği anlamına gelmez; gelen 80/443 trafiği ayrıca kontrol edilmelidir.

Loglar ve komutlarla güvenli teşhis

Aşağıdaki örnekler Linux sunucular içindir. Komutları kök kullanıcıyla veya sudo ile çalıştırın. Kontrol amaçlı komutlar yapılandırma değiştirmez. Plesk, cPanel veya farklı dağıtımlarda servis adı ve günlük yolu değişebilir.

Web servisinin dinlediğini kontrol edin

sudo ss -ltnp | grep -E ':(80|443)\s'
sudo systemctl status nginx
sudo systemctl status apache2
sudo systemctl status httpd
sudo systemctl status lsws

Dağıtımınıza ve kullandığınız web sunucusuna karşılık gelen tek servis komutunu değerlendirin: Debian/Ubuntu’da Apache çoğunlukla apache2, RHEL ailesinde httpd adını kullanır. cPanel sistemlerinde Apache hizmeti çoğu kurulumda httpd olarak görünür. ss çıktısında web servisinin en azından 0.0.0.0:80, [::]:80, 0.0.0.0:443 veya uygun sunucu IP’sinde dinlemesi beklenir.

Origin üzerinde yerel HTTP ve HTTPS testi yapın

curl -I --max-time 10 http://127.0.0.1/
curl -k -I --max-time 10 https://127.0.0.1/

Bu test, sunucunun kendi üzerinde yanıt üretip üretmediğini gösterir; dış firewall veya ağ yolunu doğrulamaz. Ad tabanlı sanal host kullanıyorsanız doğru siteyi test etmek için alan adını ekleyin:

curl -I --max-time 10 -H 'Host: www.ornekalanadi.tld' http://127.0.0.1/

Bağımsız bir ağdan origin erişimini test edin

Cloudflare proxy’sini geçici olarak kapatmadan, yönetebildiğiniz farklı bir sunucu veya bağlantıdan aşağıdaki testi yapın. ORIGIN_IP ve alan adını kendi değerlerinizle değiştirin. Bu yöntem TLS SNI bilgisini ve HTTP Host başlığını korur.

curl -I --connect-timeout 10 --max-time 20 \
  --resolve www.ornekalanadi.tld:443:ORIGIN_IP \
  https://www.ornekalanadi.tld/

Burada timeout alınması, sorunun origin erişimi, firewall veya ağ yolunda olma ihtimalini güçlendirir. Başarılı sonuç ise origin’in en azından test yapılan ağdan erişilebilir olduğunu gösterir; Cloudflare IP aralıklarına yönelik blokları ve Cloudflare DNS kaydını kontrol etmeye devam edin.

Kaynaklar ve sistem günlüklerini inceleyin

uptime
free -h
df -h
sudo journalctl -p warning..alert --since '2 hours ago'
sudo dmesg -T | grep -iE 'oom|killed process|error|fail'

df -h çıktısında özellikle kök dosya sistemi, web günlüklerinin bulunduğu bölüm ve geçici alanların dolu olmadığını kontrol edin. OOM mesajı, RAM baskısı nedeniyle web, PHP veya veritabanı süreçlerinin sonlandırıldığını gösterebilir.

Web sunucusu ve güvenlik duvarı kayıtlarını arayın

Nginx günlükleri yaygın olarak /var/log/nginx/ altında bulunur. Apache günlükleri dağıtıma göre /var/log/apache2/ veya /var/log/httpd/ altında olabilir. Önce var olan günlük adlarını listeleyin, sonra ilgili dosyayı inceleyin.

sudo ls -lah /var/log/nginx/ 2>/dev/null
sudo ls -lah /var/log/apache2/ 2>/dev/null
sudo ls -lah /var/log/httpd/ 2>/dev/null
sudo journalctl -u nginx --since '2 hours ago'
sudo journalctl -u apache2 --since '2 hours ago'
sudo journalctl -u httpd --since '2 hours ago'

Firewall altyapısını önce tespit edin. Aynı sunucuda kurulu her aracı rastgele değiştirmeyin.

sudo ufw status verbose
sudo firewall-cmd --state
sudo nft list ruleset
sudo iptables -L -n -v

DROP, REJECT, yüksek paket sayılı kural, Cloudflare aralığına uygulanan hız sınırı veya 80/443 için kapalı kural arayın. CSF/LFD ya da fail2ban kullanılıyorsa, ilgili aracın kendi ban ve olay kayıtlarını da kontrol edin.

Adım adım güvenli çözüm

Uyarı: Firewall kurallarını, DNS kayıtlarını, web sunucusu yapılandırmasını veya kaynak limitlerini değiştirmeden önce mevcut yapılandırmanın yedeğini alın ve mümkünse bakım penceresi planlayın. Uzaktan bağlıysanız firewall düzenlemesi kendi yönetim erişiminizi kesebilir. Önce mevcut SSH yönetim IP’nizin erişimini koruyan kuralın bulunduğunu doğrulayın.

1. DNS’teki origin adresini düzeltin

Cloudflare panelinden A kaydının güncel IPv4 origin IP’sini, varsa AAAA kaydının da çalışır IPv6 origin IP’sini gösterdiğini doğrulayın. Origin bir yük dengeleyici ise backend yerine yük dengeleyicinin doğru public adresi kullanılmalıdır. Yanlış veya kullanılamayan AAAA kaydı varsa, IPv6 erişimini düzeltene kadar kaydı kaldırmak değerlendirilmelidir.

2. Web servisini güvenle geri getirin

systemctl status servisin durmuş olduğunu gösteriyorsa önce hata günlüklerini inceleyin. Yapılandırma değişikliği yapmadıysanız, ilgili servisi yeniden başlatmak düşük riskli bir ilk müdahaledir:

sudo systemctl restart nginx
# veya
sudo systemctl restart apache2
# veya RHEL ailesinde
sudo systemctl restart httpd

Yalnızca kullandığınız web sunucusunun komutunu çalıştırın. Ters proxy mimarisinde Nginx ve Apache birlikte kullanılıyor olabilir; hangi katmanın dinlemediğini ss ve servis günlükleriyle belirleyin. Yeniden başlatma sonrası derhal yerel ve harici curl testini tekrarlayın.

3. Cloudflare kaynaklarına yönelik engeli kaldırın

Firewall, WAF, fail2ban veya sağlayıcı güvenlik duvarında Cloudflare’in güncel IP aralıklarının HTTP/HTTPS erişimine izin verildiğini sağlayın. En güvenli yaklaşım, yalnızca 80 ve 443 portlarında gerekli Cloudflare ağlarını izinli listeye almaktır. Tüm portları internete açmayın ve tüm firewall’ı devre dışı bırakmayın.

Kuralları uyguladıktan sonra kural sırasını kontrol edin: izin kuralından önce eşleşen bir genel DROP kuralı varsa izin etkisiz kalır. Ayrıca bağlantı/istek limiti koyan kuralları normal trafik düzeyinize göre gözden geçirin. Sağlayıcı panelindeki ayrı bir firewall varsa sunucu üzerindeki düzeltme tek başına yeterli olmayabilir.

4. Kaynak dar boğazını giderin

Disk doluysa önce güvenle silinebileceği doğrulanmış eski geçici dosyaları veya yönetilen log rotasyonunu ele alın; uygulama verisi, veritabanı dosyası ve bilinmeyen sistem dosyalarını silmeyin. RAM baskısında uzun süren istekleri, PHP-FPM/uygulama hata günlüklerini ve veritabanı beklemelerini araştırın. Sürekli CPU veya bağlantı doygunluğu varsa kapasite, worker limitleri ve uygulama sorgularını ölçerek düzenleyin. Rastgele yüksek limit tanımlamak, sorunu daha büyük bir kaynak tüketimine dönüştürebilir.

5. Ağ veya sağlayıcı katmanını kanıtlarla inceletin

Origin doğrudan testte zaman aşımına uğruyor, servis dinliyor ve yerel firewall kuralları doğru görünüyorsa sağlayıcı desteğine zaman aralığını, origin IP’yi, etkilenen portları ve test çıktısını iletin. Özellikle Cloudflare kaynaklarından gelen TCP 80/443 trafiğinde upstream filtreleme veya rota sorunu olup olmadığının kontrol edilmesini isteyin. Bu kayıtlar, sorunun uygulama yerine ağ katmanında ayrıştırılmasını kolaylaştırır.

Çözümün doğrulanması

Değişikliklerden sonra aşağıdaki kontrollerin tamamını yapın:

1. Origin sunucuda ss ile 80/443 dinleme durumunu doğrulayın.
2. Yerel curl isteğinin 200, 301, 302 veya uygulamanızın beklediği başka geçerli HTTP durum kodunu döndürdüğünü kontrol edin.
3. Harici ağdan --resolve testiyle origin’e erişildiğini doğrulayın.
4. Alan adını normal şekilde açın ve Cloudflare üzerinden 522 sayfasının kalktığını gözlemleyin.
5. Web sunucusu, sistem ve firewall günlüklerinde yeni ret, OOM veya servis çökmesi kaydı olmadığını inceleyin.

Yalnızca tarayıcı önbelleğine güvenmeyin; terminalden HTTP başlık testi yapmak ve farklı bir ağdan erişimi doğrulamak daha sağlıklı sonuç verir.

522 hatasını önleme

• Origin IP değişikliklerini planlı yapın; DNS A ve AAAA kayıtlarını değişiklik sonrası test edin.
• Cloudflare IP aralıkları için izinli listeyi resmi güncel liste üzerinden düzenli gözden geçirin.
• 80/443 erişimi, web servisi durumu, disk doluluğu, RAM baskısı ve yanıt süresi için izleme/alarm kurun.
• Firewall kural değişikliklerini sürüm kontrollü veya belgelenmiş biçimde uygulayın; geri dönüş planı tutun.
• Yoğun istek dönemlerinde uygulama, veritabanı ve web sunucusu kapasitesini ölçerek bağlantı limitlerini kontrollü biçimde ayarlayın.

Sonuç

Cloudflare 522 Connection timed out hatası çoğunlukla Cloudflare ile origin arasındaki erişim zincirinin kırıldığını gösterir. En hızlı ve güvenli yaklaşım; önce doğru origin IP’yi, web servisinin dinleme durumunu ve dış erişimi doğrulamak, ardından firewall engelleri, kaynak tükenmesi ve ağ katmanını kanıtlarla incelemektir. Firewall’ı tamamen kapatmak veya rastgele servis ayarı değiştirmek yerine, her değişiklikten sonra curl ve günlük kontrolleriyle sonucu doğrulamak kalıcı çözüm sağlar.

Sık sorulan sorular

Cloudflare 522 ile 524 arasındaki fark nedir?

522, Cloudflare’in origin ile TCP bağlantısını zamanında kuramadığını belirtir. 524 ise bağlantı kurulduktan sonra origin uygulamasının Cloudflare’in bekleme süresi içinde HTTP yanıtını tamamlayamadığını ifade eder. 524’te uzun süren uygulama veya veritabanı işlemleri daha sık araştırılır.

Cloudflare proxy’sini kapatmak 522 sorununu çözer mi?

Proxy’yi kapatmak yalnızca teşhis amacıyla erişim yolunu değiştirebilir; origin, firewall veya kaynak sorununu çözmez. Ayrıca origin IP’nizi doğrudan görünür hâle getirebilir. Önce curl --resolve ile kontrollü test yapmak genellikle daha uygundur.

Sunucuda site açılıyor ama Cloudflare neden 522 veriyor?

Yerel test, yalnızca uygulama katmanının çalıştığını gösterebilir. Cloudflare IP aralıklarının firewall tarafından engellenmesi, dış ağ erişimi, sağlayıcı firewall’ı veya rota sorunu devam edebilir.

Cloudflare IP’lerini izinli listeye almak tüm sunucuyu açık hâle getirir mi?

Hayır. Doğru tasarımda yalnızca Cloudflare’in güncel IP aralıklarına, yalnızca gerekli web portlarında izin verilir. SSH, panel, veritabanı ve diğer yönetim portları için ayrı ve dar kurallar korunmalıdır.

522 hatası yalnızca DDoS saldırısında mı görülür?

Hayır. Saldırı veya ani trafik kaynak tüketimini artırabilir; ancak yanlış DNS, durmuş servis, güvenlik duvarı kuralı ve ağ yönlendirmesi de tek başına 522 üretebilir.