Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
502 Bad Gateway bedeutet, dass NGINX die Clientanfrage erhalten hat, aber keine gültige Antwort vom Upstream-Server, wie z. B. PHP-FPM, Node.js, Python, Docker oder einem anderen, erhalten konnte. Diese Anleitung trennt die Dienste, Ports, Unix-Sockets, proxy_pass, Berechtigungen und Sicherheitsebenen in der richtigen Reihenfolge.
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 erzeugt bei einer Verbindung zum Backend-App-Service in der Vorderseite oder bei einem ungültigen oder unvollständigen Antwort des Backends einen 502. Daher ist die Wiederherstellung von NGINX in der Regel keine dauerhafte Lösung.
Die erste Unterscheidung, ob der Fehler in einer einzelnen Domain oder in allen hinter NGINX liegenden Anwendungen erscheint. Eine einzelne Domain bezieht sich in der Regel auf einen vhost, Socket oder Anwendungsdienst; alle Domains deuten auf einen gemeinsamen PHP-FPM, NGINX, Netzwerk- oder Ressourcenproblem hin.
Bei PHP-FPM-Konfigurationen, die Unix-Sockets verwenden, muss der Pfad, der Besitzer und die Berechtigungen des Socket-Files der Zeile fastcgi_pass genau entsprechen. Es ist ein häufiges Problem, wenn der alte Socket-Pfad im Vhost-File bleibt, wenn sich die PHP-Version ändert.
Wenn TCP upstream verwendet wird, sollte die Ziel-IP und -Port tatsächlich abgelauscht werden. Der Port kann nach dem Neustart des Containers, Node.js- oder Python-Dienstes geändert worden sein, oder der Dienst kann anstatt an localhost an einer anderen Schnittstelle verbunden sein oder der Firewall kann die Verbindung blockieren.
Die 502 auf dem Cloudflare-Bildschirm ist nicht dieselbe wie die 502, die von der Ursprungs-NGINX erzeugt wird. Zuerst sollten die Ursprungs-IP und der localhost-Backend direkt getestet werden, um zu bestimmen, in welcher Schicht der Fehler begonnen hat.
Bevor die Timeout-Werte in 502 erhöht werden, muss bewiesen werden, dass das Backend aktiv ist, auf dem richtigen Port und zugänglich für den NGINX-Worker-Benutzer ist.
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: Ziel-IP und Port-Verbindung wird nicht akzeptiert.
Mögliche Ursache: Backend ist geschlossen, falscher Port oder Dienst hört auf einer anderen Schnittstelle.
Bedeutung: NGINX verwendet einen nicht verfügbaren Socket-Pfad.
Mögliche Ursache: Die PHP-FPM-Version, der Poolname oder der Socket-Pfad wurde geändert.
Bedeutung: Socket existiert, aber der NGINX-Worker kann darauf keinen Zugriff haben.
Mögliche Ursache: Der Besitzer, Gruppe, Modus oder der SELinux-Kontext des Sockets ist nicht übereinstimmend.
Bedeutung: Keine verfügbaren Backends mehr in der Upstream-Gruppe.
Mögliche Ursache: Alle Server sind als fehlgeschlagen markiert oder haben ein DNS/Gesundheitsproblem.
Bedeutung: Der Backend-Dienst schloss die Verbindung vor Abschluss der Antwort.
Mögliche Ursache: Anwendungskrash, Prozessbeendigung, Speicherleck oder Protokollinkompatibilität.
Bedeutung: Die Gegenpartei hat die Verbindung zwingend zurückgesetzt.
Mögliche Ursache: Backend-Neustart, Anwendungsfehler oder Netzwerksicherheitsschicht.
Bedeutung: Backend hat keinen HTTP/FastCGI-Protokoll-konformen Header produziert.
Mögliche Ursache: Falscher Proxy-Protokoll, fehlerhaftes Anwendungsoutput oder FastCGI-Port-HTTP-Übertragung.
Bedeutung: Der allgemeine Fehler im Browser verbirgt die Ursache.
Mögliche Ursache: Überprüfen Sie den Status des Dienstes, Sockets, Ports, Berechtigungen oder Anwendungsstapel.
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
nginx -T | grep -nE 'server_name|proxy_pass|fastcgi_pass'Die Syntax wird getestet und aktive upstream-Ziele werden angezeigt.
systemctl status nginx php8.3-fpm --no-pager
ss -lntp
ss -lxnp | grep -E 'php|fpm'NGINX, PHP-FPM, TCP-Ports und Unix-Sockets werden überprüft.
tail -n 150 /var/log/nginx/error.log
journalctl -u nginx -u php8.3-fpm -n 150 --no-pagerNGINX und Backend-Dienstfehler werden im gleichen Zeitrahmen verglichen.
curl -sv http://127.0.0.1:3000/ -o /dev/null
curl -skI https://example.com/Reverse proxy hinter ihm testet das Service unabhängig von NGINX.
namei -l /run/php/php8.3-fpm.sock
stat /run/php/php8.3-fpm.sock
ps -eo user,group,cmd | grep '[n]ginx: worker'Zeigt den Zugriff auf alle Ordner im Socket-Pfad und den Worker-Benutzer an.
nginx -t && systemctl reload nginx
systemctl restart php8.3-fpmNGINX lädt kontinuierlich; nur der Backend wird bei Bedarf neu gestartet.
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 502 Bad Gateway für systemd, Paketpfad und journald-Prüfunglen.
systemctl status nginx php8.3-fpm --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.logNGINX 502 Bad Gateway für SELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen.
systemctl status nginx php-fpm --no-pager
nginx -t
tail -n 100 /var/log/nginx/error.logNGINX-Virtualhost-Dateien, die von Plesk generiert werden: nginx 502 bad gateway-Prüfungle.
plesk repair web example.com -y
systemctl status nginx sw-engine --no-pager
nginx -tAnstatt den Service zufällig neu zu starten, gehen Sie vor, indem Sie beweisen, dass der Fehler auf der NGINX-, Socket-, Backend- oder Sicherheitsstufe aufgetreten ist.
Bestimmen Sie, ob eine einzelne Domain, eine einzelne PHP-Version oder alle upstream-Anwendungen betroffen sind.
for u in https://example.com https://diger.example.com; do curl -sk -o /dev/null -w "$u %{http_code}\n" "$u"; doneKlassifizieren Sie die Ursache der Wurzel auf der Grundlage der upstream-Fehlinformation, nicht der Browser-Meldung.
tail -f /var/log/nginx/error.logBestätigen Sie, dass der Socket oder der TCP-Port tatsächlich geöffnet ist.
ss -lntp; ss -lxnp | grep -E 'php|fpm'Überprüfen Sie den Wert von fastcgi_pass oder proxy_pass mit der tatsächlichen Server-IP-Adresse.
nginx -T | grep -nE 'fastcgi_pass|proxy_pass'Überprüfen Sie SELinux- und Firewall-Blockierungen für den Socket-Zugriff.
namei -l /run/php/php8.3-fpm.sock; getenforce 2>/dev/nullWenn die Syntax erfolgreich ist, reloaden und beide Origin und Backend erneut messen.
nginx -t && systemctl reload nginx
curl -skI https://example.com/Alte PHP-FPM-Socket-Pfad kann in der vhost-Datei übrig bleiben.
grep -R 'fastcgi_pass' /etc/nginx /etc/plesk 2>/dev/nullContainer-Port, Netzwerkname oder Gesundheitsstatus können geändert worden sein
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'Der PM2/systemd-Prozess ist gestoppt oder die Anwendung ist an einen anderen Port gebunden.
systemctl status Anwendung --no-pager; ss -lntpÜberprüfen Sie den Socket-Gruppen/Modus- oder SELinux-Kontext-Missmatch.
stat /run/php/php8.3-fpm.sock; ausearch -m AVC -ts recent | tailUnterscheiden Sie den Cloudflare-Schicht mit direktem Zugriff auf Origin.
curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/Erstellen Sie die generierte NGINX/PHP-Handler-Konfiguration für die Domain neu.
plesk repair web example.com -yDie häufigste Ursache für das Nichtverbinden zum NGINX-Backend ist ein falscher Socket/Port, ein gestopptes Dienst, eine Berechtigungsproblematik oder das frühe Beenden der Verbindung durch die Anwendung.
Wenn es einen NGINX-Prozessproblem gibt, löst dies möglicherweise nur vorübergehend oder ineffektiv, wenn der Backend geschlossen ist oder fastcgi_pass falsch eingerichtet ist.
502 zeigt in der Regel an, dass eine Verbindung nicht hergestellt werden konnte oder eine ungültige Backend-Antwort erhalten wurde; 504 zeigt an, dass eine Verbindung hergestellt wurde, aber innerhalb der angegebenen Zeit keine Antwort erhalten wurde.
Überprüfen Sie den listen-Wert in den PHP-FPM-Pooldateien und die Ausgabe von ss -lxnp. Dieser Wert sollte der NGINX fastcgi_pass-Zeile entsprechen.
Zeigt an, dass die Ziel-IP/Port die Verbindung nicht akzeptiert oder aktiv blockiert. Die Dienst, Port und Bind-Adresse sollten überprüft werden.
Überprüfen Sie zunächst die Domain-Logs und Handler-Einstellungen; dann, falls erforderlich, den Webkonfiguration für die betreffende Domain nur mit plesk repair web domainname -y neu erstellen.
Nicht immer. Sie können auch direkt Anfragen an die Ursprung-IP senden und die Cloudflare- und Ursprung-NGINX-Schichten trennen
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.