HTTP 502 Bad Gateway with nginx and PHP-FPM

What the message looks like

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:"

Common causes

• PHP-FPM is stopped or crashed (e.g. after an update or an OOM kill).
• The socket path no longer matches after a PHP upgrade, e.g. php8.2-fpm.sock instead of php8.3-fpm.sock.
• No permission on the socket: listen.owner/listen.group do not match the nginx user.
• The backend listens on a different port or only on IPv6/IPv4.
• The PHP worker dies mid-request (segfault): upstream prematurely closed connection.

Check

1. Read the latest errors in the nginx log
   tail -n 50 /var/log/nginx/error.logCopy
2. Check PHP-FPM status
   systemctl status php8.3-fpmCopy
3. Does the socket exist and who owns it?
   ls -l /run/php/Copy
4. PHP-FPM logs, including crashes
   journalctl -u php8.3-fpm -n 50 --no-pagerCopy
5. Is a TCP backend listening on the expected port?
   ss -ltnp | grep -E ':(9000|3000|8000) 'Copy

Fix

• Restart PHP-FPM or the backend with systemctl restart php8.3-fpm, then look for the root cause in the journal.
• Point fastcgi_pass to the correct socket, then nginx -t && systemctl reload nginx.
• Set listen.owner = www-data and listen.group = www-data in the FPM pool.
• On OOM kills, size pm.max_children to the available RAM.
• Protect the backend with systemd Restart=on-failure.

FAQ

What is the difference between 502 and 504?

502: the backend does not answer at all or answers garbage. 504: the backend is reachable but takes longer than the nginx timeout.

Why does 502 only happen occasionally?

Typical for crashing workers or a full listen backlog. Look for SIGSEGV or OOM messages in the journal and Resource temporarily unavailable in the nginx log.