Cloudflare 524 525 526 Hataları ve Çözümleri

Cloudflare arkasında bir web sitesi yönetiyorsanız, er ya da geç 5xx hata serisiyle karşılaşacaksınız. Bu hataların bir kısmı kaynak sunucunuzdan kaynaklanırken, bir kısmı SSL/TLS yapılandırmanızla ilgilidir. Özellikle 524, 525 ve 526 hataları, Cloudflare’in kaynak sunucunuzla kurduğu bağlantıda yaşanan sorunları işaret eder ve her biri farklı bir problemi temsil eder. Bu yazıda bu üç hatayı derinlemesine inceleyecek, gerçek dünya senaryolarıyla çözüm yollarını paylaşacağız.

Cloudflare ve Kaynak Sunucu Arasındaki İlişkiyi Anlamak

Cloudflare bir CDN ve reverse proxy olarak çalışır. Kullanıcı tarayıcısı Cloudflare’e bağlanır, Cloudflare de sizin kaynak sunucunuza bağlanır. Bu iki ayrı TCP bağlantısı demektir:

Kullanıcı -> Cloudflare: Cloudflare bu bağlantıyı tamamen kontrol eder
Cloudflare -> Kaynak Sunucu: Sizin sunucunuzun durumuna bağlıdır

524, 525 ve 526 hataları her zaman ikinci bağlantıda, yani Cloudflare ile kaynak sunucunuz arasında yaşanan sorunlardır. Bu yüzden bu hataları görüyorsanız, sorunu Cloudflare arayüzünde değil, kendi sunucunuzda aramanız gerekir.

524 Hatası: A Timeout Occurred

524 hatası, Cloudflare’in kaynak sunucunuzla TCP bağlantısını başarıyla kurduğu ancak sunucunun belirlenen süre içinde HTTP yanıtı vermediği durumda oluşur. Cloudflare’in varsayılan timeout süresi 100 saniyedir.

524 Hatasının Yaygın Nedenleri

Uzun süren veritabanı sorguları
Büyük dosya işlemleri (import/export, CSV parse etme)
Harici API çağrıları bekleyen uygulamalar
PHP veya Python scriptlerinin sonlanmaması
MySQL/PostgreSQL’de kilitlenmiş (deadlock) sorgular

Gerçek Dünya Senaryosu: WooCommerce Büyük Sipariş Export

Bir e-ticaret müşterisinde 50.000 siparişin CSV olarak export edilmesi sırasında 524 hatası alınıyordu. Sorun basitti: PHP betiği çok uzun çalışıyordu ve Cloudflare bağlantıyı kesiyordu.

Önce sunucuda ne olduğunu kontrol edelim:

# Apache'de uzun süren istekleri logla
tail -f /var/log/apache2/access.log | grep -v "200|304"

# Nginx'te aktif bağlantıları gör
netstat -an | grep :80 | grep ESTABLISHED | wc -l

# PHP-FPM süreçlerini kontrol et
ps aux | grep php-fpm | grep -v grep

PHP tarafında timeout değerlerini artırmak gerekti:

# /etc/php/8.1/fpm/php.ini içinde
max_execution_time = 300
max_input_time = 300
default_socket_timeout = 300

Nginx için de proxy timeout değerlerini güncelledik:

# /etc/nginx/nginx.conf veya site konfigürasyonu
proxy_read_timeout 300s;
proxy_connect_timeout 300s;
proxy_send_timeout 300s;

# Keepalive timeout
keepalive_timeout 300s;

Ama asıl çözüm mimarisel oldu. Büyük işlemleri arka planda çalıştırmak için queue sistemi kullandık:

# Redis ve Supervisor kurulumu
apt install redis-server supervisor -y

