Fix Nginx 502 Bad Gateway

The Problem

Visitors see "502 Bad Gateway" instead of your site — Nginx itself is up and responding, but the application behind it (PHP-FPM, Node, or whatever it's proxying to) isn't answering correctly, timed out, or crashed, and Nginx has nothing to show for it.

About this problem

A 502 means Nginx successfully received the request but got an invalid or empty response from the upstream service it's supposed to be talking to — different from a 404 or 500, which come from the application itself actually running and failing. It's extremely common after a PHP-FPM pool crashes under load, a backend service restarts or hasn't started yet, a socket/port mismatch between Nginx and the app, or a timeout set too low for a slow-running request.

It shows up most often right after a deploy, a server reboot, a PHP version change, or during a sudden traffic spike that exhausts the available PHP-FPM workers.

What's Included

• Checking Nginx and upstream (PHP-FPM/app) error logs together to find the real failure
• Confirming the upstream service is actually running and listening on the socket/port Nginx expects
• Checking for resource exhaustion (PHP-FPM worker limits, memory, CPU) at the time of failure
• Adjusting timeout and buffer settings if the upstream is just slow rather than down
• Restarting/reconfiguring the affected service and confirming the site loads normally again

What's NOT Included

• Fixing bugs in your application's own code that cause it to crash (flagged separately if found)
• Scaling your server or upgrading your hosting plan — that's a capacity decision for you
• Ongoing monitoring to catch future 502s before they happen (see server monitoring/alerts service)

How It Works

1. Reproduce the error and immediately check Nginx's error log for the specific upstream failure message (connection refused, timed out, etc.).
2. Check whether the upstream service (PHP-FPM, Node, or whatever Nginx proxies to) is running and bound to the socket or port Nginx's config expects.
3. If the service is running, check its own logs for crashes, out-of-memory kills, or worker pool exhaustion around the time of the error.
4. Review Nginx's proxy/fastcgi timeout and buffer settings against how long the backend genuinely takes to respond.
5. Apply the fix — restart or reconfigure the upstream service, correct a socket/port mismatch, or raise a timeout that was set too aggressively.
6. Load the site repeatedly under light load to confirm the 502 doesn't reappear before calling it resolved.

In practice: you buy the service, send over whatever access or details the job needs, I investigate and do the work, and you confirm it's resolved before we call it done.

Frequently Asked Questions

What does a 502 Bad Gateway error actually mean?

It means Nginx (or another proxy/load balancer) passed your request along to another service but got back an invalid, empty, or no response at all — the problem is in the backend it's talking to, not Nginx itself.

Is a 502 error the same as a 500 error?

No. A 500 means the application itself ran and hit an error. A 502 means the proxy in front of it couldn't get a proper response from that application at all — it never got far enough to produce a 500.

Why does my site show 502 right after I deploy new code?

A fresh deploy often restarts PHP-FPM or your app process, and if Nginx sends a request in that brief restart window, it finds nothing listening yet and returns 502. It usually settles once the service is fully back up.

Can high traffic cause a 502 error?

Yes. If PHP-FPM or your backend runs out of available workers to handle incoming requests, new requests get rejected or time out, and Nginx reports that as a 502.

Will restarting my server fix a 502 error?

Sometimes, if it was caused by a stuck process, but it doesn't address the underlying cause — the same issue often comes back under the same conditions unless the actual trigger is fixed.

Can a firewall cause a 502 Bad Gateway?

Yes — if a firewall rule is blocking communication between Nginx and the backend service, Nginx sees the upstream as unreachable and returns a 502.