A 502 Bad Gateway is one of the more useful error codes, because it tells you something specific: your request did reach a server, that server tried to pass it to another one behind it, and the answer that came back was unusable. The site is not simply "down" — one link in a chain is broken.
Knowing which link narrows the search enormously. This guide explains what the "gateway" is in practice, how 502 differs from the 500 and 504 people constantly confuse it with, the causes ranked by how often they actually turn out to be the culprit, and what you can realistically do if you are on shared hosting and cannot touch the server.
What "Bad Gateway" Actually Means
Most websites are not served by one program. A front server — typically Nginx, Apache or a CDN such as Cloudflare — receives your request and hands it to something behind it: PHP-FPM, a Node process, a Python app, or another web server entirely. In that arrangement the front server is acting as a gateway.
A 502 is the front server telling you, honestly, that it did its job and the thing behind it did not. It either got no reply, got a reply it could not parse, or had the connection closed on it mid-answer. The front server is working — that is precisely why you got a formatted error page instead of a timeout.
How 502 Differs from 500 and 504
These three get treated as interchangeable "server errors", which sends people looking in the wrong place. They point at genuinely different components.
| Code | What it means | Where to look first |
|---|---|---|
| 500 Internal Server Error | The application itself threw an error while running | Your code, the PHP error log, a broken plugin or theme |
| 502 Bad Gateway | The backend gave the front server an invalid or empty reply | Is the backend process running? Did it crash or run out of memory? |
| 503 Service Unavailable | The server is up but deliberately not serving right now | Maintenance mode, overload protection, or a full request queue |
| 504 Gateway Timeout | The backend was reachable but answered too slowly | Long-running queries, slow external APIs, timeout settings |
The Usual Causes, Most Likely First
- The backend process crashed or was never started. PHP-FPM, Node or the application service is not running, so there is nothing for the front server to talk to. This is by far the most common cause.
- The server ran out of memory and the kernel killed the backend. Look for OOM-killer entries in the system log — the process disappears without any error of its own, which is exactly what produces a 502.
- The backend is overloaded and refusing new connections. All PHP-FPM workers are busy, so new requests are rejected outright rather than queued.
- A misconfigured proxy target. After a deployment or config change, the front server is pointing at the wrong port or socket. If the 502 started immediately after a change, start here.
- A firewall rule between the two components. Common on multi-server setups where the front end and the application live on different machines.
- The backend returned malformed output. A PHP fatal error printed before the headers, or a process that writes to stdout when it should not, can produce a reply the gateway cannot parse.
- A CDN or reverse proxy problem. If you are behind Cloudflare, a 502 can come from Cloudflare itself rather than your origin — the error page usually says which.
Work Through It in This Order
This sequence is arranged to eliminate the most likely causes with the least effort, and to avoid the classic mistake of restarting things at random until something changes.
- Check whether the backend is actually running. On a Linux server: "systemctl status php-fpm" or the equivalent for your stack. If it is dead, that is your answer and the next question is why.
- Read the front server error log before restarting anything. Nginx writes the real reason to /var/log/nginx/error.log — "connect() failed", "no live upstreams" and "recv() failed" each point somewhere different. Restarting first destroys this evidence.
- Check free memory and the system log for the OOM killer. If the backend keeps dying under load without logging an error of its own, the kernel is killing it and the machine is undersized for the traffic.
- Confirm the proxy target matches where the backend is really listening — the port or socket path in the front server config versus the one in the backend config. A single mismatched digit does this.
- Restart the backend, then the front server, in that order. Only now, once you have collected the evidence.
- If it is intermittent rather than constant, correlate it with traffic. A 502 that appears at peak and clears at night is a capacity problem, not a configuration bug, and no amount of config tweaking will fix it.
What You Can Do on Shared Hosting
On shared hosting you cannot inspect PHP-FPM or read the system log, so most of the steps above are closed to you. That does not leave you helpless, but it does change the approach.
Start by checking whether the error affects your site alone or every site on the server — if the host has a status page, look there first. Then think about what changed on your side: a plugin update, a theme change, or a script that started consuming far more memory than before. Rolling that change back is usually faster than diagnosing it.
If 502s keep returning under normal traffic, the honest answer is often that the account has outgrown shared hosting. On a shared server your resources are shared with everyone else on the machine, and a neighbour's traffic spike can knock out your site through no fault of your own. Moving to a VPS with dedicated CPU and RAM removes that entire category of problem, and also gives you the logs you need to diagnose the next one yourself.
Stop sharing your server with someone else's traffic spike
Cloud VPS with dedicated CPU and RAM, full root access and real logs you can read — from ฿150/month.
Frequently Asked Questions
Is a 502 my fault or the hosting provider's?
It depends on which component failed. If your application crashed or ran out of memory, that is your side. If the provider's front-end infrastructure or network is broken, that is theirs. The quickest way to tell is whether other sites on the same host are also affected — if they are, it is not your code.
Why does the 502 come and go instead of staying broken?
Intermittent 502s almost always mean a capacity limit rather than a configuration error. Under load the backend runs out of workers or memory, drops requests, then recovers when traffic falls. Configuration errors, by contrast, break every single request consistently.
Does a 502 hurt my SEO?
A brief one does not. Google retries and treats short outages as transient. Sustained 502s over days are a different matter — crawling slows, and pages can eventually be dropped from the index. The practical rule is that hours are survivable and days are not.
I use Cloudflare. How do I know whether the 502 is from Cloudflare or my server?
Cloudflare's own error pages are branded and include a ray ID and a diagram showing which hop failed. A plain, unstyled 502 is coming from your origin server. If the diagram shows the failure at the origin, Cloudflare is fine and the problem is on your side.
GUIDES
Related articles
Keep reading on similar topics
500 Internal Server Error — Causes and How to Fix It
A 500 is the least informative error on the web: it means "something went wrong and I am not telling you what". The good news is that the server almost always wrote the real reason to a log file. This guide shows you where that log lives and how to work through the causes in the order that finds the culprit fastest.
Read more
504 Gateway Timeout — And Why Raising the Timeout Is the Wrong Fix
A 504 means the backend was reachable but too slow to answer in time. The instinctive fix — raise the timeout — turns a fast error into a slow one and solves nothing. This guide covers what actually causes 504s and how to fix the cause instead of the symptom.
Read more
ERR_CONNECTION_TIMED_OUT — What It Means and How to Fix It
The page just hangs and then Chrome says ERR_CONNECTION_TIMED_OUT. This guide shows you how to work out in two minutes whether the problem is on your side or the server side, then walks through the fixes for each — plus how this error differs from the similar-looking ones people confuse it with.
Read more