502, 503 ve 504 Hataları: Web Sunucusunda Teşhis Rehberi

502, 503 ve 504 aynı sorun değildir. 502 proxy'nin arka uçtan geçerli cevap alamaması; 503 servisin geçici olarak isteği karşılayamaması; 504 ise arka uç cevabının zamanında gelmemesiyle ilişkilidir. Yanıtı hangi katmanın verdiğini belirleyerek başlayın.

1. Hatanın saatini ve yanıtını kaydedin

curl -sS -D /tmp/ust-headers.txt -o /tmp/ust-body.html https://example.com/
cat /tmp/ust-headers.txt

Alan adını değiştirin. Aynı dakikaya ait proxy, PHP-FPM ve uygulama loglarını karşılaştırın. Cloudflare hata ekranı ile origin uygulamasının 503 ekranı farklı katmanlardan gelebilir.

2. Nginx + yerel Node örneğinde arka ucu sınayın

curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' http://127.0.0.1:3000/
ss -ltnp | grep ':3000'
sudo tail -n 80 /var/log/nginx/error.log

Bu port yalnızca Node örneğidir; PHP-FPM soketi HTTP ile sorgulanmaz. Connection refused genellikle dinleyen süreç olmadığını; upstream timed out ise bağlantı/yanıt zaman aşımını gösterir. Yanlış port veya soket yolu varsa proxy yapılandırmasını düzeltin.

3. Koda göre müdahale edin

502 için servis çalışıyor mu, soket izinleri doğru mu ve uygulama açılışta çöküyor mu kontrol edin. 503 için bakım modu, işçi sınırı ve kaynak limitlerini inceleyin. 504 için yavaş sorguyu veya harici API çağrısını bulun; uzun işleri kuyrukta çalıştırıp kullanıcıya iş kimliği döndürün. Timeout değerini büyütmek takılan işlemi hızlandırmaz.

Doğrulama ve geri dönüş

Yapılandırma değiştiyse önce sudo nginx -t, ardından başarılı test sonrası reload uygulayın. Ana sayfa yanında hatayı üreten URL'yi de test edin. Değişiklik kötüleştirirse önceki yapılandırmayı geri yükleyip tekrar test edin. Rastgele tüm servisleri yeniden başlatmak teşhis kanıtını kaybettirir.

Hata katmanını ayıran kısa tablo

Her değişiklikten sonra aynı problemli URL ve zaman aralığıyla ölçüm yapın. Bir GET isteği düzelirken ödeme POST'u hâlâ başarısız olabilir; gerçek kullanıcı işlemini de test edin.