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

Sunucuya SSH ile bağlanabiliyor olmanız, sitenizin Cloudflare üzerinden erişilebilir olduğunu göstermez. Cloudflare 521 hatası, genellikle kaynak web sunucusunun Cloudflare bağlantısını reddettiğini belirtir. Çözüm için doğru kaynak IP'yi, Nginx'in HTTPS dinleyicisini ve güvenlik duvarı izinlerini doğrulayın; ardından Full (strict) bağlantısını alan adını koruyan doğrudan kaynak testiyle ve Cloudflare üzerinden ayrı ayrı sınayın.

Site açık görünüyor, Cloudflare neden 521 döndürüyor?

SSH oturumunuz açık, sunucudan yaptığınız yerel HTTP isteği yanıt alıyor; tarayıcıda ise Cloudflare 521 hatası var. Çelişki yok. Bu kontroller farklı bağlantıları sınar: SSH erişiminin sürmesi, Nginx’in dışarıdan HTTPS bağlantısı kabul ettiğini göstermez. Yerel HTTP yanıtı da yalnızca denediğiniz adres ve port hakkında bilgi verir. Makinenin ayakta olması, web hizmetinin Cloudflare tarafından erişilebilir olduğu anlamına gelmez.

İstek yolunu tarayıcı-Cloudflare-kaynak sunucu olarak ayırın. Turuncu bulutla proxy edilen www.example.com için tarayıcınız Cloudflare’a bağlanır; Cloudflare, kaynaktan yanıt alması gerektiğinde ayrı bir bağlantı kurar. Tarayıcıda hata sayfasının görünmesi, kaynak Nginx’in isteği aldığını kanıtlamaz. Burada gördüğünüz, Cloudflare’ın tarayıcıya ilettiği hata yanıtıdır; uygulamanızın ürettiği bir sayfa değildir.

Cloudflare’ın 521 belgesi, bu kodu kaynak web sunucusunun Cloudflare bağlantısını reddetmesiyle açıklar. Başlıca olasılıklar, kaynak web hizmetinin kapalı olması ve Cloudflare isteklerinin engellenmesidir. Nginx çalışsa bile güvenlik duvarı bağlantıyı reddedebilir. Hata kodu, tek başına kesin kök neden değildir. Kendi bilgisayarınızdan kaynağa ulaşmanız da Cloudflare adreslerinden gelen bağlantıların kabul edildiğini göstermez; erişim kuralları bağlantının geldiği IP adresine göre değişebilir.

Varsayımsal laboratuvarda tek kaynak sunucu, Ubuntu Server 24.04 LTS üzerinde dağıtım paketlerinden Nginx 1.24.0 çalıştırır; arada yük dengeleyici, Cloudflare Tunnel, Docker veya ikinci ters proxy yoktur. Cloudflare, sürümü sabitlenen bir paket değil, yönetilen hizmettir. SSL/TLS modu Full (strict), beklenen kaynak HTTPS portu TCP 443’tür; Origin Rules ile port değiştirilmemiştir. TCP 80 yalnızca HTTP kontrolü ve HTTPS yönlendirmesi içindir.

Kaynak IPv4 adresi 192.0.2.10, isteğe bağlı IPv6 adresi 2001:db8::10 olarak gösterilir. Bu adresler dokümantasyona ayrılmıştır, çalışır internet hedefleri değildir; example.com da örnek alan adıdır. Kontrollerden önce bunları yönettiğiniz gerçek değerlerle değiştirin.

522 bağlantı zaman aşımını, 523 kaynağa ulaşılamamasını, 525 TLS el sıkışmasının başarısızlığını, 526 kaynak sertifikasının doğrulanamamasını belirtir. Bunlar aynı arıza değildir. Cloudflare’ın Full (strict) belgesi, kaynakta HTTPS ve istenen ana makine adıyla eşleşen, güvenilen, süresi geçmemiş bir sertifika gerektirir; fakat 521 kodu doğrudan sertifika değiştirmeniz gerektiğini söylemez. İnceleme notunuza yalnızca “site açık” yazmak yerine, çalışan yolun SSH, yerel HTTP veya dışarıdan HTTPS olduğunu kaydedin. Özellikle yerel TCP 80 yanıtını, Cloudflare’dan kaynak TCP 443 erişiminin kanıtı saymayın.

