Türkiye (Türkçe)
Almanya (German)
Worldwide (English)
Gateway hataları502, 504, PHP-FPM ve upstream sorunları
Halkalı merkez mahallesi fatih cd ozgur apt no 46 , Küçükçekmece , İstanbul , 34303 , TR
NGINX hata ekranları çoğunlukla kök nedeni gizler; gerçek teşhis access/error logu, etkin yapılandırma, upstream servis, dosya erişimi ve sistem kaynaklarının birlikte incelenmesini gerektirir. Bu merkez 10 yaygın NGINX sorununu gerçek log mesajına göre doğru rehbere yönlendirir.
nginx -t
systemctl status nginx --no-pager
tail -n 100 /var/log/nginx/error.log
curl -skI https://example.com/Tarayıcıdaki HTTP kodu yalnız sorunun sınıfını gösterir. Kök neden, aynı zamanlı error_log satırı ve isteğin NGINX içinde hangi server/location/upstream yolundan geçtiği belirlenerek bulunur.
502 ve 504 gateway hataları benzer görünse de 502 çoğunlukla backend’e bağlanamama veya geçersiz yanıtı; 504 ise backend’in zamanında cevap vermemesini gösterir.
403 ve 404 sorunlarında önce doğru sanal host/document root eşleşmesi, ardından dosya izinleri, try_files ve erişim kuralları incelenmelidir.
413 ve büyük header/cookie hataları isteğin backend’e ulaşmadan NGINX limitinde reddedilebildiğini gösterir. PHP veya uygulama logunda kayıt bulunmaması bu nedenle normal olabilir.
Yapılandırma değişikliğinde standart güvenli sıra yedek alma, nginx -t, kontrollü reload, HTTP testi ve yeni error_log kontrolüdür. Geçersiz config varken restart kesinti riskini artırır.
Hata koduna göre ezbere komut çalıştırmak yerine tarayıcı saati, request URL, error_log mesajı ve upstream hedefini tek olay kaydı olarak eşleştirin.
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ı: NGINX 502 Bad Gateway hatasını PHP-FPM socket, proxy_pass, upstream, connection refused, permission denied ve backend servis kontrolleriyle çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX 504 Gateway Timeout ve upstream timed out hatasını proxy_read_timeout, fastcgi_read_timeout, PHP-FPM, veritabanı ve yavaş backend analiziyle çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX 403 Forbidden hatasını dosya izinleri, sahiplik, index dosyası, deny kuralları, SELinux, symlink ve Plesk kontrolleriyle çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX 413 Request Entity Too Large hatasını client_max_body_size, PHP upload limiti, WordPress, Laravel, Docker ve proxy ayarlarıyla çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX 404 Not Found sorununu try_files, root, alias, server_name, WordPress, Laravel ve SPA yönlendirme ayarlarıyla çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX 400 Request Header or Cookie Too Large hatasını cookie, JWT, large_client_header_buffers, proxy header ve uygulama oturumu kontrolleriyle çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX ERR_TOO_MANY_REDIRECTS ve rewrite or internal redirection cycle hatasını HTTPS, www, Cloudflare, proxy ve location kontrolleriyle çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX başlamıyor veya configuration test failed hatası veriyorsa syntax, unknown directive, address already in use, SSL ve include sorunlarını çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX SSL handshake, certificate chain, private key mismatch, wrong certificate ve Certbot yenileme hatalarını OpenSSL kontrolleriyle çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
Anlamı: NGINX worker_connections are not enough ve too many open files hatasını worker_processes, ulimit, LimitNOFILE, keepalive ve trafik analiziyle çözün.
Muhtemel neden: NGINX, backend, dosya sistemi, ağ veya güvenlik katmanındaki farklı kök nedenler aynı kullanıcı belirtisini oluşturabilir.
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 -tSözdizimi ve başvurulan dosyaların açılabilirliğini doğrular.
nginx -T > /tmp/nginx-tam.conf 2>&1Tüm include dosyalarını birleşik çıktı halinde gösterir.
tail -n 150 /var/log/nginx/error.logGateway, izin, rewrite ve SSL kök nedenlerini gösterir.
systemctl status nginx -l --no-pager
journalctl -u nginx -n 100 --no-pagerBaşlangıç, reload ve systemd sorunlarını gösterir.
ss -lntp
ss -lxnp | grep -E 'nginx|php|fpm'NGINX ve backend dinleme noktalarını doğrular.
curl -skI https://example.com/Gerçek durum kodu, Server ve Location başlıklarını gösterir.
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 hata kodları için systemd, paket yolu ve journald kontrolleri.
nginx -t
systemctl status nginx --no-pager
tail -n 100 /var/log/nginx/error.logNGINX hata kodları için SELinux, PHP-FPM pool ve RHEL tabanlı servis kontrolleri.
nginx -t
systemctl status nginx --no-pager
tail -n 100 /var/log/nginx/error.log
getenforcePlesk tarafından üretilen NGINX sanal host dosyalarında nginx hata kodları kontrolü.
nginx -t
plesk repair web -n
tail -n 100 /var/log/nginx/error.logHer hata için servisleri rastgele yeniden başlatmadan önce kapsam, log, etkin config ve backend durumunu belirleyin.
Tek domain, tek route veya tüm sunucu etkisini ayırın.
date; curl -skI https://example.com/Tarayıcı metni yerine NGINX’in gerçek hata cümlesini esas alın.
tail -n 150 /var/log/nginx/error.logYanlış veya include edilmeyen dosyada değişiklik yapmayı önleyin.
nginx -T > /tmp/nginx-tam.conf 2>&1Hata sınıfına göre socket/port, izin, SSL veya kaynak limitini ölçün.
ss -lntp; df -h; df -iDeğişiklikten önce ilgili config dosyasını yedekleyin.
cp -a /etc/nginx/nginx.conf /root/nginx.conf.yedeknginx -t başarısızsa reload/restart uygulamayın.
nginx -t && systemctl reload nginx
curl -skI https://example.com/Önce NGINX başlangıç/config ve 502 upstream rehberlerini değerlendirin.
systemctl is-active nginx; nginx -tBackend süre, PHP-FPM, DB ve timeout rehberine geçin.
curl -sk -o /dev/null -w '%{time_total}\n' https://example.com/403, izin, SELinux ve allow/deny rehberini kullanın.
tail -n 50 /var/log/nginx/error.log413 body limiti, PHP limiti ve disk alanını inceleyin.
nginx -T | grep client_max_body_sizeserver_name, try_files, rewrite ve proxy şema rehberlerine geçin.
curl -skIL --max-redirs 10 https://example.com/Worker connections, fd limitleri ve backend kapasitesini ölçün.
ss -s; systemctl show nginx -p LimitNOFILEYapılandırma veya servis sorunu şüphesinde nginx -t ve systemctl status nginx; çalışan site hatasında aynı zamanlı error_log kontrolü yapılmalıdır.
502 backend’e bağlanamama veya geçersiz yanıtı; 504 ise backend’e ulaşılsa da zamanında yanıt alınamamasını gösterir.
Genellikle nginx -t sonrası reload yeterlidir ve daha güvenlidir. Restart yalnız özel servis durumu gerektiğinde uygulanmalıdır.
Yaygın yol /var/log/nginx/error.log’dur; domain veya panel yapılandırması farklı özel log yolu kullanabilir.
Tüm include dosyalarıyla birlikte etkin yapılandırmayı stdout’a yazar; gerçek uygulanan server/location satırlarını bulmayı sağlar.
Domain Logs, Additional nginx directives, üretilen vhost dosyaları ve plesk repair web dry-run birlikte kullanılmalıdır.
Config testi, servis durumu, gerçek HTTP isteği, backend doğrudan testi ve yeni log kayıtları birlikte kontrol edilmelidir.
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.