In short
A 502 Bad Gateway error is returned by a server acting as a gateway or proxy, such as a CDN, a load balancer or Nginx in front of an application, when the server behind it, the origin, returned an invalid response or none at all. The usual causes are the application process having crashed or not started, the origin being overloaded or timing out, a misconfigured upstream address or port, a firewall blocking the proxy, or the origin's certificate failing when the proxy connects over HTTPS. The visitor cannot fix it; the site owner fixes it at the origin.
What sits between the visitor and the site
Few websites are served directly by the application that generates them. A request typically passes through a CDN such as Cloudflare, then a load balancer or a reverse proxy such as Nginx, before reaching the application process, PHP-FPM, Node, Python or whatever runs the site. Each layer forwards the request onward and relays the answer back.
A 502 is what one of those forwarding layers says when the layer behind it did not give a valid answer. The visitor sees an error page from the front layer, often with its branding, which is why Cloudflare's 502 page is the one many people recognise. The error is not at the front; the front is reporting that the back failed.
The usual causes
The application is not running. The process crashed, ran out of memory and was killed, or was never started after a deploy or a reboot. The proxy connects to the port, finds nothing listening, and reports 502. This is the most common cause on VPS and container hosting.
The application is too slow. It is running but took longer to respond than the proxy's timeout, typically 30 to 100 seconds. Proxies report this as 502 or 504 depending on configuration. Slow database queries, an external API call that hangs, or a traffic spike that saturates the workers are the usual reasons.
Wrong upstream configuration. The proxy points at the wrong host, port or socket path, often after a migration or a config edit. Everything is running; nothing is connected.
A firewall between the layers. The origin's firewall does not allow the CDN's or load balancer's IP ranges, or a security rule at the origin blocks the proxy's requests.
Origin certificate problems. When a CDN connects to the origin over HTTPS in full or strict mode and the origin's certificate is expired, self-signed without being trusted, or for the wrong hostname, the CDN refuses the response. Cloudflare reports some of these as 526 rather than 502, but not all configurations do.
Overloaded PHP-FPM or worker pool. All workers busy, new connections refused or queued past the timeout. Common on shared hosting under load and on under-provisioned servers.
The proxy itself misconfigured or restarting. Less common; a bad Nginx configuration reload or a load balancer with no healthy targets.
A problem at the CDN. Rare but real; check the provider's status page before anything else.
Is it the CDN or the origin?
If the site is behind Cloudflare or a similar CDN, the fastest test is to bypass it. Request the origin directly by its IP address or a direct hostname if one exists, or temporarily set the DNS record to bypass the proxy. If the origin answers correctly, the problem is between the CDN and the origin: firewall, certificate mode, or the CDN's configuration. If the origin also fails, the problem is at the origin, and the CDN was only the messenger.
Cloudflare's error page distinguishes: a 502 with Cloudflare branding and the words "host error" indicates the origin; "Cloudflare" errors in the 52x range have specific meanings that its documentation lists.
The diagnosis in order
- Check the provider status pages for the CDN and the host.
- Bypass the CDN and hit the origin directly. Origin fine: fix the CDN-to-origin path. Origin fails: continue.
- Is the application process running?
systemctl status, the process manager's status, the container's logs. If not, start it and read why it stopped. - Read the proxy's error log. Nginx logs "connect() failed" (nothing listening), "upstream timed out" (too slow), or "upstream prematurely closed" (the app crashed mid-request). Each names the cause.
- Read the application log for the crash or the slow request.
- Check the upstream configuration against what the application is actually listening on.
- Check the firewall allows the proxy's addresses.
- Check memory and worker limits. An out-of-memory kill or an exhausted pool is a capacity problem, not a bug.
Most 502s on small sites resolve at step 3: the process was down and needed restarting, and the log says why.
Preventing it
Run the application under a process manager that restarts it on failure and starts it on boot. Add a health check the proxy or load balancer uses, so a dead instance is taken out of rotation and an alert fires. Set timeouts deliberately and make slow operations asynchronous through background jobs rather than holding the request. Provision workers for peak, not average. And monitor for 5xx rates, so the first 502 is a notification rather than a customer complaint.
A 502 is one of the ways a site goes down that has a clear layered diagnosis. If yours persists after the sequence above, book a call and we will trace the request through the layers with you.
Common questions
How do I fix a 502 Bad Gateway error on my website?
Check whether the application process behind your proxy or CDN is running and restart it if not, reading its log for why it stopped. If it is running, check the proxy's error log for timeouts or connection failures, verify the upstream host and port in the proxy configuration, and confirm the origin firewall allows the proxy's addresses. Bypassing the CDN tells you whether the fault is at the origin.
Is a 502 error the visitor's fault?
No. It is a server-side error reported by a gateway or proxy when the server behind it failed to respond properly. As a visitor, reloading after a moment sometimes works if the outage was brief; otherwise nothing on your side changes it. The site owner fixes it at the origin server.
What is the difference between 502 and 504?
A 502 Bad Gateway means the proxy received an invalid or no response from the upstream server, typically because the application is down or crashed. A 504 Gateway Timeout means the upstream did not respond within the proxy's time limit, typically because the application is running but too slow. Some proxies report timeouts as 502, so check the proxy log for the precise cause.
Why does Cloudflare show a 502 error?
Because Cloudflare, acting as the proxy, could not get a valid response from your origin server. Usually the origin application is down, overloaded, blocking Cloudflare's IP ranges at its firewall, or failing the TLS connection when Cloudflare connects over HTTPS. Bypass Cloudflare and request the origin directly to confirm, then fix the origin or the origin-to-Cloudflare configuration.
Can a traffic spike cause a 502 error?
Yes. When all application workers are busy, new requests queue past the proxy's timeout or are refused, and the proxy reports 502 or 504. The fix is more capacity, caching so fewer requests reach the application, and moving slow work to background jobs. A CDN caching static and cacheable pages absorbs most spikes before they reach the origin.