Önce Cloudflare’ın hangi kaynağa gittiğini doğrulayın

Yanlış kaynak adresine yönelen bir kayıt için Nginx’i yeniden başlatmak hiçbir şeyi düzeltmez. Önce hedefi doğrulayın. Cloudflare’ın 521 hata belgesi, kaynak sunucunun Cloudflare bağlantısını reddetmesini temel sorun olarak tanımlar. Cloudflare 521 hatası incelemesinde DNS panelindeki adresi sunucunuzun adresiyle karşılaştırmadan servis veya güvenlik duvarı ayarlarını değiştirmeyin; yanlış makinedeki doğru ayar sorunu çözmez.

Bu varsayımsal laboratuvarda tek kaynak, Ubuntu Server 24.04 LTS üzerinde dağıtım paketlerinden Nginx 1.24.0 çalıştırır. Cloudflare panelinde example.com alanının DNS kayıtlarını açın. www.example.com için A kaydının 192.0.2.10 adresini gösterdiğini ve turuncu bulutla proxy edildiğini doğrulayın. Aynı ad altında eski adreslere yönelen başka A kayıtları bulunmadığını da kontrol edin. Burada yük dengeleyici, Cloudflare Tunnel, Docker veya ikinci ters proxy yoktur; hedef doğrudan kaynak sunucudur.

Genel DNS sorgusu ise paneldeki kaynak adresini göstermez. Ubuntu’da dig komutunu dnsutils paketiyle edinebilirsiniz. Aşağıdaki örnek, IPv4 ve IPv6 yanıtlarını ayrı sorgular. example.com, 192.0.2.10 ve 2001:db8::10 dokümantasyon değerleridir; çalışır internet hedefleri değildir. Komutları uygulamadan önce alan adını, panel karşılaştırmalarında da adresleri yönettiğiniz gerçek değerlerle değiştirin.

dig +short www.example.com A
dig +short www.example.com AAAA

Proxy etkin gerçek bir alan adında ilk komutun Cloudflare uç IPv4 adreslerini döndürmesi beklenir. İkinci komutta AAAA yanıtı varsa bunlar uç IPv6 adresleridir. Adresleri Cloudflare’ın yayımladığı resmî IPv4 ve IPv6 aralıklarıyla karşılaştırabilirsiniz. Çıktıda 192.0.2.10 bulunmaması hata değildir – kaynak IP’yi buradan doğrulayamazsınız. Genel sorgudaki AAAA yanıtı da kaynak sunucunun IPv6 kullandığını kanıtlamaz; ziyaretçi bağlantısıyla kaynak bağlantısını birbirinden ayırın.

Kaynak IPv6 kontrolünü yalnızca gerçekten yapılandırılmışsa yapın. Panelde www.example.com için AAAA kaydı varsa bu laboratuvardaki karşılığı 2001:db8::10 olmalıdır; adresin sunucuya atanmış ve erişilebilir olması gerekir. Kaynakta IPv6 kullanmıyorsanız sırf genel sorgu IPv6 döndürüyor diye AAAA kaydı eklemeyin. Mevcut bir kaynak AAAA kaydını ise IPv6 kullanmadığınızı düşünerek görmezden gelmeyin.

SSL/TLS modunun Full (strict) olduğunu doğrulayın. Cloudflare’ın Full (strict) belgesi, kaynakta HTTPS ve doğrulanabilir bir sertifika gerektirir. Origin Rules içinde hedef portunu değiştiren bir kural bulunmadığını da kontrol edin. Bu ortamda kaynak HTTPS portu TCP 443’tür; TCP 80 yalnızca HTTP kontrolü ve HTTPS yönlendirmesi içindir. Bağlantı kontrolüne geçerken panelde doğruladığınız kaynak adresini ve TCP 443 portunu esas alın.

Kaynak IP’ye alan adını koruyarak bağlanın

