502 Bad Gateway 5xx

What does 502 mean?

A 502 Bad Gateway response means a server acting as a gateway or proxy — load balancer, reverse proxy, CDN — tried to forward a request to an upstream (origin) server, but received an invalid or malformed response back. The proxy itself is working fine; it's the connection to (or response from) whatever sits behind it that's broken.

This is a fundamentally different situation from 500. A 500 means "the application itself encountered an error while processing the request." A 502 means "the thing in front of the application couldn't even get a sensible response from the application" — the failure is one layer further back in the chain.

How a 502 behaves

• It's generated by the proxy/gateway, not the origin server — if your site is behind Cloudflare, Nginx, or a load balancer, a 502 page you see is often coming from that intermediary, not from your application code directly
• It's not cacheable — represents a transient connectivity/response issue
• The origin server may be completely unaware it returned a "502" — from the origin's perspective, it might have crashed, closed the connection abruptly, or returned something the proxy couldn't parse as a valid HTTP response; the 502 is the proxy's interpretation of that failure
• It often indicates a problem between two specific hops — useful for debugging multi-layer architectures (CDN → load balancer → app server), since the 502 tells you a handoff failed, even if not precisely which one without further investigation

Common causes

If you're building/operating the infrastructure:

• The application server (PHP-FPM, Node process, etc.) crashed or isn't running, so the proxy has nothing valid to forward
• The application server is still starting up (during a deploy) and isn't yet accepting connections
• The connection between the proxy and the application server times out or is refused — wrong port, firewall rule, or the app server is overwhelmed and not accepting new connections
• The upstream server returned a response that's too large, malformed, or violates the proxy's expectations (e.g., invalid headers)
• A misconfigured reverse proxy is pointing at the wrong upstream address entirely

If you're calling an API:

• The API's infrastructure is experiencing an issue between its CDN/load balancer and its application servers — this is on the provider's side, not yours
• You're hitting the API during a deployment, and the new application instances aren't fully up yet while old ones are being drained

If you're a website visitor:

• The site is experiencing a temporary infrastructure issue — often very brief, especially during deploys
• A CDN (Cloudflare, etc.) in front of the site can't reach the origin server at all

How to fix it

As an API/website builder:

• Check whether your application server process is actually running and accepting connections — a crashed PHP-FPM pool or Node process is one of the most common causes
• During deploys, use a process that keeps the old version serving until the new version is confirmed healthy ("blue-green" or rolling deploys) to avoid a window where the proxy has nothing valid to forward to
• Check proxy/reverse-proxy configuration (Nginx upstream blocks, load balancer target groups) for correct addresses and ports
• If using Cloudflare or a similar CDN, check whether the origin server is reachable directly (bypassing the CDN) to isolate whether the issue is the CDN-to-origin connection or the origin itself
• Review timeout settings — if the application takes longer to respond than the proxy's timeout for establishing/maintaining the connection (distinct from 504, which is about waiting for the response), a 502 can result

As an API consumer:

• Treat like a transient infrastructure issue — retry with backoff, similar to 503
• If persistent, check the API provider's status page — 502s affecting all clients usually indicate the provider's infrastructure issue, not something fixable on your end

As a website visitor:

• Refresh after a short wait — 502s during deploys are often resolved within seconds to minutes
• If persistent across multiple page loads and refreshes, the site's infrastructure has an issue that only the site owner can fix

502 vs related codes

Real-world examples

Sites behind Cloudflare frequently display Cloudflare's own styled 502 error page when Cloudflare can't get a valid response from the origin server — this is a very common first signal of an origin-side issue (a crashed app server, a deploy in progress) for sites using Cloudflare as a reverse proxy. In containerized/orchestrated environments (Kubernetes, etc.), 502s during rolling deployments are common when a load balancer briefly routes traffic to a pod that's still starting up and not yet ready to accept connections — readiness probes exist specifically to prevent this.

SEO implications

A 502 is treated similarly to a 500 by search engines — a signal of temporary server-side trouble. Brief, occasional 502s (e.g., during routine deploys) typically have negligible SEO impact. Frequent or sustained 502s, however, can reduce crawl efficiency and, if persistent enough, may lead to temporary removal of pages from the index, similar to prolonged 500/503 situations.

FAQ

What's the difference between 502 and 500?

500 is generated by the application itself when something goes wrong in its own code. 502 is generated by a proxy, load balancer, or CDN sitting in front of the application, indicating it couldn't get a valid response from the application — the failure is one layer removed from the application code itself.

Why am I seeing a 502 from Cloudflare specifically?

Cloudflare acts as a reverse proxy in front of your origin server. A Cloudflare-branded 502 page means Cloudflare successfully received your request but couldn't get a valid response back from your origin server — the issue is between Cloudflare and your server, not within Cloudflare itself.

Is 502 usually a quick, temporary issue?

Often, yes — especially during deploys, when application servers restart, or brief network blips between proxy and origin. If 502s persist for more than a few minutes, it usually points to a more substantial issue (crashed process, misconfiguration) that needs investigation.

How can I tell if a 502 is from my CDN or my actual server?

Try accessing your server directly via its origin IP address or a non-proxied subdomain, bypassing the CDN entirely. If the direct request succeeds, the issue is between the CDN and your origin (configuration, connectivity, or timeouts). If the direct request also fails, the issue is with your application/server itself.

Can 502 happen even if my application code has no bugs?

Yes — 502 is fundamentally about the connection and response handoff between a proxy and an upstream server, not about application logic. Infrastructure issues (crashed processes, network configuration, deploy timing) can cause 502s even in applications with flawless code.

Fun fact

502 is one of the clearest examples of a status code whose meaning depends entirely on where in the request chain it's generated — the same "502 Bad Gateway" text can appear on a page styled by Cloudflare, a load balancer, an Nginx reverse proxy, or a cloud provider's edge network, each representing a different specific hop in a multi-layer infrastructure, which is why diagnosing a 502 often starts with figuring out which layer actually produced it.