502, Nginx'in size "sayfayı başka bir şeyden istedim ve kullanamayacağım bir yanıt aldım" demesidir. Nginx'in kendisi çalışıyordur — çalışmasaydı hiçbir şey göremezdiniz — demek ki kusur onun arkasındadır, ve neredeyse her zaman PHP'dedir.
Dördünden hangisi olduğunu anlayın
Önce hata kaydını okuyun. Sebebi tek satırda söyler; tahmine harcanan her dakika, onu okumaya harcanmamış bir dakikadır.
tail -50 /var/log/nginx/error.log- connect() failed (111: Connection refused) — PHP-FPM çalışmıyor.
- upstream timed out — PHP çalışıyor ama tanınan süreden uzun sürdü.
- recv() failed (104: Connection reset by peer) — PHP işçisi istek ortasında öldü, genellikle bellek yetmediği için.
- no live upstreams — havuzda yanıt verecek işçi kalmadı.
PHP-FPM çalışmıyor
- Bakın — systemctl status php8.3-fpm — durmuş bir hizmet bunu ilk satırda söyler.
- Başlatın — systemctl start php8.3-fpm
- Neden durduğunu bulun — journalctl -u php8.3-fpm --since "1 hour ago" — havuz yapılandırmasındaki bozuk bir satır onu daha açılışta durdurur, ve yine duracaktır.
php-fpm8.3 -t komutunu çalıştırın. Havuz dosyalarını doğrular ve beğenmediği satırın adını verir.PHP, tanınan süre için fazla yavaş
Varsayılan, PHP'ye 60 saniye tanır. Yavaş bir içe aktarma ya da yanıt vermeyi kesmiş dış bir API bunu aşar, ve Nginx sonsuza kadar beklemek yerine 502 döndürür.
location ~ \.php$ {
fastcgi_read_timeout 300;
}İşçi öldü
memory_limit değerini aşan bir istek kendi işçisini öldürür, Nginx de bağlantının sıfırlandığını görür. PHP'nin hata kaydı dosyayı ve satırı adıyla söyler.
grep -i "allowed memory size" /var/log/php8.3-fpm.log | tailHavuzda işçi kalmadı
Bütün işçiler meşguldür, yeni bir isteğin gidecek yeri yoktur. Bu bir kapasite sorunudur ve dürüst çözüm ya daha az yavaş istek ya da daha çok işçidir — ama aynı bellekle daha çok işçi, arızayı yalnızca başka bir yere taşır.
pm.max_children = 20
pm.max_requests = 500