Tarayıcıya kaynak IP’yi yazmak, doğru siteyi sınadığınız anlamına gelmez. Nginx’in HTTPS belgeleri, sertifika seçiminin HTTP isteğinden önce gerçekleştiğini ve SNI bilgisinin bu seçimde kullanıldığını açıklar. https://192.0.2.10/ isteği, sertifikadaki alan adıyla eşleşmeyebilir veya varsayılan sanal sunucuya düşebilir. Yalnızca Host başlığını değiştirmek TLS aşamasını düzeltmez. Adı koruyun.

Bu varsayımsal laboratuvarda kaynak, Ubuntu Server 24.04 LTS üzerinde Nginx 1.24.0 çalıştırır; komut curl 8.5.0 içindir. Kaynak sunucunun dışındaki yetkili bir test noktasını kullanın. www.example.com ve 192.0.2.10 dokümantasyon değerleridir, çalışır internet hedefleri değildir; uygulamadan önce yönettiğiniz gerçek alan adı ve kaynak IPv4 adresiyle değiştirin. Örnek, turuncu bulutla proxy edilen kaydın Cloudflare adreslerine değil, doğrudan kaynak sunucunun TCP 443 portuna bağlanır.

curl --noproxy '*' \
  --resolve www.example.com:443:192.0.2.10 \
  --connect-timeout 5 \
  --max-time 15 \
  --verbose \
  --dump-header - \
  --output /dev/null \
  https://www.example.com/

--resolve, belirtilen ad ve port için bağlantı adresini değiştirir; SNI, sertifika adı doğrulaması ve HTTP Host bilgisi URL’deki alan adını kullanmayı sürdürür. --noproxy '*', ortamda tanımlı ileri proxy’leri devreden çıkarır. Bağlantı aşaması 5, işlemin tamamı 15 saniyeyle sınırlıdır. Ayrıntılı bağlantı bilgileri ve yanıt başlıkları gösterilir, gövde atılır. Yönlendirmeler takip edilmez; ilk yanıt incelenir. Aşağıdakiler gözlemlenmiş ölçümler değil, olası çıktıların yorumlarıdır:

• curl: (7) ile Connection refused: TCP bağlantısı reddedilmiştir. Dinleyici yokluğu veya güvenlik duvarının etkin reddi araştırılır; tek başına hata numarası nedeni belirlemez.
• curl: (28): Süre sınırı aşılmıştır. Ayrıntılı çıktıda bağlantının kurulup kurulmadığına bakın; paket düşürülmesi ile bağlantı sonrasında geciken yanıtı ayırın.
• curl: (60): Sertifika doğrulaması başarısızdır. Ad uyuşmazlığı, geçerlilik süresi ve güven zinciri incelenir. Bu, TCP bağlantı reddi değildir.
• HTTP/1.1 200 OK veya 301: TLS tamamlanmış, HTTP yanıtı alınmıştır. Yönlendirme yanıtı, hedef sayfanın veya uygulamanın tamamının sağlıklı olduğunu kanıtlamaz.

Cloudflare’ın Full (strict) belgesi, geçerli, güvenilen ve istenen adla eşleşen kaynak sertifikası gerektirir; -k ekleyerek doğrulama hatasını gizlemeyin. Cloudflare 521 hatası belgesi bağlantı reddini vurgular. Güvenlik duvarınız yalnızca Cloudflare’ın resmî IP aralıklarına izin veriyorsa test noktasının çıkış IP’sine TCP 443 için dar kapsamlı, geçici izin gerekir. Başarılı yanıt yalnızca bu noktanın erişimini gösterir; Cloudflare erişimini kanıtlamaz. Kontrol bitince geçici izni kaldırın.

Nginx gerçekten 443 portunu dinliyor mu?

Servisin yeşil görünmesi, HTTPS bağlantısı kabul ettiğini kanıtlamaz. Nginx yalnızca TCP 80 dinliyorsa HTTP kontrolü geçebilir; Full (strict) kullanılan bu ortamda beklenen TCP 443 ise kapalı kalır. Cloudflare’ın 521 belgesi, kaynak sunucunun çalışmamasını veya bağlantıları reddetmesini nedenler arasında sayar; Full (strict) belgesi kaynakta HTTPS erişimi gerektirir.

