502 Bad Gateway: Causes & Fixes

By Marcus Feld, Infrastructure Editor

What a 502 Bad Gateway Error Means

A 502 Bad Gateway error means a server acting as a gateway or proxy (a reverse proxy, load balancer, or CDN edge node) asked an upstream server, your actual web application, for a page and got back something invalid, garbled or empty. The proxy is doing its job. It’s reporting that the server behind it failed to answer properly.

That is what separates a 502 from a 500. A 500 is your application failing while handling a request. A 502 is a failure one step further back, at the handoff between two pieces of software. On most modern hosting that handoff is happening even when you can’t see it: a web server such as Nginx passes PHP requests to PHP-FPM, or a CDN passes visitors to your origin. Any of those joins can produce a 502, which is why the error is so common on setups with a CDN or a separate application server.

The practical upshot is that a 502 narrows your search. You’re not hunting through every plugin first. You’re asking which link in the chain is broken, and whether it is a link you control.

Is It the Server, the Application or the Network?

• Application or process layer (most likely). The process that runs your code (PHP-FPM, Node, Gunicorn and so on) crashed, hung or was restarted, and the web server has nothing valid to relay.
• Server layer. The origin is overloaded or ran out of memory and is dropping connections, or a firewall is rejecting the internal handoff.
• Network and CDN layer. A CDN or proxy in front of you can’t reach the origin, can’t agree on SSL with it, or can’t resolve its address. The fault may be at the CDN, at your origin, or in the link between them.

The quickest first question is whether your site returns a 502 when you bypass the CDN (or proxy) and hit the origin directly. If the origin works and the CDN shows a 502, the problem is in the connection between them. If the origin fails too, look at the server and application.

Common Causes of a 502 Bad Gateway Error, Ranked

This ordering reflects typical patterns on WordPress and PHP hosting behind Nginx or a CDN. It is a practical ranking from experience, not measured data, and your own stack may differ.

Crashed or Overloaded PHP-FPM Process

The process that hands requests to PHP dies or hangs, often because it ran out of available workers or memory, and Nginx has nothing valid to relay back. A single runaway script can tie up every worker at once.

Backend Server Overload

A traffic spike or resource-heavy script exhausts CPU or RAM on the origin, which then drops or garbles responses. Bot crawls and poorly cached pages are frequent contributors.

Misconfigured Reverse Proxy or CDN

Timeout values, buffer sizes or SSL mismatches between the proxy and origin cause the proxy to reject a response. A classic example is a CDN set to require a valid certificate while the origin has an expired or self-signed one.

DNS Resolution Failure at the Proxy Level

The proxy can’t resolve the origin server’s address, often right after a migration or IP change, or when the CDN is still pointed at the old server.

Firewall or Security Plugin Blocking the Internal Request

An aggressive WAF rule, rate limiter or host-level firewall blocks legitimate traffic between the proxy and the application server. This one often appears right after you enable a new security layer.

Origin Server Down for Maintenance or a Restart

Brief 502s during a reboot, update or deployment are expected and normally clear in seconds to a few minutes.

Step-by-Step Fix for a 502 Bad Gateway Error

1. Reload after a short wait. Many 502s are transient, caused by a brief restart or momentary overload, and clear within seconds to a couple of minutes. If it’s gone on reload, check whether it recurs before doing anything else.
2. Confirm it’s not just you. Try another device, another network, and a private window. A broken browser extension or local DNS cache can mimic the error. Clearing those costs nothing.
3. Check whether you’re behind a CDN or proxy (Cloudflare, a caching layer, a load balancer). If so, check that service’s status page first. The fault may sit there, not with your host. Many CDNs also show a different error page for “origin unreachable” versus “origin returned a bad response”, and the wording tells you which half failed.
4. Test the origin directly if you can, by bypassing the CDN through a temporary hosts-file entry or a direct origin address. This single test splits the problem neatly in two.
5. Check server resource usage in your hosting panel or VPS dashboard for CPU, RAM and process-count spikes around the time of the error.
6. Read the web server and PHP-FPM logs, not the browser message. Lines mentioning “upstream”, “connection refused” or “no live upstreams” (Nginx), or a worker limit being reached (PHP-FPM), tell you exactly which handoff is failing.
7. Restart PHP-FPM (or your application service) through your control panel or SSH if you have access. A hung process is the most common single fix. If a restart cures it for an hour and it comes back, you’ve found the symptom, not the cause.
8. Review recent deployments or config changes to the web server, proxy, CDN or DNS. A 502 that began right after a change points straight at that change.
9. Check proxy timeout and buffer settings if only specific pages fail, such as large exports or reports. Raising the timeout resolves 502s tied to legitimately slow responses, but read the 504 guide below too, because slow responses more often become 504s.
10. Temporarily disable a security plugin or WAF rule added recently, to rule out it blocking internal traffic, then re-enable it with a corrected rule.
11. Escalate to hosting support with a timestamp and the web server log lines if the error recurs without a clear trigger.