# Laravel Queue worker için supervisor config
cat > /etc/supervisor/conf.d/laravel-worker.conf << 'EOF'
[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /var/www/html/artisan queue:work --sleep=3 --tries=3
autostart=true
autorestart=true
numprocs=4
EOF

supervisorctl reread
supervisorctl update

Cloudflare Tarafında 524 için Çözümler

Eğer Cloudflare Enterprise planındaysanız, proxy_read_timeout değerini artırabilirsiniz. Ancak ücretsiz/Pro/Business planlarda bu mümkün değildir. Alternatif olarak:

# Cloudflare'i bypass etmek için A record'u "gri bulut" yap
# API ile DNS kaydını non-proxied yap
curl -X PATCH "https://api.cloudflare.com/client/v4/zones/ZONE_ID/dns_records/RECORD_ID" 
  -H "Authorization: Bearer API_TOKEN" 
  -H "Content-Type: application/json" 
  --data '{"proxied": false}'

Long-polling veya WebSocket kullanan uygulamalar için de Cloudflare’in Argo Smart Routing özelliğini açmak gecikmeyi azaltabilir.

525 Hatası: SSL Handshake Failed

525 hatası, Cloudflare’in kaynak sunucunuzla TCP bağlantısını kurduğu ancak SSL handshake’in başarısız olduğu durumda oluşur. Bu hata tamamen SSL/TLS ile ilgilidir.

525 Hatasının Yaygın Nedenleri

Kaynak sunucuda SSL sertifikasının eksik veya hatalı yapılandırılması
Cloudflare ve kaynak sunucu arasında desteklenmeyen cipher suite
SNI (Server Name Indication) yapılandırma sorunu
Nginx/Apache’de SSL’in yanlış port veya virtual host’ta dinlenmesi
Self-signed sertifika kullanımı (Full strict modda sorun yaratır)

Gerçek Dünya Senaryosu: Yeni Sunucuya Taşıma Sonrası 525

Bir müşteri sunucularını taşıdıktan sonra 525 hatası almaya başladı. Kontrol ettiğimizde Nginx’in 443 portunu dinlemediğini gördük:

# SSL'in hangi portlarda dinlendiğini kontrol et
ss -tlnp | grep -E '443|8443'

# Veya netstat ile
netstat -tlnp | grep nginx

# Nginx konfigürasyonunu test et
nginx -t

# SSL bağlantısını manuel test et
openssl s_client -connect SUNUCU_IP:443 -servername example.com

Nginx konfigürasyonu eksikti:

# /etc/nginx/sites-available/example.com
server {
    listen 80;
    listen 443 ssl;  # Bu satır eksikti!
    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;
    
    # Cloudflare IP'leri için gerçek IP'yi al
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 104.16.0.0/13;
    set_real_ip_from 104.24.0.0/14;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 131.0.72.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    real_ip_header CF-Connecting-IP;
    
    root /var/www/html;
    index index.php index.html;
}

Cipher Suite Sorunu

Eski sunucularda desteklenmeyen cipher suite problemi sık görülür:

# Sunucunun desteklediği cipher suite'leri listele
openssl ciphers -v 'ALL:COMPLEMENTOFALL' | awk '{print $1}' | sort

# Cloudflare'in kullandığı TLS versiyonlarını test et
openssl s_client -connect SUNUCU_IP:443 
  -tls1_2 
  -servername example.com 
  2>/dev/null | grep "Protocol|Cipher"

# TLS 1.3 testi
openssl s_client -connect SUNUCU_IP:443 
  -tls1_3 
  -servername example.com 
  2>/dev/null | grep "Protocol|Cipher"

Modern cipher suite konfigürasyonu için Nginx:

# Güvenli ve Cloudflare uyumlu SSL ayarları
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

526 Hatası: Invalid SSL Certificate

526 hatası, Cloudflare’in kaynak sunucunuzla SSL bağlantısını kurabildiği ancak sertifikanın geçersiz veya güvenilir olmadığı durumda oluşur. Bu hata yalnızca Cloudflare SSL/TLS modu Full (Strict) olarak ayarlandığında görülür.

526 Hatasının Yaygın Nedenleri

Süresi dolmuş SSL sertifikası
Self-signed sertifika kullanımı (Full Strict modda)
Sertifikanın alan adıyla eşleşmemesi (wildcard sorunları)
Ara sertifikaların (intermediate/chain) eksik olması
Let’s Encrypt sertifikasının yenilenmemesi

Gerçek Dünya Senaryosu: Let’s Encrypt Yenileme Başarısızlığı

Bir müşteride gece yarısı 526 hatası geldi. Neden? Let’s Encrypt sertifikası süresi dolmuştu ve otomatik yenileme başarısız olmuştu:

# Sertifika süresini kontrol et
echo | openssl s_client -servername example.com 
  -connect example.com:443 2>/dev/null 
  | openssl x509 -noout -dates

# Veya doğrudan sertifika dosyasını kontrol et
openssl x509 -in /etc/letsencrypt/live/example.com/cert.pem 
  -noout -enddate

# Certbot ile tüm sertifikaların durumunu gör
certbot certificates

# Neden yenileme başarısız oldu?
tail -100 /var/log/letsencrypt/letsencrypt.log

Yenilemenin neden başarısız olduğunu incelediğimizde Cloudflare’in HTTP-01 challenge‘ı engellediğini gördük. Çözüm DNS-01 challenge kullanmaktı:

# Cloudflare DNS API ile DNS-01 challenge
pip install certbot-dns-cloudflare

# Cloudflare credentials dosyası oluştur
mkdir -p /root/.secrets
cat > /root/.secrets/cloudflare.ini << 'EOF'
dns_cloudflare_api_token = YOUR_API_TOKEN_HERE
EOF
chmod 600 /root/.secrets/cloudflare.ini

# DNS-01 ile sertifika al/yenile
certbot certonly 
  --dns-cloudflare 
  --dns-cloudflare-credentials /root/.secrets/cloudflare.ini 
  -d example.com 
  -d '*.example.com' 
  --preferred-challenges dns-01

# Otomatik yenileme için cron
echo "0 0,12 * * * root certbot renew --quiet" >> /etc/crontab

Sertifika Chain Sorununu Teşhis Etme

Bazen sertifika zinciri eksik olur ve bu 526 hatasına yol açar:

# Sertifika zincirini kontrol et
openssl s_client -connect SUNUCU_IP:443 
  -servername example.com 2>/dev/null 
  | openssl x509 -noout -text | grep "Issuer|Subject"

# Tüm zinciri görüntüle
openssl s_client -showcerts 
  -connect SUNUCU_IP:443 
  -servername example.com 2>/dev/null

# Chain'i doğrula
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt 
  /etc/letsencrypt/live/example.com/fullchain.pem

Nginx’te fullchain.pem yerine sadece cert.pem kullanılması sık yapılan hatadır:

# YANLIS - sadece sertifika, chain yok
ssl_certificate /etc/letsencrypt/live/example.com/cert.pem;

# DOGRU - tam chain dahil
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Cloudflare SSL Modları ve Hata İlişkisi

Cloudflare panelinde SSL/TLS sekmesinde dört mod bulunur:

Off: HTTPS kullanılmaz, 525/526 görmezsiniz ama güvensizdir
Flexible: Cloudflare ile kullanıcı arasında HTTPS, Cloudflare ile kaynak sunucu arasında HTTP. 525/526 almaz ama kaynak sunucuda SSL gerekmez
Full: Kaynak sunucuda SSL zorunlu ama sertifika doğrulanmaz. Self-signed çalışır, 526 görmezsiniz
Full (Strict): Hem SSL hem de geçerli sertifika zorunlu. 526 burada görünür

Hızlı teşhis için: Eğer 526 alıyorsanız ve hızlı çözüm gerekiyorsa, geçici olarak Full (Strict) moddan Full moda geçebilirsiniz. Ama bu kalıcı çözüm değildir.

Hataları Proaktif Olarak İzleme

Bu hataları yaşanmadan önce tespit etmek için izleme scriptleri kullanabilirsiniz:

#!/bin/bash
# ssl_monitor.sh - SSL sertifika süresini izle

DOMAIN="example.com"
WARN_DAYS=30
ALERT_EMAIL="[email protected]"

# Sertifika bitiş tarihini al
EXPIRY=$(echo | openssl s_client -servername "$DOMAIN" 
  -connect "$DOMAIN":443 2>/dev/null 
  | openssl x509 -noout -enddate 
  | cut -d= -f2)

EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s)
NOW_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $NOW_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt $WARN_DAYS ]; then
    echo "UYARI: $DOMAIN sertifikasi $DAYS_LEFT gun sonra sona eriyor!" 
    | mail -s "SSL Sertifika Uyarisi: $DOMAIN" "$ALERT_EMAIL"
    echo "Kritik: $DAYS_LEFT gun kaldi"