Varsayımsal Ubuntu Server 24.04 LTS ve dağıtım paketlerinden Nginx 1.24.0 ortamında şu komutları kaynak sunucuda çalıştırabilirsiniz. Durumu değiştirmezler; servis, soket, yapılandırma ve günlük bilgilerini gösterirler:

sudo systemctl status nginx --no-pager -l
sudo ss -ltnp '( sport = :80 or sport = :443 )'
sudo nginx -t
ls -l /etc/nginx/sites-enabled/example.com
readlink -e /etc/nginx/sites-enabled/example.com
sudo nginx -T
sudo journalctl -u nginx -n 50 --no-pager
sudo tail -n 50 /var/log/nginx/error.log

active (running), sürecin çalıştığını gösterir. Tek başına yetmez. ss çıktısında 443 için LISTEN ve süreç alanında nginx beklenir. 0.0.0.0:443 bütün yerel IPv4 adreslerini, [::]:443 IPv6 adreslerini kapsar; IPv6 soketinin IPv4 bağlantılarını da karşılayacağını varsaymayın. Yalnızca 127.0.0.1:443 dinleniyorsa dışarıdan erişilemez. Başka bir süreç portu tutuyorsa günlükte Address already in use görülebilir.

Etkinleştirme bağlantısı /etc/nginx/sites-available/example.com dosyasına çözülmelidir. readlink -e çıktı vermiyorsa bağlantıyı ve hedefi inceleyin. nginx -T, diskteki yapılandırmayı sınayıp dahil edilen dosyaları döker; çalışan sürecin aynı içeriği yüklediğini kanıtlamaz. Site dosyasının bu çıktıda bulunduğunu kontrol edin. Bağlantı düzeni için Ubuntu’da Nginx Kurulumu ve İlk Yapılandırma yazısına başvurabilirsiniz.

Nginx’in HTTPS belgesindeki düzene göre ilgili server bloğunda listen 443 ssl; bulunmalıdır. İsteğe bağlı IPv6 kullanılıyorsa listen [::]:443 ssl; satırını da denetleyin. Aynı blokta server_name example.com www.example.com;, ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ve ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem; beklenir. Laboratuvar alan adını ve ona bağlı yolları gerçek ortamınıza uyarlayın; örnek değerler çalışır internet hedefleri değildir.

nginx -t çıktısında syntax is ok ve test is successful beklenir. Başarısızsa bildirilen dosya ve satırı, sertifika erişimini ve hata günlüğünü inceleyin. Cloudflare 521 hatası sırasında bağlantı HTTP katmanına ulaşmamışsa /var/log/nginx/access.log kaydı oluşmayabilir. Sessizlik, sağlıklı bağlantı demek değildir.

Hataları giderdikten sonra çalışan servise doğrulanmış yapılandırmayı reload ile uygulayın; körlemesine yeniden başlatmayın:

sudo nginx -t && sudo systemctl reload nginx

Servis durmuşsa bunun yerine testi takiben başlatın:

sudo nginx -t && sudo systemctl start nginx

İşlemden sonra servis durumunu ve günlükleri tekrar kontrol edin; ss çıktısında 443 soketinin beklenen adres ailesinde gerçekten açıldığını doğrulayın.

Cloudflare bağlantısını kesen güvenlik duvarı katmanları

Sizin bağlantınızın kabul edilmesi, Cloudflare bağlantılarının da kabul edildiğini göstermez. Yol farklıdır. Cloudflare’ın 521 belgesi, kaynak sunucunun bağlantıyı reddetmesini ve Cloudflare adreslerinin engellenmesini olası nedenler arasında gösterir. Varsayımsal Ubuntu Server 24.04 LTS laboratuvarındaki Full (strict) modu için, Cloudflare’ın kaynak HTTPS gereksinimleri doğrultusunda TCP 443 yolunu inceleyin. TCP 80’in açık olması yeterli değildir.

Sunucudaki nftables kurallarını, sağlayıcı güvenlik duvarını ve varsa Fail2ban gibi otomatik engelleme araçlarını birlikte değerlendirin. Sağlayıcıda durdurulan trafik sunucuya ulaşmayabilir. Fail2ban kullanılıyorsa etkin jail’lerin engelleme listelerini kontrol edin; yalnızca Nginx ayarlarını incelemek bu katmandaki sorunu ortaya çıkarmaz. Bir katmandaki izin, diğerindeki engeli kaldırmaz.