When It’s Your Fault and When It’s the Host’s

It is on your side when the 502 began after a code deployment, a plugin change, a new security rule or a CDN settings change, when one specific heavy page triggers it, or when you run your own server and PHP-FPM is set with too few workers for your traffic.

It is on the host’s side when the origin itself is unreachable or rebooting, when many sites on the same server fail at once, when resource caps you didn’t exceed are being enforced, or when their network or load balancer is returning the error. The honest tell is timing and scope: a problem hitting one site after a change is usually yours, while a problem hitting several unrelated sites at once is usually theirs.

If you’re on managed hosting, PHP-FPM tuning is the host’s job and a repeating crash loop is worth a firm ticket. If you’re on an unmanaged VPS, it’s yours, and that’s one of the real trade-offs of running your own server.

How to Prevent 502 Bad Gateway Errors

• Size your hosting plan for peak traffic, not average traffic. Recurring 502s during traffic spikes usually mean the plan is undersized, and your uptime and SLA terms tell you what compensation, if any, applies when the host’s own infrastructure is at fault.
• Cache aggressively so fewer requests reach PHP at all. Every page served from cache is one less request that can hang a worker.
• Monitor PHP-FPM or application process health if you manage your own server, and alert on worker exhaustion before it becomes an outage.
• Set proxy timeouts to match your slowest legitimate page, not a generic default.
• Keep your origin’s SSL certificate valid and auto-renewing if a CDN validates it.
• Test major deployments and CDN or proxy changes on staging before pushing to the live domain.
• If 504 timeouts also show up alongside 502s, review the related 504 Gateway Timeout guide. The two often share the same overload root cause.

When to Contact Your Host

Contact your host once you’ve confirmed the fault sits at their server or network layer: a resource cap hit on a plan that should handle your traffic, a process crash in the server logs with no matching change on your end, or other sites on the same server failing too. Bring a timestamp, the URL, and whether the origin works when you bypass the CDN. That last detail gets you to an engineer faster than any other. If you’re behind a third-party CDN, check its status page and support channel first, since the 502 may originate there. See the common hosting errors overview for how a 502 fits alongside the other server-error codes, and the status codes cheat sheet for the full reference.

FAQ

Is a 502 error my fault or my host’s fault? It can be either. A recent plugin, deployment or CDN change on your side causes many 502s; a genuine backend overload or process crash on the host’s infrastructure causes the rest. The server logs, and whether other sites are affected, distinguish the two.

Why do I only see a 502 error sometimes, not always? Intermittent 502s usually point to intermittent overload: a process that’s fine most of the time but crashes or hangs under a traffic spike or a resource-heavy request. A bot crawl or a scheduled job can be the trigger.

Does a 502 mean my site’s data is lost? No. A 502 is a request-handling failure, not a data-loss event. Your files and database are untouched; the server simply couldn’t complete that specific response.

Is a 502 the same as a 504 Gateway Timeout? No. A 502 means the upstream server responded, but with something invalid or refused the connection. A 504 means the upstream server never responded within the allowed time at all. See the 504 Gateway Timeout guide for that distinction in detail.

Will a 502 hurt my search rankings? A brief one won’t. Repeated or long-lasting 502s can slow how often search engines crawl you and, if they persist, lead to pages dropping out of the index, so it’s worth fixing recurring ones promptly.