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

Is it you or the website? A one-minute check

1. Reload once after 30 seconds. Many 502s last only seconds, for example while an app restarts during a deployment.
2. Check the site with our website status checker. It requests the page through an outside checking service and reports the HTTP status code it receives.
   • It shows 502 too: the site is broken for everyone, not just you.
   • It can't get a response: the result is inconclusive. Try another network.
3. Try another browser or network. If the site works there, clear your browser cache for the site. A 502 that only one person sees is rare, but a stuck cached error page or a broken company proxy can cause it.

What happens behind a 502

Most websites aren't a single machine. A typical setup looks like this:

Your browser → CDN or load balancer → web server (Nginx/Apache) → application (PHP-FPM, Node.js, Python, …)

Each layer passes the request to the next. When one layer can't get a usable reply from the layer behind it, it returns 502. The layer that shows the error is working. The one behind it isn't.

Close relatives:

• 503 Service Unavailable: the server is up but deliberately not taking requests, because of maintenance or overload.
• 504 Gateway Timeout: the layer behind answered too slowly, not wrongly.
• Cloudflare 520–526: Cloudflare's own, more specific versions. See Cloudflare error 522.

If you're visiting the site

There isn't much you can fix. The fault is on the server side. You can:

1. Wait a few minutes and reload. Deployments and restarts often cause short 502s.
2. Clear the cached copy: do a hard reload (Ctrl+Shift+R on Windows, Cmd+Shift+R on Mac) or open an Incognito window.
3. Turn off a VPN or proxy, in case it's the middle server producing the 502.
4. Check the site's status page or social media for an outage notice.

If it's your website

Start from the layer that shows the error and work backwards.

1. Is the application running? The most common cause is a crashed or stopped app process.

   • PHP-FPM: systemctl status php8.3-fpm (adjust the version number).
   • Node.js under PM2: pm2 status.
   • Docker: docker ps.

   Restart the app and test again.

2. Read the proxy's error log at the moment of the failure. In Nginx, /var/log/nginx/error.log usually names the cause:

   • connect() failed (111: Connection refused) while connecting to upstream: nothing is listening on the address or port Nginx forwards to. Either the app is down or the port or socket path in proxy_pass/fastcgi_pass is wrong.
   • upstream prematurely closed connection: the app crashed or ran out of memory while handling the request.
   • no live upstreams: every backend in the load-balancing group is marked failed.

3. Check memory and resources. If the system killed the app for using too much memory, dmesg | grep -i oom (or journalctl -k) will show it. Raise the memory limit, reduce the number of worker processes, or fix the memory leak.

4. Check the address the proxy forwards to. After a deployment, the app may be listening on a new port, or a container may have a new internal IP. Update the proxy config to match.

5. Check firewalls between layers. A cloud security group or iptables rule can block the proxy from reaching the app server.

6. Check whether one page or every page fails.

   • One page: usually a code error on that page that crashes the app.
   • Every page: usually the app is down or misconfigured.

FAQ

Does a 502 hurt my Google rankings?

A short one doesn't. Google retries later. Repeated or long-lasting 5xx errors make Google crawl less often, and if they continue for days, pages can drop out of results.

Why does a 502 appear only sometimes?

Intermittent 502s usually mean one backend out of several is unhealthy, or the app crashes under load and restarts. Look for patterns in the error log timestamps.

Is "502 Bad Gateway nginx" an Nginx bug?

No. Nginx is reporting that the application behind it failed. Fix the app or the address Nginx forwards to, not Nginx itself.