else
    echo "SSL OK: $DAYS_LEFT gun kaldi"
fi

# HTTP response kodlarini izle
#!/bin/bash
# cloudflare_health_check.sh

ENDPOINTS=(
    "https://example.com"
    "https://api.example.com/health"
    "https://www.example.com/robots.txt"
)

for URL in "${ENDPOINTS[@]}"; do
    HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" 
      --max-time 30 
      --connect-timeout 10 
      "$URL")
    
    if [[ "$HTTP_CODE" == "524" ]]; then
        echo "$(date): 524 Timeout - $URL"
        # Alert gonder
    elif [[ "$HTTP_CODE" == "525" ]]; then
        echo "$(date): 525 SSL Handshake Failed - $URL"
    elif [[ "$HTTP_CODE" == "526" ]]; then
        echo "$(date): 526 Invalid Certificate - $URL"
    else
        echo "$(date): HTTP $HTTP_CODE - $URL OK"
    fi
done

Cloudflare Origin CA Sertifikaları

526 hatasından kurtulmanın en temiz yolu Cloudflare’in kendi Origin CA sertifikalarını kullanmaktır. Bu sertifikalar yalnızca Cloudflare tarafından güvenilir, 15 yıla kadar geçerlidir ve tamamen ücretsizdir:

# Cloudflare Origin CA ile imzalanmış sertifika almak için
# Cloudflare Dashboard > SSL/TLS > Origin Server > Create Certificate

