The server acting as a gateway or proxy received an invalid response from the upstream server. The backend server is down, overloaded, or returning malformed responses.
🛡️ Security Implications
Repeated 502 errors may indicate a DDoS attack overwhelming the backend. Monitor backend health and implement circuit breakers.
🔍 Common Causes
Backend server crashed, PHP-FPM process died, upstream timeout, firewall blocking backend, DNS resolution failure, or backend overloaded.
🔧 How to Fix
Check backend server status. Restart PHP-FPM/application server. Increase proxy timeout values. Check backend firewall rules. Monitor backend memory and CPU.
HTTP 502 in depth — what you actually need to know
HTTP 502 Bad Gateway indicates that a server acting as a gateway or proxy received an invalid response from the upstream server. The proxy itself is working, but the backend it tried to reach failed in some way — returned malformed response, closed connection unexpectedly, or did not respond at all (timeout typically returns 504 instead). Modern web architectures with load balancers, CDNs, reverse proxies, and microservices produce 502 errors as one indicator of upstream issues.
Common 502 causes: backend application crashed (returned partial response then died), backend not running at all (proxy connects but no application listens on the upstream port), backend overloaded (response taking too long, proxy gave up), backend returned malformed response (partial HTTP, broken headers), network issues between proxy and backend (intermittent connectivity, MTU mismatches), SSL/TLS issues (certificate problems, protocol mismatches between proxy and backend).
In Cloudflare-fronted sites, 502 is often Cloudflare's indication that it could not reach your origin server. Status sources for diagnosis: your origin server logs (check whether requests reached origin), proxy logs (check whether proxy received any response), application monitoring (check whether application is healthy), infrastructure monitoring (check whether backend service is running).
Five real-world scenarios involving HTTP 502
CDN-fronted site with origin issues
Cloudflare/Akamai/Fastly returns 502 when origin server is unreachable or returning broken responses. Standard diagnosis: check origin health from CDN edge perspective, check origin server logs for connection issues, check whether origin SSL certificate is valid (CDN cannot verify cert = 502).
Microservices architecture — upstream service failure
API gateway or service mesh returns 502 when one microservice fails to respond properly. Service-mesh observability tools (Istio, Linkerd) help correlate which specific upstream produced the failure, what the response looked like, why the proxy classified it as bad.
Reverse proxy debugging — proxy_pass to broken backend
Nginx proxy_pass to a backend that crashed or is not running produces 502. Check Nginx error logs for specific reason: "no live upstreams", "upstream prematurely closed connection", "could not connect", etc. Each suggests different backend issues.
Load balancer health-check failures cascading to 502s
Load balancers mark backends unhealthy when health checks fail; if all backends are unhealthy, return 502 (or 503 depending on config). Monitor health-check pass rates separately from request error rates to catch cascading failures.
External pentest reconnaissance: 502 responses sometimes reveal information about backend architecture (which versions of which services). Cloudflare 502 page differs from Nginx 502 page differs from AWS ALB 502 page. Combined with server header analysis, helps map target infrastructure.
Common mistakes & edge cases
Treating all 5xx errors as the same
500 vs 502 vs 503 vs 504 indicate different failure modes with different debugging approaches. Generic "5xx error rate" monitoring loses diagnostic information. Track each separately.
Not setting timeout values appropriately
Default proxy timeouts (often 30s) may be too short for slow backends or too long for monitoring purposes. Configure timeouts based on actual application behaviour and SLA requirements. Match upstream and proxy timeouts to avoid cascading 502/504.
No upstream health checks
Proxies without health checks send requests to dead backends, producing 502 errors that affect users. Configure health checks to detect failed backends; remove unhealthy backends from rotation automatically.
SSL certificate issues between proxy and backend
Many 502 errors come from SSL handshake failures: expired backend certs, hostname mismatches, missing intermediate certs. CDN-to-origin SSL is a particularly common gotcha. Use proper certificates on backends; verify periodically.
Connection pool exhaustion causing 502s
Proxies with too few backend connections (connection pool size too small) queue requests, leading to timeouts and 502s under load. Tune connection pool size based on actual concurrency requirements.
Not monitoring 502 spikes
502 spikes indicate backend issues that affect user experience. Monitor 502 rate; alert on spikes. Sudden 502 increase usually correlates with backend deployments, infrastructure changes, or upstream service incidents.
Frequently Asked Questions about HTTP 502
A server acting as gateway or proxy received an invalid response from the upstream server. The proxy is working; the backend it tried to reach failed in some way (returned malformed response, closed connection, network issue).
502 = upstream returned bad response. 503 = service unavailable (upstream explicitly indicated unavailable, or no healthy upstream available). 504 = gateway timeout (upstream did not respond within timeout window). Each indicates different backend issues with different debugging approaches.
Cloudflare cannot get a valid response from your origin server. Common causes: origin SSL certificate issues, origin server down, origin firewall blocking Cloudflare IPs, origin returning malformed HTTP, origin connection limits exhausted. Check origin status first.
Check Nginx error log (typically /var/log/nginx/error.log). Specific error messages indicate cause: "no live upstreams" (all backends marked dead), "upstream prematurely closed connection" (backend crashed or restarted), "could not connect" (backend not listening on expected port). Each suggests different fixes.
CDNs typically do not cache 502 responses (or cache for very short duration). The error condition is expected to be transient; caching it would prolong user impact unnecessarily. Some CDNs have configurable error caching.
Application crashes (process died, returned partial response then exited), application not running (port not listening), application overloaded (slow response, proxy timed out — though this is usually 504), SSL handshake failures, network connectivity issues, malformed HTTP responses.
Implement upstream health checks (proxies should detect and route around failed backends). Run multiple backend instances (one failure does not affect users). Monitor application health. Set appropriate timeouts. Validate SSL certificates regularly. Have rollback procedures for deployments that cause backend issues.
Indirectly. 502 indicates backend issues; if backend issues are caused by attacks (DDoS, exploitation attempts crashing the application), 502 is a symptom. Pattern of 502s correlated with specific source IPs or request patterns may indicate attack — investigate.
Sometimes — depends on whether the error is transient. For idempotent requests (GET), retry with exponential backoff is reasonable. For non-idempotent (POST that modifies state), retrying may cause duplicate operations — consider idempotency tokens or careful retry logic.
Sustained 502s affect SEO — search engines crawling your site cannot index content, may eventually de-index URLs that consistently 502. Brief 502s during incidents have minimal impact; persistent 502s damage rankings.