sudo nft -a list ruleset
sudo timeout 20s tcpdump -i any -nn -c 50 'tcp port 443'

İlk komut etkin kuralları ve handle kimliklerini listeler. Çıktının /etc/nftables.conf ile aynı olduğunu varsaymayın; çalışan yapılandırma sonradan değiştirilmiş olabilir. hook input zincirlerini, öncelikleri, varsayılan politikayı, adres kümelerini ve reject/drop kurallarını inceleyin. Varsa sayaçların istek sırasında artması eşleşmeyi daraltır; sayaç bulunmaması kuralın işlemediğini göstermez.

İkinci komut tcpdump paketini gerektirir; 50 pakette veya 20 saniyede durur. Süre dolduğunda timeout için 124 çıkış kodu beklenebilir. Yakalama sürerken proxy edilen www.example.com adresine başka bir terminalden istek gönderin. Bu dokümantasyon alanını uygulamadan önce yönettiğiniz gerçek alan adıyla değiştirin. Filtre diğer HTTPS bağlantılarını da gösterebilir; görülen kaynak adreslerini Cloudflare aralıklarıyla karşılaştırın. Komut paketleri dosyaya yazmaz; çıktı terminalde görünür.

Gelen SYN ardından sunucudan RST dönmesi aktif reddetmeyle uyumludur; reject with tcp reset bunu üretebilir. Dinleyen servis bulunmaması da RST oluşturabilir. Yanıtsız tekrarlanan SYN paketleri sessiz düşürmeyle uyumludur ve Cloudflare 521 hatası yerine zaman aşımı belirtileri doğurabilir. Hiç paket görünmemesi tek başına sağlayıcı engelini kanıtlamaz.

İzin kapsamını Cloudflare’ın resmî IPv4 ve IPv6 adres aralıklarından oluşturun; statik, eksik liste kopyalamayın. CIDR gösterimi, tek adres yerine ağ aralığını eşleştirmenizi sağlar. Bu ortamda izinleri TCP 443 ve HTTP kontrolü ile HTTPS yönlendirmesinde kullanılan TCP 80 üzerinden değerlendirin.

İzin kuralını mevcut zincir sırası ve varsayılan politikayla birlikte ele alın; başka bir temel zincir, önceki kabulden sonra paketi düşürebilir. Güvenlik duvarını kapatmayın. Değişiklikten önce SSH erişimini koruyun ve sağlayıcı konsolundan eski kurallara dönebileceğinizi doğrulayın.

Full (strict) için HTTPS yolunu tamamlayın

TCP 80 üzerinden yanıt almak, kaynak sunucunun HTTPS bağlantısını kabul ettiğini göstermez. Cloudflare’ın 521 belgesi, Full (strict) kullanırken kaynakta TCP 443 erişiminin gerektiğini belirtir. Dinleyici yoksa bağlantı reddedilebilir. Katmanı ayırın. TCP bağlantısından sonraki TLS el sıkışması ve sertifika doğrulaması, farklı hata noktalarıdır.

Varsayımsal Ubuntu Server 24.04 LTS ve Nginx 1.24.0 laboratuvarında aşağıdaki blok, /etc/nginx/sites-available/example.com dosyasındaki asgari HTTPS yapılandırmasını gösterir. Nginx’in HTTPS belgesine uygun olarak dinleyici, sertifika zinciri ve özel anahtar birlikte tanımlanır. Sabit yanıt tanılama içindir; mevcut uygulamanızın location bloklarını bununla değiştirmeyin. TCP 80 üzerindeki HTTPS yönlendirmesini koruyun.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    location / {
        return 200 "HTTPS endpoint ready\n";
    }
}

/etc/nginx/sites-enabled/example.com bağlantısının bu dosyayı etkinleştirdiğini doğrulayın. İsteğe bağlı 2001:db8::10 adresi sunucuya atanmışsa ve proxy edilen kayıtta kullanılıyorsa aynı bloğa listen [::]:443 ssl; ekleyin. Denetim başarılıysa yapılandırmayı yeniden yükleyin:

