Skip to content
WebAuditOS
Start free audit

Test your website now

Free, no card. We read only public pages.

Run free audit →

HTTP errors

What does 502 Bad Gateway mean, and how do you fix it?

A 502 means a proxy or load balancer got no valid answer from your app. The usual causes on modern hosting, and how to find which layer failed.

502 Bad Gateway means a server in front of your app, such as a proxy, CDN or load balancer, received an invalid response or no response from it. Usually the app crashed, is not listening on the expected port, or is still starting. Check the app's logs and the port it binds to before anything else.

Published · Last updated

By Michal Měřínský. Audit methodology.

What 502 Bad Gateway means

Almost every website today sits behind something: a CDN, a reverse proxy, a platform router or a load balancer. When that front layer forwards your request to the application and gets back nothing usable, it answers 502 on the application's behalf. The error is reported by the messenger, but the problem is almost always behind it.

Its neighbors narrow down what happened:

  • 500 Internal Server Error - the application itself answered, and the answer was an error.
  • 502 Bad Gateway - the front layer could not get a valid answer from the application at all.
  • 503 Service Unavailable - something deliberately said it cannot serve right now.
  • 504 Gateway Timeout - the application took too long to answer.

If you are a visitor

A 502 is a server-side failure. Wait a minute and reload, since many 502s are a deploy or restart in progress. If it persists across devices and networks, the site is down and only its owner can fix it.

Why your own site returns 502, most likely first

  • The app crashed or failed to start. A missing environment variable, a failed database connection or an exception at boot all leave the proxy with nothing to talk to.
  • The app listens on the wrong port or address. Platforms such as Railway, Render, Fly.io and Heroku tell your app which port to use through a PORT variable. An app hard-coded to 3000, or bound to 127.0.0.1 inside a container, is unreachable from the router.
  • A deploy is in progress and the new instance is not ready yet.
  • The app runs out of memory and is killed mid-request.
  • The upstream returns a malformed response, such as headers that are too large, which some proxies reject as a 502.
  • Your CDN cannot reach your origin because of DNS, a firewall or an origin certificate problem.

How to fix it

Read the application's logs first, at the time of the error. A crash at startup or an out-of-memory kill is usually spelled out there, and it is the single fastest diagnosis.

Then confirm the app binds where the platform expects. In Node, that looks like this:

const port = process.env.PORT || 3000;
app.listen(port, "0.0.0.0");

If the app looks healthy, test the origin directly, bypassing the CDN. A 502 that only appears through the CDN points at the connection between the two: origin DNS, firewall rules or the TLS mode.

  • Add a health check endpoint and point the platform at it, so traffic only reaches instances that are ready.
  • Check memory graphs around the failures. Steady growth followed by a restart is a leak, not bad luck.
  • If a specific route returns 502 and others do not, that route is crashing the process or producing a response the proxy rejects.

Restarting the service often makes a 502 go away for a while. Without a reason from the logs, it will come back, usually under load.

Google treats 5xx responses as a temporary server problem and slows its crawling of the site. Pages already in the index stay there at first, but if the errors persist, Google eventually drops those URLs. Short outages cost little. Repeated 502s on every deploy add up, because the crawler keeps meeting them.

What a scan can and cannot tell you

WebAuditOS records the status of every crawled page, so a 502 at scan time shows up as a critical finding, together with slow server response times that often precede one. It also checks whether you link a status page, which is where visitors look during an outage.

A scan is a snapshot. A 502 that happens for two minutes during each deploy, or only under load, will usually not be caught by a single crawl. Uptime monitoring and your platform's logs are the tools for intermittent errors.

If the very first page of a scan returns a 5xx, the scan cannot crawl further, so a fully down site produces one error rather than a list of findings.

Short answers

Is a 502 my fault as a visitor? No. It is always on the server side.

Why do I get a 502 right after deploying? The new instance is not ready yet, or it fails to start. Add a health check so traffic waits for it.

502 or 504? 502 means no valid answer, 504 means no answer in time. Both point at the app behind the proxy.

Does Cloudflare cause 502s? Cloudflare reports them when it cannot get a valid answer from your origin. The fix is almost always on the origin.

In the product

The checks this maps to

Every check named here runs on every scan, on every plan - what a plan changes is how many pages are crawled, how long the history is kept and what you can do with the result. These are the ids the findings carry, so you can match a line in a report to the explanation above.

HTTP errors

What does 503 Service Unavailable mean, and how do you fix it?

A 503 says the server cannot handle the request right now. When it is the right response, what causes accidental ones, and how to use it for maintenance.

HTTP errors

What does 500 Internal Server Error mean, and how do you fix it?

A 500 means your application hit an error it did not handle. How to find the real cause in the logs, and why the error page must never show a stack trace.