Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
İstek akışıİstemci, NGINX ve backend arasındaki kopma noktası
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
502 Bad Gateway, NGINX’in istemci isteğini aldığı ancak PHP-FPM, Node.js, Python, Docker veya başka bir upstream servisten geçerli yanıt alamadığı anlamına gelir. Bu rehber servis, port, Unix socket, proxy_pass, izin ve güvenlik katmanlarını doğru sırayla ayırır.
2026/07/17 03:14:28 [error] 2187#2187: *904 connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) while connecting to upstream
2026/07/17 03:14:28 [error] 2187#2187: *904 connect() failed (111: Connection refused) while connecting to upstreamNGINX ön tarafta çalışırken arkadaki uygulama servisine bağlanamadığında veya backend geçersiz/yarım yanıt verdiğinde 502 üretir. Bu nedenle yalnız NGINX’i yeniden başlatmak çoğu vakada kalıcı çözüm değildir.
İlk ayrım, hatanın tek bir domainde mi yoksa NGINX arkasındaki tüm uygulamalarda mı görüldüğüdür. Tek domain genellikle vhost, socket veya uygulama servisine; tüm domainler ortak PHP-FPM, NGINX, ağ ya da kaynak sorununa işaret eder.
Unix socket kullanılan PHP-FPM yapılandırmalarında socket dosyasının yolu, sahibi ve izinleri fastcgi_pass satırıyla birebir eşleşmelidir. PHP sürümü değiştiğinde eski socket yolunun vhost dosyasında kalması sık görülen bir nedendir.
TCP upstream kullanılıyorsa hedef IP ve portun gerçekten dinlenmesi gerekir. Container, Node.js veya Python servisi yeniden başladıktan sonra port değişmiş, servis yalnız localhost yerine farklı arayüze bağlanmış veya firewall bağlantıyı engelliyor olabilir.
Cloudflare ekranındaki 502 ile origin NGINX’in ürettiği 502 aynı değildir. Önce origin IP’ye ve localhost backend’e doğrudan istek göndererek hatanın hangi katmanda başladığı belirlenmelidir.
502’de timeout değerlerini yükseltmeden önce backend’in ayakta, doğru portta ve NGINX worker kullanıcısı tarafından erişilebilir olduğu kanıtlanmalıdır.
E-postada, tarayıcıda veya SSH günlüğünde gördüğünüz ifadeyi aratın. Her kartta anlam, muhtemel neden ve güvenli ilk işlem bulunur.
Anlamı: Hedef IP ve port bağlantıyı kabul etmiyor.
Muhtemel neden: Backend kapalı, yanlış port veya servis yalnız farklı arayüzde dinliyor.
Anlamı: NGINX’in kullandığı socket yolu mevcut değil.
Muhtemel neden: PHP-FPM sürümü, pool adı veya socket yolu değişmiş.
Anlamı: Socket mevcut fakat NGINX worker erişemiyor.
Muhtemel neden: Socket sahibi, grup, mod veya SELinux context uyumsuz.
Anlamı: Upstream grubunda kullanılabilir backend kalmamış.
Muhtemel neden: Tüm sunucular başarısız işaretlenmiş veya DNS/health durumu bozuk.
Anlamı: Backend yanıt tamamlanmadan bağlantıyı kapattı.
Muhtemel neden: Uygulama crash, process kill, bellek tükenmesi veya protokol uyumsuzluğu.
Anlamı: Karşı taraf bağlantıyı zorla sıfırladı.
Muhtemel neden: Backend restart, uygulama hatası veya ağ güvenlik katmanı.
Anlamı: Backend HTTP/FastCGI protokolüne uygun başlık üretmedi.
Muhtemel neden: Yanlış proxy protokolü, bozuk uygulama çıktısı veya FastCGI portuna HTTP gönderimi.
Anlamı: Tarayıcıdaki genel hata kök nedeni gizler.
Muhtemel neden: Servis, socket, port, izin veya uygulama katmanı.
Bu ifadeyle eşleşen kayıt bulunamadı.
Komutlar root erişimi içindir. Önce yalnızca durum ve log toplayın; nedeni görmeden kalıcı ayar değiştirmeyin.
nginx -t
nginx -T | grep -nE 'server_name|proxy_pass|fastcgi_pass'Sözdizimini test eder ve etkin upstream hedeflerini gösterir.
systemctl status nginx php8.3-fpm --no-pager
ss -lntp
ss -lxnp | grep -E 'php|fpm'NGINX, PHP-FPM, TCP portları ve Unix socketleri doğrular.
tail -n 150 /var/log/nginx/error.log
journalctl -u nginx -u php8.3-fpm -n 150 --no-pagerNGINX ve backend servis hatalarını aynı zaman aralığında karşılaştırır.
curl -sv http://127.0.0.1:3000/ -o /dev/null
curl -skI https://example.com/Reverse proxy arkasındaki servisi NGINX’ten bağımsız test eder.
namei -l /run/php/php8.3-fpm.sock
stat /run/php/php8.3-fpm.sock
ps -eo user,group,cmd | grep '[n]ginx: worker'Socket yolundaki tüm klasörlerin ve worker kullanıcısının erişimini gösterir.
nginx -t && systemctl reload nginx
systemctl restart php8.3-fpmNGINX’i kesintisiz yükler; yalnız backend gerektiğinde yeniden başlatılır.
NGINX hatasının temel nedeni aynı olsa da paket yolları, servis adları, güvenlik katmanları ve sanal host yönetimi kullanılan Linux dağıtımına veya Plesk altyapısına göre değişir.
NGINX 502 Bad Gateway için systemd, paket yolu ve journald kontrolleri.
systemctl status nginx php8.3-fpm --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.logNGINX 502 Bad Gateway için SELinux, PHP-FPM pool ve RHEL tabanlı servis kontrolleri.
systemctl status nginx php-fpm --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.logPlesk tarafından üretilen NGINX sanal host dosyalarında nginx 502 bad gateway kontrolü.
plesk repair web example.com -y
systemctl status nginx sw-engine --no-pager
nginx -tServisi rastgele yeniden başlatmak yerine hatanın NGINX, socket, backend veya güvenlik katmanında oluştuğunu kanıtlayarak ilerleyin.
Tek domain, tek PHP sürümü veya tüm upstream uygulamalar mı etkileniyor ayırın.
for u in https://example.com https://diger.example.com; do curl -sk -o /dev/null -w "$u %{http_code}\n" "$u"; doneTarayıcı mesajına değil, upstream hata satırına göre kök nedeni sınıflandırın.
tail -f /var/log/nginx/error.logSocket veya TCP port hedefinin gerçekten açık olduğunu kanıtlayın.
ss -lntp; ss -lxnp | grep -E 'php|fpm'fastcgi_pass veya proxy_pass değerini gerçek listen adresiyle eşleştirin.
nginx -T | grep -nE 'fastcgi_pass|proxy_pass'Socket erişimi, SELinux ve firewall bloklarını inceleyin.
namei -l /run/php/php8.3-fpm.sock; getenforce 2>/dev/nullSözdizimi başarılıysa reload edin ve hem origin hem backend’i tekrar ölçün.
nginx -t && systemctl reload nginx
curl -skI https://example.com/Eski PHP-FPM socket yolu vhost dosyasında kalmış olabilir.
grep -R 'fastcgi_pass' /etc/nginx /etc/plesk 2>/dev/nullContainer portu, network adı veya health durumu değişmiş olabilir.
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'PM2/systemd process durmuş veya uygulama yalnız farklı porta bağlanmış olabilir.
systemctl status uygulama --no-pager; ss -lntpSocket group/mode veya SELinux context uyumsuzluğunu inceleyin.
stat /run/php/php8.3-fpm.sock; ausearch -m AVC -ts recent | tailOrigin’e doğrudan erişim ile Cloudflare katmanını ayırın.
curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/Domainin üretilen NGINX/PHP handler yapılandırmasını yeniden oluşturun.
plesk repair web example.com -yEn sık neden NGINX’in PHP-FPM veya reverse proxy backend’ine bağlanamamasıdır. Yanlış socket/port, durmuş servis, izin sorunu ve uygulamanın bağlantıyı erken kapatması başlıca nedenlerdir.
Yalnız NGINX process sorunu varsa çözebilir. Backend kapalı veya fastcgi_pass yanlışsa yeniden başlatma geçici ya da etkisiz olur.
502 genellikle bağlantı kurulamadığını veya geçersiz backend yanıtını; 504 ise bağlantı kurulmasına rağmen zamanında yanıt alınamadığını gösterir.
PHP-FPM pool dosyalarındaki listen değerini ve ss -lxnp çıktısını kontrol edin. Bu değer NGINX fastcgi_pass satırıyla eşleşmelidir.
Hedef IP/port üzerinde bağlantıyı kabul eden servis olmadığını veya aktif reddedildiğini gösterir. Servis, port ve bind adresi kontrol edilmelidir.
Önce domain loglarını ve handler ayarını kontrol edin; ardından gerekirse plesk repair web alanadi -y ile yalnız ilgili domainin web yapılandırmasını yeniden oluşturun.
Her zaman değil. Origin IP’ye --resolve ile doğrudan istek göndererek Cloudflare ile origin NGINX katmanlarını ayırabilirsiniz.
cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim ve güvenlik katmanlarını birlikte analiz ederek yalnızca servisi kaldırmak yerine arızanın temel nedenini gideriyoruz.