Web sitenizdeki 502 Bad Gateway, 503 ve 504 hatalarını çözün

502, 503 ve 504 hataları uygulamanızın önündeki web sunucusundan veya proxy'den gelir: o çalışıyordur, ama arkasındaki uygulama (PHP-FPM, Node.js, Python veya başka bir arka uç) doğru yanıt vermemiştir. Kayıtlar neredeyse her zaman nedeni söyler. Komutlar Ubuntu ve Debian'da PHP-FPM ile nginx veya Apache içindir; aynı yaklaşım diğer arka uçlarda da işe yarar.

1. adım: Hata kaydını okuyun

sudo tail -n 50 /var/log/nginx/error.log
sudo tail -n 50 /var/log/apache2/error.log

Hata veren sayfayı yenileyin ve komutu tekrar çalıştırın: en yeni satırlar bu isteği anlatır. Aşağıdaki mesajlar hangi bölümü okumanız gerektiğini gösterir.

502 Bad Gateway

Web sunucusu arka uçtan geçerli bir yanıt alamadı. Tipik nginx mesajları:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) while connecting to upstream
connect() to unix:/run/php/php8.3-fpm.sock failed (13: Permission denied) while connecting to upstream
upstream prematurely closed connection while reading response header from upstream

Arka uç çalışıyor mu? PHP-FPM servisini bulun ve kontrol edin; adı PHP sürümünü içerir:

systemctl list-units 'php*-fpm*'
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

php8.3-fpm yerine ilk komuttaki adı yazın. Durmuşsa sudo systemctl start ile başlatın ve neden durduğunu okuyun.

Soket yolu eşleşiyor mu? nginx sitenizdeki fastcgi_pass satırı, PHP-FPM havuzunun dinlediği soketi (/etc/php/ altındaki havuz dosyasında listen =) göstermelidir. Bir PHP yükseltmesinden sonra yoldaki sürüm çoğu zaman değişir.

Sokette Permission denied, web sunucusu kullanıcısının onu kullanamadığı anlamına gelir. Havuz dosyasındaki listen.owner, listen.group ve listen.mode ayarlarını kontrol edin.

Prematurely closed, PHP sürecinin isteği işlerken çöktüğü veya sonlandırıldığı anlamına gelir: PHP-FPM kaydına ve bellek yetersizliği sonlandırmaları için journalctl -k çıktısına bakın.

Değişikliklerden sonra test edip yeniden yükleyin:

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl restart php8.3-fpm

503 Service Unavailable

Servis işi reddediyor. Sık nedenler:

• Tüm PHP işçileri meşgul. PHP-FPM kaydı server reached pm.max_children setting gösterir. Her işçi bellek kullanır; bu yüzden pm.max_children değerini yalnızca belleğin elverdiği kadar artırın (kabaca: kullanılabilir bellek bölü bir işçinin kullandığı bellek) ve yavaş istekleri önbellekle azaltın.
• Uygulamanın bakım modu (örneğin yarıda kalmış bir güncellemeden sonra). Güncellemeyi tamamlayın veya geri alın.
• nginx'teki hız sınırları (limit_req) veya bir web uygulaması güvenlik duvarı istekleri reddediyor. Kayıtta sınırlama mesajlarına bakın.
• Sınırlarına ulaşmış bir hosting hesabı. Paylaşımlı hostingte kaynak sınırları (CPU, bellek, giriş süreçleri) 503 hatası döndürebilir; kontrol panelinizdeki kaynak kullanımına bakın veya daha büyük bir plana geçin.

504 Gateway Timeout

Arka uç zaman aşımı içinde yanıt vermedi. nginx şunu kaydeder:

upstream timed out (110: Connection timed out) while reading response header from upstream

Neyin yavaş olduğunu bulun: bir veritabanı sorgusu, bir dış API çağrısı, büyük bir içe aktarma. Veritabanınızın yavaş sorgu kaydı ve uygulamanın kendi kayıtları yardımcı olur. Yalnızca doğası gereği yavaş olan istekler için nginx location bloğundaki zaman aşımlarını artırın, örneğin:

fastcgi_read_timeout 120s;
proxy_read_timeout 120s;

PHP-FPM için fastcgi_read_timeout, proxy_pass arkasındaki arka uçlar için proxy_read_timeout kullanın. PHP'nin kendi max_execution_time ayarı ve havuzdaki request_terminate_timeout betiği daha erken durdurabilir; bunları tutarlı tutun.

Apache

Apache'de mod_proxy veya mod_proxy_fcgi kaynaklı proxy hataları için /var/log/apache2/error.log dosyasına bakın; örneğin arka uca başarısız bağlantılar veya zaman aşımları. Nedenler aynıdır: arka uç durmuştur, soketi veya portu SetHandler ya da ProxyPass satırıyla eşleşmiyordur ya da çok yavaştır. ProxyTimeout, Apache'nin bekleme süresini belirler. sudo systemctl reload apache2 öncesinde yapılandırmayı sudo apachectl configtest ile test edin.

Cloudflare arkasında

520 ile 526 arasındaki hatalar, sunucunuz Cloudflare'e iyi bir yanıt vermediğinde Cloudflare'den gelir:

Sunucuyu Cloudflare'i atlayarak doğrudan curl -I --resolve example.com:443:203.0.113.10 https://example.com ile test edin. Bkz. sitenizin önünde Cloudflare.

Ne zaman destek bildirimi açmalı?

Sunucunun kendisine erişilemiyorsa ya da hatalar sizin tarafınızda hiçbir değişiklik olmadan başlıyor ve kayıtlar bir şey göstermiyorsa hizmeti seçerek; URL'yi, saati saat dilimiyle ve ilgili kayıt satırlarını ekleyerek bir destek bildirimi açın. Hosting planlarında alan adını ve kontrol panelindeki hata kaydından bir alıntıyı ekleyin.

Sonraki adımlar

• Kaynaklar tükeniyor: yüksek CPU veya bellek kullanımı.
• Siteyi uçta koruyun: sitenizin önünde Cloudflare.