{"id":694,"date":"2026-11-12T09:15:00","date_gmt":"2026-11-12T09:15:00","guid":{"rendered":"https:\/\/getserverexplorer.app\/?p=694"},"modified":"2026-11-10T21:54:08","modified_gmt":"2026-11-10T21:54:08","slug":"how-to-fix-502-bad-gateway-on-nginx-5-checks","status":"publish","type":"post","link":"https:\/\/getserverexplorer.app\/index.php\/2026\/11\/12\/how-to-fix-502-bad-gateway-on-nginx-5-checks\/","title":{"rendered":"How to Fix 502 Bad Gateway on Nginx (5 Checks)"},"content":{"rendered":"\n

<\/p>\n\n\n\n

Your website worked yesterday. Today, it shows 502 Bad Gateway<\/strong>. If you host a Node.js, Python, or PHP application behind Nginx, the problem is often between Nginx and the service handling your requests.<\/p>\n\n\n\n

Here are five checks to find the cause without blindly restarting everything.<\/p>\n\n\n\n

What Does 502 Bad Gateway Mean?<\/h2>\n\n\n\n

Nginx often acts as a reverse proxy<\/strong>: it receives visitors’ requests and forwards them to your application (the upstream<\/em>). A 502 response means Nginx could not get a valid response from that upstream. The application might have stopped, the port might be wrong, or Nginx might be unable to access a Unix socket.<\/p>\n\n\n\n

1. Check Whether Your Application Is Running<\/h2>\n\n\n\n

Start with the backend, not Nginx.<\/p>\n\n\n\n

For a systemd service:<\/p>\n\n\n\n

sudo systemctl status my-app\nsudo journalctl -u my-app -n 50 --no-pager<\/code><\/pre>\n\n\n\n
For a Node.js app managed by PM2:<\/p>\n\n\n\n
pm2 list\npm2 logs my-app --lines 50<\/code><\/pre>\n\n\n\n
For Docker:<\/p>\n\n\n\n
docker ps -a\ndocker logs --tail 50 my-container<\/code><\/pre>\n\n\n\n
If the application is crashing, fix that first. Restarting Nginx will not repair a broken backend.<\/p>\n\n\n\n
2. Verify the Upstream Port<\/h2>\n\n\n\n
Suppose your Nginx configuration forwards requests to 127.0.0.1:3000<\/code>. Check whether anything is listening there:<\/p>\n\n\n\n
sudo ss -ltnp | grep ':3000'<\/code><\/pre>\n\n\n\n
Then test the backend directly from the server<\/strong>:<\/p>\n\n\n\n
curl -i http:\/\/127.0.0.1:3000\/<\/code><\/pre>\n\n\n\n
A 404<\/code> from your app can still prove the upstream is reachable; Connection refused<\/code> suggests nothing is listening at that address and port. A timeout may indicate a different network or application issue.<\/p>\n\n\n\n
If the backend runs in Docker, confirm the port mapping and whether Nginx is on the host or inside another container. localhost<\/code> inside a container refers to that container, not the host or another container.<\/p>\n\n\n\n
\"Server<\/figure>\n\n\n
\n \n \n  \n  \n  \n <\/g>\n \n  \n <\/g>\n \n  \n  \n <\/g>\n <\/g>\n<\/svg>\n 
\n  <\/span>Server Explorer<\/span>\n  
Bring your servers into focus.<\/h3>\n  
A desktop app for macOS and Windows. Connect over SSH.<\/p> <\/div>\n Download\u2197<\/span><\/a>\n<\/div>\n\n\n\n\n
3. Read the Nginx Error Logs<\/h2>\n\n\n\n
The error log usually gives you the strongest clue:<\/p>\n\n\n\n
sudo tail -n 80 \/var\/log\/nginx\/error.log<\/code><\/pre>\n\n\n\n
Or inspect the service journal:<\/p>\n\n\n\n
sudo journalctl -u nginx -n 80 --no-pager<\/code><\/pre>\n\n\n\n
Common messages include:<\/p>\n\n\n\n