Ein 502 ist Nginx' Mitteilung, dass es etwas anderes um die Seite gebeten und eine unbrauchbare Antwort bekommen hat. Nginx selbst läuft — liefe es nicht, sähen Sie gar nichts — der Fehler steckt also dahinter, fast immer in PHP.

Erkennen, welcher der vier es ist

Lesen Sie zuerst das Fehlerprotokoll. Es nennt die Ursache in einer Zeile, und jede Minute des Ratens ist eine Minute, in der Sie es nicht gelesen haben.

tail -50 /var/log/nginx/error.log
  • connect() failed (111: Connection refused) — PHP-FPM läuft nicht.
  • upstream timed out — PHP läuft, brauchte aber länger als die Zeitgrenze.
  • recv() failed (104: Connection reset by peer) — der PHP-Worker starb mitten in der Anfrage, meist wegen Speichermangels.
  • no live upstreams — im Pool ist kein Worker mehr übrig, der antworten könnte.

PHP-FPM läuft nicht

  1. Nachsehen — systemctl status php8.3-fpm — ein gestoppter Dienst sagt es in der ersten Zeile.
  2. Starten — systemctl start php8.3-fpm
  3. Herausfinden, warum er stehen blieb — journalctl -u php8.3-fpm --since "1 hour ago" — eine fehlerhafte Zeile in einer Pool-Konfiguration stoppt ihn schon beim Start, und er wird wieder stehen bleiben.
Startet er und bleibt sofort wieder stehen, führen Sie php-fpm8.3 -t aus. Es prüft die Pool-Dateien und nennt die Zeile, die ihm nicht gefällt.

PHP ist zu langsam für die Zeitgrenze

Voreingestellt bekommt PHP 60 Sekunden. Ein langsamer Import oder eine externe API, die nicht mehr antwortet, überschreitet das, und Nginx liefert 502, statt ewig zu warten.

location ~ \.php$ {
    fastcgi_read_timeout 300;
}
Die Zeitgrenze anzuheben verdeckt nur das Symptom. Eine Seite, die fünf Minuten braucht, braucht eine Warteschlange, kein längeres Warten — und der Besucher ist längst weg.

Der Worker ist gestorben

Eine Anfrage, die memory_limit überschreitet, tötet ihren Worker, und Nginx sieht die zurückgesetzte Verbindung. Das PHP-Fehlerprotokoll nennt Datei und Zeile.

grep -i "allowed memory size" /var/log/php8.3-fpm.log | tail

Der Pool hat keine Worker mehr

Jeder Worker ist beschäftigt, eine neue Anfrage hat also keinen Platz. Das ist ein Kapazitätsproblem, und die ehrliche Abhilfe heißt entweder weniger langsame Anfragen oder mehr Worker — aber mehr Worker auf demselben RAM verschieben den Ausfall nur.

pm.max_children = 20
pm.max_requests = 500
Beim EGPHP-Hosting wird der Pool für Sie verwaltet und dieser Fall abgefangen, bevor Sie ihn sehen. Auf einem VPS liegt die Dimensionierung bei Ihnen, und die Zahl, auf die es ankommt, ist Ihr RAM geteilt durch die durchschnittliche Workergröße.