sudo nginx -t && sudo systemctl reload nginx

Denetimde syntax is ok ve test is successful ifadeleri beklenir; bunlar dışarıdan erişimi kanıtlamaz. Sertifika okunamıyorsa veya anahtarla eşleşmiyorsa bildirilen hatayı giderin. Özel anahtarı herkese okunabilir yapmak çözüm değildir.

Aşağıdaki OpenSSL 3.0.x komutları kaynağa doğrudan bağlanır; SNI ile www.example.com adını gönderir. Alan adları ve IP adresleri dokümantasyon değerleridir, çalışır internet hedefleri değildir. Çalıştırmadan önce yönettiğiniz gerçek değerlerle değiştirin.

openssl s_client -connect 192.0.2.10:443 \
  -servername www.example.com \
  -verify_hostname www.example.com \
  -verify_return_error -CApath /etc/ssl/certs \
  -showcerts </dev/null

openssl s_client -connect 192.0.2.10:443 \
  -servername www.example.com -showcerts </dev/null |
  openssl x509 -noout -subject -issuer -dates -ext subjectAltName

İlk komutta başarılı doğrulama için Verify return code: 0 (ok) beklenir; zincir, istenen ad ve geçerlilik yerel güven deposuyla denetlenir. -showcerts sunucunun gönderdiği sertifikaları listeler. İkinci komut yalnızca yaprak sertifikanın ayrıntılarını gösterir, bağımsız doğrulama yapmaz. subjectAltName içinde example.com ve www.example.com adlarını, notBefore ve notAfter alanlarında tarih aralığını kontrol edin.

Cloudflare’ın Full (strict) belgesi; süresi geçerli, istenen adla eşleşen, genel güvenilir bir otoritenin veya Cloudflare Origin CA’nın verdiği sertifikayı şart koşar. Buradaki Let’s Encrypt zinciri yerel CA deposuyla doğrulanabilir; Origin CA varsayılan olarak aynı depoda güvenilir değildir.

Cloudflare 521 hatası ile TLS el sıkışması başarısızlığını belirten 525’i veya sertifika doğrulama sorununu belirten 526’yı eşitlemeyin. Flexible’a geçmek ya da doğrulamayı kapatmak yerine, Full (strict) için 443 dinleyicisini ve sunulan sertifika zincirini düzeltin.

Düzeltmeyi Cloudflare üzerinden doğrulayın

Sayfanın açılması tek başına yeterli değildir. Önbellek yanıltabilir. Cloudflare’ın 521 belgesi, hatayı kaynak sunucunun Cloudflare bağlantısını reddetmesiyle ilişkilendirir; doğrulama bu nedenle hem doğrudan kaynağı hem Cloudflare üzerinden geçen isteği kapsamalıdır. Önbellekteki başarılı yanıt, bağlantı sorunu devam ederken de görüntülenebilir.

Varsayımsal Ubuntu Server 24.04 LTS laboratuvarında turuncu bulut açık, mod Full (strict), kaynak portu TCP 443 olarak kalır. Cloudflare’ın Full (strict) belgesi, kaynak sertifikasının doğrulanmasını gerektirir. Doğrudan testte de sertifika denetimini koruyun; curl komutuna -k eklemeyin. Dokümantasyon değerleri www.example.com ve 192.0.2.10 çalışır hedefler değildir; komutlardan önce yönettiğiniz gerçek değerlerle değiştirin.

Geçici bir Cloudflare Cache Rule ile ana makinesi www.example.com, yolu /, sorgu dizesi cf521check= içeren isteklerde önbelleği atlayın. Çakışan kuralları kontrol edin. Yalnızca sorgu parametresi eklemek yeterli değildir; önbellek anahtarı sorgu dizesini yok sayabilir. Doğrudan testi, kaynak güvenlik duvarının izin verdiği bir noktadan yürütün; doğrulama uğruna erişimi herkese açmayın.

date -u +'%Y-%m-%dT%H:%M:%SZ'
token=$(date -u +%Y%m%dT%H%M%SZ)

