502 Bad Gateway: What It Means and How to Fix It

502 Bad Gateway is one of the most common errors after deploying an app, and the name hides what it actually means:

The server in front of your app tried to pass the request to your app, and got no valid answer back.

Most apps don't face the internet directly. A reverse proxy — Nginx, Caddy, Cloudflare, a load balancer, or your host's router — receives the request and forwards it to your app on some internal port. (Reverse proxies explained) A 502 is that proxy saying "I called the app and it didn't pick up properly."

So the problem is almost never the proxy. It's your app.

The usual causes

1. Your app isn't running. It crashed on start-up or later.
2. It's running on the wrong port — the proxy forwards to 3000, your app listens on 8080.
3. It's listening on the wrong address — localhost/127.0.0.1 inside a container, unreachable from the proxy.
4. It's still starting. A deploy restarted it and requests arrived first.
5. It ran out of memory and was killed. (Container memory limits)
6. It sent back something invalid — rare, but happens with oversized headers.

Find the cause in five steps

1. Look at the app's logs, not the proxy's. The answer is usually right there: a stack trace, Error: Cannot find module, a missing environment variable, a database connection refused.

pm2 logs            # if you use PM2
journalctl -u myapp -n 100   # systemd
docker logs myapp   # Docker

2. Is the process alive? pm2 ls, systemctl status myapp, docker ps. If it's restarting over and over, it's crashing on start-up — back to the logs.

3. Can you reach it directly from the server?

curl -i http://127.0.0.1:3000/

If this works, the app is fine and the proxy is pointing somewhere else. If it fails, the app isn't listening there.

4. Check port and address. Your app should use the port it's given (often process.env.PORT) and, in containers, listen on 0.0.0.0, not localhost. (Ports explained)

app.listen(process.env.PORT || 3000, '0.0.0.0')

5. Check the proxy's upstream setting. In Nginx, proxy_pass http://127.0.0.1:3000; must match where the app listens.

Intermittent 502s

If 502s come and go:

• During deploys — the old process stopped before the new one was ready. Use a health check and start the new version first. (Zero-downtime deploys, health check endpoints)
• Under load — the app is crashing from memory or running out of database connections. Check memory graphs and connection pooling.
• Keep-alive mismatch — the app closes idle connections sooner than the proxy expects. In Node, set server.keepAliveTimeout higher than the proxy's idle timeout.

502 vs 503 vs 504

Code	Proxy is saying
502 Bad Gateway	"The app gave me no valid answer" (crashed, refused)
503 Service Unavailable	"The app is deliberately unavailable" (overloaded, maintenance)
504 Gateway Timeout	"The app took too long to answer"

A 504 points at slow code or a slow database query rather than a crash. (HTTP status codes explained)

Cloudflare's 502 page

If the error page has Cloudflare branding, Cloudflare couldn't get a good answer from your server. Same steps apply. If it's Cloudflare's own problem, their page says so explicitly, and their status page will confirm.

The summary

• 502 = the proxy couldn't get a valid answer from your app.
• Read your app's logs first — the cause is usually there.
• Check the process is running, on the right port, listening on 0.0.0.0.
• Intermittent 502s point at deploys, memory or connection limits.

---

EasySpawn runs your app with health checks, keeps it restarted if it crashes, and puts its logs one click (or one Claude Code question) away. See how it works or join the waitlist.

Related: 500 Internal Server Error · Why Does My App Work Locally but Not in Production? · HTTP Status Codes Explained · What Is Nginx?