You loaded a page and got 502 Bad Gateway. The short version: one server asked another server for a response and got something invalid back. It's a server-side error, so if you're just visiting, it's not your fault — and if you run the site, it's a sign your backend is unhappy.
What 502 Bad Gateway means
Modern sites rarely talk to a backend directly. A request passes through a chain — a CDN, a load balancer, a reverse proxy (like Nginx) — before reaching the application server. When one of those middle servers (the "gateway") forwards your request upstream and gets back an invalid or empty response, it returns a 502.
It's a 5xx code, which means server error. The gateway itself is usually fine — the thing behind it isn't.
Common causes
| Cause | What's happening |
|---|---|
| Upstream is down | The backend app crashed or was never started |
| Backend overloaded | Too much traffic; the app can't respond in time |
| Bad proxy config | Nginx/HAProxy pointing at the wrong port or host |
| Process crash | PHP-FPM, Node, or the app worker died mid-request |
| Firewall / DNS | Proxy can't reach the origin (blocked or unresolved) |
| CDN can't reach origin | Cloudflare/Fastly gets nothing back from your server |
How to fix it — as a visitor
- Reload the page — many 502s are momentary.
- Wait a few minutes and retry; the site may be restarting.
- Clear your cache or try a private window / different network.
- If it persists across sites, restart your router or flush DNS.
How to fix it — as a developer
- Is the origin up? SSH in and confirm the app process is running (
systemctl status,pm2 list, container health). - Check the proxy config. Confirm the upstream host/port in your Nginx/HAProxy/load balancer matches where the app actually listens.
- Read the backend logs. A 502 almost always has a matching crash or timeout in the app logs.
- Check resources. Out-of-memory kills and connection-pool exhaustion produce 502s under load.
- Verify network. Firewall rules, security groups, and DNS between proxy and origin.
How to catch the next one before users do
The worst part of a 502 is finding out from an angry customer. Monitoring the actual response codes of your endpoints turns that around: when / or /api starts returning 502s, you get alerted in seconds, not in a support ticket.
Nurbak Watch checks your endpoints from multiple regions and tracks status codes and error rates per route — so a spike of 502s pages you on Slack, email or WhatsApp the moment it starts.

