Türkei (Türkisch)
Germany (German)
Worldwide (English)
Proxy-SchichtNginx- und Apache-Verbindung
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
502 und 504 Fehler auf einem Plesk-Server bedeuten, dass die Anfrage Nginx oder Apache erreicht hat, aber PHP-FPM, FastCGI oder das Backend-Service nicht innerhalb einer angemessenen Zeit mit einer gesunden Antwort reagiert hat.
502 Bad Gateway
connect() to unix:/var/www/vhosts/system/example.com/php-fpm.sock failed
(11: Resource temporarily unavailable) while connecting to upstream
upstream timed out (110: Connection timed out)502 Bad Gateway zeigt an, dass die Proxy-Ebene keine gültige Antwort vom Backend erhalten konnte; 504 Gateway Timeout zeigt an, dass das Backend innerhalb der angegebenen Zeit nicht geantwortet hat. Beide Fehler scheinen ähnlich, aber die Lösung sollte auf den Log-Nachrichten von Socket, Timeout und Prozess basieren.
Wenn nur ein Domain betroffen ist, werden die PHP-Handler-Auswahl der betroffenen Domain, der PHP-FPM-Pool, der Anwendungscode und die Aufzeichnungen im Verzeichnis /var/www/vhosts/system/domain/logs untersucht.
Wenn alle Sites betroffen sind, werden Nginx, Apache, installierte Plesk PHP-FPM-Dienste, globale RAM, Datei-Identifikatoren und die letzten Update-Betriebe überprüft.
php-fpm.sock fehlgeschlagen: Datei oder Verzeichnis nicht gefunden, was möglicherweise darauf hinweist, dass die erwartete Socket-Datei für die Domain nicht erstellt wurde oder die Domain an einen entfernten PHP-Handler gebunden ist.
Auch wenn der Dienst wie funktionierend erscheint, wenn die Ressourcenbegrenzung oder der starke Traffic den Pool voll macht, können neue Anfragen nicht an den Back-End weitergeleitet werden. Daher ist ein Neustart allein keine dauerhafte Lösung.
Die Erhöhung der Timeout-Wert ist für Aufgaben, die tatsächlich lange dauern, nützlich. Sie sollte nicht nur verwendet werden, um die Wartezeit für eine langsame Abfrage, einen Bot-Angriff oder einen gesperrten PHP-Prozess für eine normale Seite zu verbergen.
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 oder Apache konnte keine gültige HTTP-Antwort vom Backend abrufen.
Mögliche Ursache: PHP-FPM ist geschlossen, Socket verloren, Verbindung abgelehnt oder der Prozess wurde abrupt beendet.
Bedeutung: Proxy, konnte innerhalb der angegebenen Zeit keine Antwort vom Backend erhalten.
Mögliche Ursache: Langlaufender PHP-Prozess, langsamer SQL-Abfrage, externe API-Wartezeit oder niedriger Proxy-Timeout.
Bedeutung: Der PHP-FPM-Socket-Pfad kann im Dateisystem nicht gefunden werden.
Mögliche Ursache: PHP-Handler entfernt, fehlende Pool-Datei oder Web-Konfiguration ist veraltet.
Bedeutung: Der Socket oder der Port ist verfügbar, aber die Backend-Verbindung wurde nicht akzeptiert.
Mögliche Ursache: Der PHP-FPM-Dienst ist möglicherweise gestoppt, die Pool ist abgestürzt oder ein falscher Endpunkt wird verwendet.
Bedeutung: Neue Verbindung oder Prozess kann vorübergehend nicht getrennt werden.
Mögliche Ursache: PHP-FPM-Pool voll, Prozesslimit hoch unter hohem Last oder DDoS-Verkehr
Bedeutung: Die gleichzeitige Anzahl der Kindprozesse in der PHP-FPM-Pool ist erreicht.
Mögliche Ursache: Hoher Traffic, langsamer Anfrage oder niedrige Pool-Kapazität.
Bedeutung: Back-end-Verbindung hergestellt, aber Antwort-Header nicht rechtzeitig empfangen.
Mögliche Ursache: Die Anwendung, Datenbank oder externe Dienstleistung erleidet eine Verzögerung.
Bedeutung: Die Domain ist an einen nicht existierenden oder defekten PHP-Handler gebunden.
Mögliche Ursache: PHP-Version wurde entfernt, aber die Domain-Konfiguration bleibt unverändert
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.
curl -skI https://example.com/
curl -skI https://example.com/test.htmlEs unterscheidet, ob das Problem ein Proxy oder eine Anwendung ist, indem es statische und PHP-Antworten vergleicht.
tail -n 150 /var/www/vhosts/system/example.com/logs/proxy_error_log
tail -n 150 /var/www/vhosts/system/example.com/logs/error_logZeigt Nginx, Apache und PHP-Hintergrundnachrichten auf Domain-Basis an.
systemctl status nginx --no-pager
systemctl status apache2 --no-pager 2>/dev/null || systemctl status httpd --no-pagerÜberprüft den Status von Nginx und Apache Diensten basierend auf der Distribution.
systemctl list-units --type=service 'plesk-php*-fpm.service' --no-pager
ps -eo pid,user,%cpu,%mem,etime,cmd --sort=-%cpu | grep 'php-fpm' | head -n 30Listet die installierten PHP-FPM-Dienste und intensive Prozesse auf.
plesk repair web example.comEs überwacht die Web-Konfiguration der zugehörigen Domäne und bietet interaktive Reparaturvorschläge.
free -h
journalctl -k --since '1 hour ago' | grep -Ei 'oom|out of memory|killed process'Zeigt globalen Speicherdruck oder Kernel-OOM-Ereignis an.
tail -n 10000 /var/www/vhosts/system/example.com/logs/proxy_access_log | awk '{print $1}' | sort | uniq -c | sort -nr | headZeigt an, ob eine einzelne IP oder eine Bot-Gruppe den Pool verbraucht.
Der Umfangstest, die Log-Matching, die Dienst- und Handler-Verifizierung, die Anwendungsdurchführung und die endgültige Überprüfung sollten in dieser Reihenfolge durchgeführt werden.
Testen Sie verschiedene Domains auf dem gleichen Server und statische Dateien, um einzelne Sites, einzelne PHP-Versionen oder globale Dienstausfälle zu isolieren.
curl -skI https://example.com/Im Browser sind die Ergebnisse 502/504 einzigartig. Die gleiche Zeile in proxy_error_log und error_log nähert sich der Ursache, die sich im selben Sekunden ereignet.
tail -n 150 /var/www/vhosts/system/example.com/logs/proxy_error_logÜberprüfen Sie im Plesk-Panel, ob die Domain einen bestehenden FPM-Handler verwendet. Wenn ein verlorenes Socket existiert, wählen Sie den Handler erneut aus und wenden Sie ihn an.
Wenn der PHP-FPM-Pool voll ist, sollte die RAM-Nutzung, der durchschnittliche Prozessgröße und die lang laufenden Anfragen gemessen werden.
ps -eo pid,user,%cpu,%mem,etime,cmd --sort=-%mem | grep php-fpm | headStatt den gesamten Server für ein einzelnes Domänenproblem auszutauschen, überprüfen Sie die Web-Konfiguration des zugehörigen Domänennamens mit Plesk-Reparatur.
plesk repair web example.comÜberwachen Sie den HTTP-Code, den Dienststatus, neue Log-Einträge und Ressourcenverbrauch für mindestens 15 Minuten.
curl -skI https://example.com/ && systemctl is-active nginxDer PHP-Handler, die Socket-Datei, proxy_error_log und Anwendungserweiterungen der Domain werden untersucht. Ein globaler Nginx-Neustart ist nicht die erste Option.
plesk repair web example.comNginx, Apache, PHP-FPM-Dienste, RAM und die neuesten Paketupdates werden global überprüft.
systemctl --failed --no-pagerBei Nginx kann ein Proxy-Timeout oder ein PHP max_execution_time Limit vorliegen. Zuerst muss ermittelt werden, warum der Prozess so lange dauert.
time curl -sk https://example.com/ -o /dev/nullPool-Kapazität, IP-Adressen, die die meisten Anfragen senden, WAF und Rate-Limit-Anforderungen werden untersucht.
PHP-Prozesse können den Pool durch das Warten auf die SQL-Antwort auffüllen. Im MariaDB-Prozessliste und IO-Verzögerung werden überprüft.
mysqladmin processlist
iostat -xz 1 3502 zeigt an, dass keine gültige Antwort vom Backend erhalten wurde, während 504 anzeigt, dass die Antwort die Zeitgrenze überschritten hat. Obwohl beide Fehler den gleichen Ursprung haben können, zeigt die Log-Nachricht eine andere Lösungsebene an.
Die blockierte Verbindung kann vorübergehend gelöscht werden. Wenn der verlorene PHP-Socket, der vollbesetzte Pool oder die langsame Anwendung weitergeht, wiederholt sich der Fehler.
Der ausgewählte PHP-Handler für die Domain sollte überprüft und über die Web-Konfiguration Plesk auf eine vorhandene FPM-Version neu erstellt werden.
Es gibt keine feste Zahl. Sie sollte durch die Berechnung der verfügbaren RAM, der durchschnittlichen Verbrauch eines PHP-Prozesses und den Anteil anderer Dienste bestimmt werden.
In Report-erstellungsprozessen, der Prüfunglwert kann erhöht werden. Verwenden Sie ihn nicht, um langsamen Codes oder SQL-Anfragen auf einer normalen Seite zu verstecken.
Der Domain-Log, PHP-FPM-Pool, Erweiterungen, wp-cron, externe API-Aufrufe und Datenbankabfragen sollten überprüft werden.
Es überprüft und erzeugt neu Web-Aspect-Konfigurationsdateien; jedoch sollte vor jeder Reparatur des Produktionservers ein aktuelles Backup und eine Ausgabekommando erhalten 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.