Türkei (Türkisch)
Germany (German)
Worldwide (English)
Gateway-Fehler502, 504, PHP-FPM und Upstream-Probleme
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
NGINX-Fehlerfenster verbergen in der Regel die tatsächliche Ursache; eine genaue Diagnose erfordert die gemeinsame Untersuchung von Zugriffs-/Fehlerprotokollen, aktiven Konfigurationen, upstream-Diensten, Dateizugriff und Systemressourcen.
nginx -t
systemctl status nginx --no-pager
tail -n 100 /var/log/nginx/error.log
curl -skI https://example.com/Der HTTP-Code im Browser zeigt nur die Klasse des Problems an. Die Ursache wird durch die Identifizierung der gleichzeitigen error_log-Zeile und des Server/Location/Upstream-Pfads, den die Anfrage in NGINX durchläuft, ermittelt.
502- und 504-Gateway-Fehler scheinen ähnlich, aber 502 zeigt in der Regel an, dass eine Verbindung zum Backend nicht hergestellt werden konnte oder eine ungültige Antwort erhalten wurde; 504 zeigt an, dass das Backend innerhalb der angegebenen Zeit nicht geantwortet hat.
Bei 403- und 404-Problemen sollten zuerst die korrekte virtuelle Host-/Dokumentenwurzel-Übereinstimmung, dann Dateiberechtigungen, try_files und Zugriffsregeln überprüft werden.
413 und große Header/Cookie-Fehler können von NGINX abgelehnt werden, bevor die Anfrage das Backend erreicht. PHP oder kein Eintrag im Anwendungsprotokoll ist normal aus diesem Grund.
Standard sichere Backup, nginx -t, kontrollierter Reload, HTTP-Test und neuer error_log-Check bei Konfigurationsänderungen. Neustart mit einer ungültigen Konfiguration erhöht das Risiko einer Unterbrechung.
Anstatt einen Befehl aufgrund des Fehlercodes aus dem Kopf auszuführen, sollten Sie die Browserzeit, die Anfrage-URL, die Fehlerprotokollnachricht und den Zielserver in einem einzigen Ereignis aufzeichnen.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: NGINX 502 Bad Gateway Fehlerlösung mit PHP-FPM-Socket, proxy_pass, upstream, Verbindung abgelehnt, Berechtigung verweigert und Backend-Dienstüberprüfungen
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: Lösen Sie NGINX 504 Gateway Timeout und Upstream timed out-Fehler mit proxy_read_timeout, fastcgi_read_timeout, PHP-FPM, Datenbank und Slow-Backend-Analyse.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: NGINX 403 Forbidden Fehler mit Dateiberechtigungen, Eigentumsrechten, Indexdateien, Deny-Regeln, SELinux, Symbolverknüpfen und Plesk-Prüfunglen lösen.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: NGINX 413 Request Entity Too Large-Fehler gelöst mit client_max_body_size, PHP-Upload-Limit, WordPress, Laravel, Docker und Proxy-Einstellungen.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: NGINX 404 Not Found Probleme mit try_files, root, alias, server_name, WordPress, Laravel und SPA Routingkonfigurationen lösen.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: NGINX 400 Request Header oder Cookie Too Large Fehlerlösung mit cookie, JWT, large_client_header_buffers, Proxy-Header und Anwendungssitzungssteuerungen.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: NGINX ERR_TOO_MANY_REDIRECTS und rewrite- oder interne Umleitungsschleife-Fehler-Lösung mit HTTPS, www, Cloudflare, Proxy und Location-Steuerungen
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: NGINX startet nicht oder zeigt eine Konfigurationsprüfung fehlgeschlagen-Fehlermeldung an, wie Syntax, unbekannte Direktive, Adresse bereits in Verwendung, SSL und Include-Probleme.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: Lösen Sie NGINX-SSL-Handshake-, Zertifikatskette-, privater-Schlüssel-ungleichheit-, falsches-Zertifikat- und Certbot-Auflösungsfehler mit OpenSSL-Überprüfungen.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Bedeutung: NGINX worker_connections sind nicht ausreichend und zu viele offene Dateien-Fehler wird mit worker_processes, ulimit, LimitNOFILE, keepalive und Traffic-Analyse gelöst.
Mögliche Ursache: NGINX, unterschiedliche Ursachen wie Dateisystem, Netzwerk oder Sicherheitslayer-Probleme können denselben Benutzerzeichen erstellen.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
nginx -tÜberprüft die Zugänglichkeit der Syntax und der angewendeten Dateien.
nginx -T > /tmp/nginx-tam.conf 2>&1Zeigt alle Include-Dateien in einer kombinierten Ausgabeformat an.
tail -n 150 /var/log/nginx/error.logGateway, Berechtigung, Rewrite und SSL-Rootursachen werden angezeigt.
systemctl status nginx -l --no-pager
journalctl -u nginx -n 100 --no-pagerZeigt Start-, Neulad- und systemd-Probleme an.
ss -lntp
ss -lxnp | grep -E 'nginx|php|fpm'NGINX und Backend-Hörpunkte werden überprüft.
curl -skI https://example.com/Zeigt den echten Statuscode, Server und Location-Header an.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
NGINX-Fehlercodes für systemd, Paketpfad und journald-Prüfunglen.
nginx -t
systemctl status nginx --no-pager
tail -n 100 /var/log/nginx/error.logSELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen für NGINX-Fehlerrichtlinien.
nginx -t
systemctl status nginx --no-pager
tail -n 100 /var/log/nginx/error.log
getenforceNGINX virtuelle Host-Dateien von Plesk generiert: Überprüfung von nginx-Fehlern.
nginx -t
plesk repair web -n
tail -n 100 /var/log/nginx/error.logBevor Sie die Dienste für jeden Fehler zufällig neu starten, bestimmen Sie den Umfang, den Protokoll, die aktive Konfiguration und den Backend-Zustand.
Einschränken Sie ein einzelnes Domain, eine einzelne Route oder den gesamten Servereffekt.
date; curl -skI https://example.com/Verwenden Sie die reale Fehlerzeile von NGINX anstelle des Browser-Textes.
tail -n 150 /var/log/nginx/error.logÄnderungen an falschen oder nicht eingeschlossenen Dateien verhindern.
nginx -T > /tmp/nginx-tam.conf 2>&1Socket/Port, Berechtigung, SSL oder Ressourcenlimit gemäß der Fehlerklasse messen.
ss -lntp; df -h; df -iVor der Änderung die relevante Konfigurationsdatei sichern.
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/Zuerst die NGINX Start/Config- und 502 Upstream-Anleitungen beurteilen.
systemctl is-active nginx; nginx -tGehen Sie zu Backend-Dauer, PHP-FPM, DB und Timeout-Leitfaden.
curl -sk -o /dev/null -w '%{time_total}\n' https://example.com/403, Berechtigung, SELinux und allow/deny-Leitfaden.
tail -n 50 /var/log/nginx/error.logÜberprüfen Sie die 413-Body-Grenze, die PHP-Grenze und den verfügbaren Festplattenspeicher.
nginx -T | grep client_max_body_sizeBeziehen Sie sich auf die Leitfäden für server_name, try_files, rewrite und proxy-Schemata.
curl -skIL --max-redirs 10 https://example.com/Überprüfen Sie Worker-Verbindungen, fd-Grenzwerte und Backend-Kapazität.
ss -s; systemctl show nginx -p LimitNOFILEKonfigurations- oder Dienstprobleme vermutet, führen Sie nginx -t und systemctl status nginx aus; bei einem laufenden Site-Fehler sollte ein gleichzeitiger error_log-Check durchgeführt werden.
502 zeigt an, dass eine Verbindung zum Backend nicht hergestellt werden konnte oder eine ungültige Antwort erhalten wurde; 504 zeigt an, dass das Backend erreicht wurde, aber innerhalb der angegebenen Zeit keine Antwort erhalten wurde.
In der Regel reicht nginx -t gefolgt von reload aus und ist sicherer. Ein Neustart sollte nur dann durchgeführt werden, wenn dies durch eine spezielle Servicelage erforderlich ist.
Der gängige Pfad ist /var/log/nginx/error.log; eine Domain oder eine Konfiguration kann einen benutzerdefinierten Log-Pfad verwenden.
Schreibt die effektive Konfiguration mit allen Include-Dateien in stdout; ermöglicht das Finden der tatsächlich angewendeten Server/Location-Zeilen.
Domain-Logs, Additional nginx directives, generierte vhost-Dateien und plesk repair web dry-run sollten zusammen verwendet werden.
Konfigurationstest, Servicestatus, echter HTTP-Anfrage, direkter Backend-Test und neue Log-Datensätze sollten gemeinsam überprüft werden
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.