# Oluşturulan sertifikayı sunucuya kaydet
cat > /etc/ssl/cloudflare-origin.pem << 'EOF'
-----BEGIN CERTIFICATE-----
[BURAYA CLOUDFLARE'DEN ALINAN SERTIFIKA]
-----END CERTIFICATE-----
EOF

cat > /etc/ssl/cloudflare-origin-key.pem << 'EOF'
-----BEGIN PRIVATE KEY-----
[BURAYA OZEL ANAHTAR]
-----END PRIVATE KEY-----
EOF

chmod 600 /etc/ssl/cloudflare-origin-key.pem

# Nginx konfigurasyonu
server {
    listen 443 ssl;
    ssl_certificate /etc/ssl/cloudflare-origin.pem;
    ssl_certificate_key /etc/ssl/cloudflare-origin-key.pem;
    
    # Cloudflare Authenticated Origin Pulls
    ssl_client_certificate /etc/ssl/cloudflare-authenticated-origin.pem;
    ssl_verify_client on;
}

Hızlı Teşhis Checklist

524 hatası alıyorsanız:

Sunucu tarafında: php.ini timeout değerlerini, Nginx/Apache proxy timeout’larını kontrol edin
Uygulama tarafında: Uzun süren sorguları, harici API çağrılarını inceleyin
Cloudflare tarafında: Enterprise değilseniz long-polling işlemlerini Cloudflare dışında tutun

525 hatası alıyorsanız:

Kaynak sunucuda 443 portunun dinlenip dinlenmediğini kontrol edin
openssl s_client ile manuel handshake test edin
Nginx/Apache SSL konfigürasyonunu doğrulayın
Cipher suite uyumluluğunu kontrol edin

526 hatası alıyorsanız:

Sertifika süresini kontrol edin
fullchain.pem kullanıldığından emin olun
Cloudflare SSL modunu geçici olarak Full’a çekin
Cloudflare Origin CA kullanmayı değerlendirin

Sonuç

524, 525 ve 526 hataları farklı problemleri işaret etse de hepsinin ortak noktası şudur: sorun Cloudflare’de değil, sizin altyapınızda ya da yapılandırmanızdadır. Bu hataları gördüğünüzde paniğe gerek yok; metodolojik yaklaşıp önce hangi hata olduğunu belirleyin, sonra yukarıdaki teşhis adımlarını takip edin.

Uzun vadeli bir çözüm için önerilerim şunlar: Cloudflare Origin CA sertifikalarını kullanın, Let’s Encrypt yenileme süreçlerinizi DNS-01 challenge ile yapılandırın, uzun süren işlemleri asenkron queue sistemlerine taşıyın ve SSL sertifika sürelerini proaktif olarak izleyin. Bu dört adımı uygularsanız, 5xx hatalarıyla karşılaşma sıklığınız ciddi ölçüde azalacaktır.

Sorularınız veya farklı senaryolarınız varsa yorum bölümünde paylaşabilirsiniz.

Cloudflare Hata Ayıklama: 524, 525 ve 526 Hataları