Quick answer: 502 means the web server (nginx/Apache as proxy) could not get a valid response from the backend — usually PHP-FPM or your app process is dead, restarting, or listening on a different socket/port than the proxy expects. systemctl status php8.3-fpm and the nginx error log identify which in under a minute.

Overview

Think of 502 as "the receptionist is fine, the office behind is empty". nginx is up and answering; the upstream it forwards to is not. The fix is almost always on the upstream side: start it, resize it, or point the proxy at the right address.

Before you start

  • SSH access; know your upstream (PHP-FPM, node app, gunicorn...).

Step-by-step guide

  1. Read the precise reason:
    sudo tail -n 30 /var/log/nginx/error.log
    connect() failed (111) = upstream down; no such file on a .sock path = socket mismatch; upstream timed out = see the 504 guide.
  2. Check and start the upstream:
    sudo systemctl status php8.3-fpm
    sudo systemctl restart php8.3-fpm
  3. Verify the socket/port matches on both sides:
    grep -r fastcgi_pass /etc/nginx/sites-enabled/
    ls -l /run/php/
    After PHP upgrades the socket name changes (php8.1-fpm.sock → php8.3-fpm.sock) — a classic 502.
  4. Check why the upstream died: OOM kill (sudo dmesg -T | grep -i oom), full disk, crash loop in journalctl -u php8.3-fpm.
  5. Under load, raise PHP-FPM capacity carefully (pm.max_children) within available RAM.

Common issues

  • 502 right after a PHP upgrade: nginx still points to the old socket.
  • Intermittent 502 at traffic peaks: FPM pool exhausted — requests queue and get dropped.
  • OOM killer strikes the backend: the biggest process loses; add RAM or swap.

When to contact support

If upstreams are healthy, sockets match, and 502s persist with logs showing nothing, open a ticket with the nginx error-log excerpt and timestamps.

Frequently asked questions

What does a 502 actually tell me?

The proxy in front (nginx or Apache) is healthy but got no valid answer from the backend such as PHP-FPM. The backend is down, restarting, crashed, or listening on a different socket or port.

Why did 502 errors start right after a PHP upgrade?

The PHP-FPM socket path contains the version, so nginx configs pointing at the old socket break. Update fastcgi_pass to the new socket name and reload nginx to fix it.

Related articles

Need a hand? Contact Cloud2Y support →

Was this answer helpful? 0 Users Found This Useful (0 Votes)