curl -sS --connect-timeout 5 --max-time 20 \
  --resolve www.example.com:443:192.0.2.10 \
  -D - -o /dev/null \
  "https://www.example.com/?cf521check=${token}-origin"

curl -sS --connect-timeout 5 --max-time 20 \
  -D - -o /dev/null \
  "https://www.example.com/?cf521check=${token}-cloudflare"

curl -sS --connect-timeout 5 --max-time 20 \
  -D - -o /dev/null https://www.example.com/

İlk GET isteği, alan adını ve TLS SNI bilgisini koruyarak kaynağa bağlanır. İkincisi Cloudflare üzerinden önbelleği atlaması beklenen kontrolü, üçüncüsü normal adresi sorgular. -D - başlıkları gösterir; -o /dev/null gövdeyi gizler. Sağlıklı ana sayfa için beklenen çıktı örneğin 200 durum kodudur; uygulamanız yönlendiriyorsa hedefi ayrıca denetleyin.

CF-Cache-Status: HIT kaynak sağlığını kanıtlamaz. Kontrol yanıtındaki BYPASS veya DYNAMIC değerini, kaynakta /var/log/nginx/access.log içinde aynı zaman belirtecini taşıyan -cloudflare isteğiyle eşleştirin. Başlığın yokluğu da kanıt değildir. Önbelleğin atlandığını ve isteğin kaynağa ulaştığını birlikte doğrulamadan düzeltmeyi tamamlanmış saymayın.

İzlemeyi ayırın: dış HTTPS kontrolü Cloudflare üzerinden beklenen durum kodunu ve içeriği denetlesin; kaynakta systemctl is-active nginx servis durumunu izlesin. active, dış erişimin sağlıklı olduğunu göstermez. VPS’te Prometheus ve Grafana ile İzleme yaklaşımında bu iki sinyal için ayrı alarmlar tanımlayabilirsiniz.

Cloudflare 521 hatası sürerse destek kaydına UTC zaman damgasını, hata kodunu, varsa CF-Ray değerini, hedef TCP 443 portunu ve hassas bilgilerden arındırılmış ilgili access.log/error.log kesitlerini ekleyin. Geçici kuralı kaldırdıktan sonra normal URL’nin değişiklik sonrası kullandığı gerçek kaynak IP ve port yolunu yeniden kontrol edin.

Değişiklikten Önce ve Sonra Kontrol Edin

• Cloudflare panelindeki proxy durumunu, A hedefini ve kullanılıyorsa AAAA hedefini gerçek kaynak yapılandırmasıyla karşılaştırın.
• SSL/TLS modunun Full (strict) olduğunu ve Origin Rules ile hedef portun değiştirilmediğini doğrulayın.
• Yetkili bir dış noktadan curl –resolve ile alan adını koruyarak kaynağa bağlanın ve bağlantı, TLS ve HTTP sonuçlarını ayrı kaydedin.
• systemctl status nginx, ss -ltnp, nginx -t ve journalctl -u nginx çıktılarıyla servis durumunu ve TCP 443 dinleyicisini denetleyin.
• Sunucu ve sağlayıcı güvenlik duvarlarında Cloudflare'ın resmî adres aralıklarını, kural sırasını ve SSH için geri dönüş erişimini kontrol edin.
• Etkin sanal sunucu bağlantısını, sertifika adlarını, zincirini ve geçerlilik süresini doğrulayın; çalışan Nginx'e değişikliği yalnızca başarılı yapılandırma testinden sonra reload ile uygulayın.
• Cloudflare üzerinden önbelleğe alınmadığı doğrulanan yanıtı sınayın; hata sürerse UTC zamanı, varsa Ray ID, hedef port ve hassas bilgilerden arındırılmış loglarla destek kaydı açın.

Sık Sorulan Sorular

Kaynaklar

• Cloudflare – Error 521: Web server is down — developers.cloudflare.com
• Cloudflare – Resmî IPv4 ve IPv6 adres aralıkları — cloudflare.com
• Cloudflare – Full (strict) kaynak HTTPS gereksinimleri — developers.cloudflare.com
• Nginx – HTTPS sunucularının yapılandırılması — nginx.org