Nginx “502 Bad Gateway” Hatası Nasıl Düzeltilir?

h1>Nginx “502 Bad Gateway” Hatası Nasıl Düzeltilir?

502 Bad Gateway, Nginx’in bir reverse proxy olarak arkadaki uygulamaya (PHP-FPM, Node.js, Python/uwsgi, upstream başka bir Nginx/Apache) erişemediği veya düzgün yanıt alamadığı durumlarda verdiği hatadır. Yani çoğu zaman sorun Nginx’te değil, Nginx’in konuşmaya çalıştığı arka uç (backend) servisindedir. Bu rehberde, 502 hatasının en yaygın nedenlerini ve adım adım nasıl çözülebileceğini anlatıyoruz.

502 Bad Gateway Nedir?

Nginx istemciden (tarayıcı) isteği alır, bunu arka uç sunucuya iletir. Arka uç sunucu yanıt vermezse, geç yanıt verirse ya da bozuk bir yanıt verirse Nginx “Ben geçit görevini yapamadım” diyerek 502 döner.

Yaygın Nedenler

• PHP-FPM servisinin durmuş olması
• Arka uç uygulamanın (Node.js, Gunicorn, Django) çalışmıyor olması
• Yanlış fastcgi_pass veya proxy_pass adresi
• Socket izin hatası (/run/php/php8.2-fpm.sock vb.)
• Uygulamanın çok uzun sürede yanıt vermesi (timeout)
• Upstream sunucunun firewall ile engellenmesi

1) Nginx Hata Loglarını Kontrol Edin

İlk adım, hatanın tam kaynağını logdan görmek olmalı:

tail -f /var/log/nginx/error.log

Burada “connect() to unix:/run/php/php8.2-fpm.sock failed” veya “(111: Connection refused)” gibi net bir açıklama görürsünüz.

2) PHP-FPM Çalışıyor mu? (PHP Siteleri İçin)

502’nin en yaygın sebebi, FPM’in durmasıdır.

sudo systemctl status php8.2-fpm
# veya
sudo systemctl status php-fpm

Eğer servis durmuşsa:

sudo systemctl restart php8.2-fpm

3) Nginx Konfigürasyonunda fastcgi_pass Doğru mu?

/etc/nginx/sites-enabled/ altındaki sitede aşağıdakine benzer bir blok olmalı:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

Eğer FPM TCP portu ile çalışıyorsa:

fastcgi_pass 127.0.0.1:9000;

Buradaki soket yolunun veya portun FPM ile eşleştiğinden emin olun.

4) Socket İzinlerini Kontrol Edin

FPM soketinin Nginx kullanıcısı (genelde www-data veya nginx) tarafından okunup yazılabilir olması gerekir.

ls -l /run/php/

Gerekirse FPM pool dosyasında (/etc/php/8.2/fpm/pool.d/www.conf)

listen.owner = www-data
listen.group = www-data
listen.mode = 0660

deyip FPM’i yeniden başlatın.

5) Node.js / Uygulama Backend Çalışıyor mu?

Nginx’i reverse proxy olarak kullanıyorsanız ve proxy_pass http://127.0.0.1:3000; diyorsanız, port 3000’de uygulamanın çalıştığından emin olun:

sudo lsof -i :3000
# yoksa:
cd /var/www/app
npm start

Uygulama çöküyorsa PM2 ile sürekli çalışmasını sağlayın.

6) proxy_pass Adresi Doğru mu?

Nginx konfigürasyonunda küçük bir yazım hatası bile 502’ye yol açar:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

http://localhost:3000 yerine yanlışlıkla http://localhost:3001 yazdıysanız Nginx bağlanamaz.

7) Timeout Değerlerini Yükseltin

Backend yavaş yanıt veriyorsa Nginx “zamanında cevap gelmedi” deyip 502 atabilir. Şu ayarları site konfigürasyonuna ekleyin:

proxy_read_timeout 60s;
proxy_connect_timeout 60s;
proxy_send_timeout 60s;
fastcgi_read_timeout 60s;

8) Nginx Yapılandırmasını Test ve Reload

Değişiklikten sonra mutlaka test edin:

sudo nginx -t
sudo systemctl reload nginx

9) Upstream Sunucu Firewall ile Engelli mi?

Eğer Nginx başka bir sunucuya proxy yapıyorsa (örneğin app sunucusu 10.0.0.5:8000) o sunucuda firewall bu portu kapatmış olabilir.

telnet 10.0.0.5 8000
# veya
nc -zv 10.0.0.5 8000

10) Container / Docker Ortamlarında 502

Docker’da Nginx başka bir container’a proxy yapıyorsa, doğru container adı veya network kullanıldığından emin olun. Örnek:

proxy_pass http://app:3000;

ve her iki container’ın da aynı Docker network içinde olması gerekir.

Hızlı Kontrol Listesi

• 📄 /var/log/nginx/error.log ne diyor?
• 🟢 Backend servis (php-fpm / node / gunicorn) çalışıyor mu?
• 🛣️ Nginx’teki socket/port backend’le aynı mı?
• ⏳ Timeout değeri yeterli mi?
• 🧱 Firewall upstream’e izin veriyor mu?

Sonuç

502 Bad Gateway hatası çoğu zaman Nginx’ten değil, arka uç uygulamanın ulaşılamamasından kaynaklanır. Logları okuyup servisleri kontrol ederek birkaç dakikada çözebilirsiniz. Daha kararlı ve kaynak izolasyonu güçlü bir barındırma için VDS veya Premium VDS altyapıları üzerinde Nginx reverse proxy kullanmak daha tutarlı sonuç verir.