HTTP 502 Bad Gateway (nginx, PHP-FPM): Lösung

So sieht die Meldung aus

2026/10/23 09:14:02 [error] 1234#1234: *5678 connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory) while connecting to upstream, client: 198.51.100.7, server: cloud.beispiel.de, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.3-fpm.sock:"

Häufige Ursachen

PHP-FPM ist gestoppt oder abgestürzt (z. B. nach Update oder OOM-Kill).
Socket-Pfad passt nach einem PHP-Upgrade nicht mehr, etwa php8.2-fpm.sock statt php8.3-fpm.sock.
Keine Rechte auf den Socket: listen.owner/listen.group passen nicht zum nginx-User.
Backend lauscht auf anderem Port oder nur auf IPv6/IPv4.
Der PHP-Worker stirbt mitten in der Anfrage (Segfault): upstream prematurely closed connection.

Prüfen

Letzte Fehler im nginx-Log lesen
tail -n 50 /var/log/nginx/error.log
Status von PHP-FPM prüfen
systemctl status php8.3-fpm
Existiert der Socket, und wem gehört er?
ls -l /run/php/
Logs von PHP-FPM, inklusive Abstürzen
journalctl -u php8.3-fpm -n 50 --no-pager
Lauscht ein TCP-Backend auf dem erwarteten Port?
ss -ltnp | grep -E ':(9000|3000|8000) '

Lösung

PHP-FPM bzw. das Backend neu starten: systemctl restart php8.3-fpm, danach die Ursache des Ausfalls im Journal suchen.
fastcgi_pass auf den richtigen Socket setzen, dann nginx -t && systemctl reload nginx.
Im FPM-Pool listen.owner = www-data und listen.group = www-data setzen.
Bei OOM-Kills pm.max_children an den verfügbaren RAM anpassen.
Backend per systemd mit Restart=on-failure absichern.

Häufige Fragen

Was ist der Unterschied zwischen 502 und 504?

502: Das Backend antwortet gar nicht oder fehlerhaft. 504: Das Backend ist erreichbar, braucht aber länger als der Timeout von nginx.

Warum tritt 502 nur ab und zu auf?

Typisch für abstürzende Worker oder volle Backlogs. Suchen Sie im Journal nach SIGSEGV oder OOM-Meldungen und im nginx-Log nach Resource temporarily unavailable.

HTTP 502 Bad Gateway mit nginx und PHP-FPM