A 502 Bad Gateway almost never means nginx is broken. It means nginx is fine — it's the thing behind nginx that didn't answer. The 502 is a messenger: your reverse proxy tried to reach an upstream (an app server, a container, a PHP-FPM socket) and got nothing usable back. Fix the upstream and the 502 disappears.
1. Read the nginx error log — it names the cause
The access log shows the 502; the error log explains it. Tail it and look at the exact wording:
tail -f /var/log/nginx/error.log # "connect() failed (111: Connection refused)" -> upstream is down # "upstream timed out" -> upstream too slow # "no live upstreams" -> all backends marked down
2. Is the upstream actually up?
Find where nginx is proxying (the proxy_pass / upstream block in the site config) and test that target directly, cutting nginx out of the picture: curl -v http://127.0.0.1:3000/. If curl also fails, the backend is your problem — check systemctl status for the app (or docker ps if it's a container that crashed or never came up).
3. Match the plumbing
If the backend is running but nginx still 502s, the two disagree about how to talk: a wrong port, a unix socket path that moved, or an SELinux rule blocking the connection (see SELinux denials). Make proxy_pass point at exactly where the app is listening.
4. Reload, don't restart
After editing config, validate it first with nginx -t, then systemctl reload nginx — a reload re-reads config with zero downtime, where a bad restart can leave you fully down.
Practise it on a live 502
A dead backend behind a proxy is a recurring incident in the simulator. Work the proxy-vs-upstream split on a real box with incident response practice, and sharpen log reading with reading journalctl.