- Konu sahibi
- #1
Nginx 502 Bad Gateway hatasını çözmek için önce hatanın oluştuğu andaki Nginx hata günlüğünü okuyun; ardından isteğin yönlendirildiği uygulama sunucusunu veya PHP-FPM servisini, bağlantı adresini ve izinlerini kontrol edin. Hata çoğunlukla Nginx'in arka uçtan geçerli bir yanıt alamamasıyla ilgilidir; ancak yalnızca 502 koduna bakarak hangi bileşenin bozulduğunu belirleyemezsiniz.
Sunucuya SSH ile ve gerekli yönetici yetkisiyle bağlanın. Hata veren sayfayı bir kez açıp saatini not edin. Ardından Nginx yapılandırmasını görüntüleyin:
Çıktıda ilgili alan adına ait
Saat ve istekle eşleşen kayıtta bağlantı adresine ve hata mesajına bakın. Günlük dosyası yerine sistem günlüğü veya konteyner çıktısı kullanılıyorsa, kuruluma uygun kayıtları inceleyin.
Aşağıdaki mesajlar başlangıç noktasıdır; kesin nedeni arka uç kayıtları ve yapılandırmayla doğrulayın.
Örneğin bağlantının reddedilmesi, tek başına servisin çöktüğünü kanıtlamaz: servis farklı bir portta da çalışıyor olabilir. Hata kaydında hiç upstream bağlantısı görünmüyorsa 502'yi başka bir katman veya uygulamanın kendisi üretmiş olabilir; istek zamanı ve yanıtı ilgili katmanların kayıtlarıyla karşılaştırın.
Nginx'in yönlendirdiği servisin adını dağıtımınızın veya uygulamanızın yapılandırmasından belirleyin. Systemd kullanan bir sunucuda, aşağıdaki örnekteki
Servis durmuşsa günlükteki başlatma hatasını düzeltin ve ilgili servisi başlatın. Çalışır durumdaysa bunun doğru adresi dinlediğini ayrıca kontrol edin; servis durumunun aktif olması uygulamanın doğru yanıt verdiğini kanıtlamaz. TCP bağlantısı kullanılıyorsa
PHP sitelerinde
Soket yoksa PHP-FPM servisinin çalıştığını, doğru havuzun yüklendiğini ve gerçek
Havuz ayarını kaydettikten sonra kurulumunuzun PHP-FPM yapılandırma testini çalıştırın; başarılıysa ilgili servisi yeniden yükleyin veya kullandığınız servis yöneticisinin gerektirdiği şekilde yeniden başlatın. Soketin oluştuğunu ve izinlerini tekrar kontrol edin.
Bağlantı kurulamıyorsa uygulamanın çalışmasını, dinlediği adresi ve aradaki ağ kurallarını inceleyin. HTTP yanıtı gelmesi bağlantının kurulduğunu gösterir; tek başına sorunlu sayfanın veya Nginx üzerinden yapılan isteğin doğru çalıştığını kanıtlamaz. Uygulama belirli bir alan adı ya da yol bekliyorsa, testi ilgili istekle ve uygun Host başlığıyla tekrarlayın. PHP-FPM bir FastCGI servisi olduğundan bu HTTP testini doğrudan FPM portuna uygulamayın.
Nginx adresini veya başka bir yapılandırma değerini değiştirdiyseniz önce dosyayı kaydedin, ardından aynı kurulum için yapılandırmayı sınayın ve yalnızca test başarılıysa yeniden yükleyin:
Test hata verirse gösterilen dosya ve satırı düzeltmeden yeniden yüklemeyin. Systemd kullanılmayan kurulumlarda kendi servis yöneticinizin yeniden yükleme yöntemini kullanın. Ardından hatalı sayfayı tekrar açın ve yeni hata kayıtlarını kontrol edin. Sayfanın bir kez açılması kalıcı çözümü garanti etmez; sorun yük altında veya belirli bir işlemde oluşuyorsa o isteği güvenli biçimde yeniden deneyin.
Arka uç bağlantıyı erken kapatıyorsa uygulama ve servis günlüklerinde aynı zamandaki çökme, bellek yetersizliği veya işlem hatalarını araştırın. Zaman aşımı görüyorsanız yalnızca süre sınırını artırmak yerine yavaş işlemin nedenini de inceleyin; zaman aşımı her durumda 502 üretmez. Sorun sürüyorsa sunucu yöneticisine veya barındırma desteğine hata zamanı ve saat dilimini, etkilenen adresi, temizlenmiş Nginx hata satırını, arka uç servisinin durumunu ve yaptığınız kontrolleri iletin; ilgili arka uç bağlantısının ve servis günlüklerinin incelenmesini isteyin.
Hatanın hangi bağlantıda oluştuğunu bulun
Sunucuya SSH ile ve gerekli yönetici yetkisiyle bağlanın. Hata veren sayfayı bir kez açıp saatini not edin. Ardından Nginx yapılandırmasını görüntüleyin:
Kod:
sudo nginx -TÇıktıda ilgili alan adına ait
server bloğunu, error_log yolunu ve istekleri arka uca gönderen proxy_pass veya fastcgi_pass satırını arayın. Günlük dosyası yapılandırmaya göre değişebilir; aşağıdaki yol yalnızca bir örnektir:
Kod:
sudo tail -n 100 /var/log/nginx/error.logSaat ve istekle eşleşen kayıtta bağlantı adresine ve hata mesajına bakın. Günlük dosyası yerine sistem günlüğü veya konteyner çıktısı kullanılıyorsa, kuruluma uygun kayıtları inceleyin.
nginx -T çıktısı ve günlükler hassas bilgi içerebilir; bunları paylaşmadan önce parolaları, belirteçleri, kişisel verileri ve gizli adresleri temizleyin.Aşağıdaki mesajlar başlangıç noktasıdır; kesin nedeni arka uç kayıtları ve yapılandırmayla doğrulayın.
| Günlükteki ifade | İlk kontrol |
|---|---|
| connection refused | Servis çalışıyor mu, doğru adres ve portu mu dinliyor? |
| No such file or directory | Belirtilen Unix soketi mevcut mu, yolu doğru mu? |
| Permission denied | Nginx çalışanının sokete veya bağlantıya erişim izni var mı? |
| upstream prematurely closed connection | Arka uç uygulama hatası veya işlem sonlanması kaydetmiş mi? |
Arka uç servisini ve adresini düzeltin
Nginx'in yönlendirdiği servisin adını dağıtımınızın veya uygulamanızın yapılandırmasından belirleyin. Systemd kullanan bir sunucuda, aşağıdaki örnekteki
SERVIS_ADI yerine gerçek servis adını yazarak durumunu ve son kayıtlarını inceleyin:
Kod:
sudo systemctl status SERVIS_ADI
sudo journalctl -u SERVIS_ADI -n 100 --no-pagerServis durmuşsa günlükteki başlatma hatasını düzeltin ve ilgili servisi başlatın. Çalışır durumdaysa bunun doğru adresi dinlediğini ayrıca kontrol edin; servis durumunun aktif olması uygulamanın doğru yanıt verdiğini kanıtlamaz. TCP bağlantısı kullanılıyorsa
sudo ss -ltnp çıktısındaki adres ve portu Nginx yapılandırmasıyla karşılaştırın. Uygulama başka bir sunucu veya konteynerdeyse kontrolü o ortamda da yapın; 127.0.0.1 her ortamda o ortamın kendisini gösterir.PHP-FPM soketini kontrol edin
PHP sitelerinde
fastcgi_pass ile gösterilen adres, ilgili PHP-FPM havuzunun listen değeriyle uyuşmalıdır. Örneğin Nginx /run/php/site.sock soketine bağlanacak şekilde ayarlanmışsa PHP-FPM de aynı soketi dinlemelidir. Yollar örnektir; kendi yapılandırmanızı esas alın.Soket yoksa PHP-FPM servisinin çalıştığını, doğru havuzun yüklendiğini ve gerçek
listen değerini kontrol edin. Soket varsa ls -l /run/php/site.sock ile sahip ve grup izinlerine bakın; Nginx çalışanının erişmesi gerekir. Linux'ta gerekirse PHP-FPM havuzundaki listen.owner, listen.group ve listen.mode değerlerini mevcut Nginx kullanıcısına ve grubuna uygun biçimde düzeltin. Soketi herkese yazılabilir yapmak yerine yalnız gerekli erişimi verin. PHP-FPM'nin TCP portunu herkese açık internete açmayın.Havuz ayarını kaydettikten sonra kurulumunuzun PHP-FPM yapılandırma testini çalıştırın; başarılıysa ilgili servisi yeniden yükleyin veya kullandığınız servis yöneticisinin gerektirdiği şekilde yeniden başlatın. Soketin oluştuğunu ve izinlerini tekrar kontrol edin.
HTTP uygulamasını doğrudan sınayın
proxy_pass bir HTTP uygulamasına yöneliyorsa, Nginx'in bulunduğu ortamdan yapılandırmadaki gerçek adresi sınayın. Örneğin arka uç yerel olarak 8080 portunu dinliyorsa:
Kod:
curl -i http://127.0.0.1:8080/Bağlantı kurulamıyorsa uygulamanın çalışmasını, dinlediği adresi ve aradaki ağ kurallarını inceleyin. HTTP yanıtı gelmesi bağlantının kurulduğunu gösterir; tek başına sorunlu sayfanın veya Nginx üzerinden yapılan isteğin doğru çalıştığını kanıtlamaz. Uygulama belirli bir alan adı ya da yol bekliyorsa, testi ilgili istekle ve uygun Host başlığıyla tekrarlayın. PHP-FPM bir FastCGI servisi olduğundan bu HTTP testini doğrudan FPM portuna uygulamayın.
Değişikliği uygulayın ve sonucu doğrulayın
Nginx adresini veya başka bir yapılandırma değerini değiştirdiyseniz önce dosyayı kaydedin, ardından aynı kurulum için yapılandırmayı sınayın ve yalnızca test başarılıysa yeniden yükleyin:
Kod:
sudo nginx -t
sudo systemctl reload nginxTest hata verirse gösterilen dosya ve satırı düzeltmeden yeniden yüklemeyin. Systemd kullanılmayan kurulumlarda kendi servis yöneticinizin yeniden yükleme yöntemini kullanın. Ardından hatalı sayfayı tekrar açın ve yeni hata kayıtlarını kontrol edin. Sayfanın bir kez açılması kalıcı çözümü garanti etmez; sorun yük altında veya belirli bir işlemde oluşuyorsa o isteği güvenli biçimde yeniden deneyin.
Arka uç bağlantıyı erken kapatıyorsa uygulama ve servis günlüklerinde aynı zamandaki çökme, bellek yetersizliği veya işlem hatalarını araştırın. Zaman aşımı görüyorsanız yalnızca süre sınırını artırmak yerine yavaş işlemin nedenini de inceleyin; zaman aşımı her durumda 502 üretmez. Sorun sürüyorsa sunucu yöneticisine veya barındırma desteğine hata zamanı ve saat dilimini, etkilenen adresi, temizlenmiş Nginx hata satırını, arka uç servisinin durumunu ve yaptığınız kontrolleri iletin; ilgili arka uç bağlantısının ve servis günlüklerinin incelenmesini isteyin.
