Nginx `502 Bad Gateway` Usually Means Your Proxy Is Fine but the Upstream App Is Dead, Listening on the Wrong Port, or Failing Before Nginx Ever Gets a Real Response

Why this issue matters: a 502 page makes Nginx look guilty, but most of the time Nginx is merely the messenger telling you the upstream application is not answering in a usable way.

One of the most common production or VPS issues is:

502 Bad Gateway

People jump straight into editing nginx.conf, but the real upstream failure is often elsewhere.

What 502 usually means

Nginx tried to talk to the configured upstream and failed because:

1. the app process is down
2. the app listens on a different port or socket
3. the Unix socket path is wrong
4. permissions block socket access
5. the app crashes before responding

First validate Nginx config anyway

Do the cheap check:

nginx -t

If that passes, move quickly to the upstream app instead of obsessing over syntax.

Check the upstream target

If your config says:

proxy_pass http://127.0.0.1:8000;

then confirm something is actually listening there:

lsof -iTCP:8000 -sTCP:LISTEN -n -P

If you use a Unix socket:

proxy_pass http://unix:/run/myapp.sock;

then verify the socket exists:

ls -l /run/myapp.sock

Read the real logs

Nginx error log:

tail -f /var/log/nginx/error.log

App logs:

journalctl -u myapp -f

or for a process manager:

pm2 logs

The paired view matters. Nginx often tells you “connection refused” while the app logs tell you why the process never came up.

Verify the app manually

If Nginx proxies to a local HTTP service, hit it directly:

curl -i http://127.0.0.1:8000/health

If this fails too, Nginx is not your first problem.

Typical fixes

• restart the upstream service
• correct proxy_pass
• fix the app bind address
• fix socket ownership and permissions
• correct the port in the app service config

A common mistake is running the app only on:

127.0.0.1:3000

while Nginx still proxies to:

127.0.0.1:8000

That is not a proxy mystery. That is just a stale upstream target.

Final recommendation

Treat 502 as an upstream availability problem first. Validate Nginx config once, then inspect the real listener, curl the upstream directly, and read both Nginx and app logs together. Most 502s are solved by fixing the app side, not by rewriting the proxy.

Sources

• Nginx reverse proxy documentation
• Nginx beginner’s guide