HTTP 502 Bad Gateway
HTTP 502 Bad Gateway means your proxy or load balancer reached the upstream server but got back something it could not understand — or the upstream did not respond at all. From a user perspective, the site is down. From an operations perspective, the proxy is running fine; the application server behind it is the problem.
The most common production scenario: you deploy a new version of your application, a bug causes the process to crash on startup, and within seconds users start seeing 502. Nginx or Cloudflare is still running, but it has nobody to proxy to. Another common scenario: the application returned a response without required HTTP headers, and the proxy rejected it.
The key distinction from 504: 502 means the upstream sent something bad. 504 means the upstream said nothing within the timeout window.
Quick reference
| Code | 502 |
|---|---|
| Name | Bad Gateway |
| Category | 5xx server errors |
| Specification | RFC 9110 |
| IANA status | Assigned |
| When to use | Proxies and gateways emit 502 automatically. As an application developer, your responsibility is ensuring the upstream service is running, returning valid HTTP responses, and reachable from the proxy. |
| Client behavior | May retry — the upstream may recover. Implement exponential backoff. After repeated 502s, escalate to alert the operations team. |
| Caching | Not cached. |
Common causes
- Application server crashed or is unreachable
- Upstream service returned a malformed response
- Network issue between proxy and origin
- Deployment in progress causing temporary upstream unavailability
How to fix it
- Check the application server process — is it running?
- Review proxy error logs for the specific upstream failure
- Verify network connectivity between proxy and origin
- Check for recent deployments that may have broken the origin
Example exchange
GET /example HTTP/1.1 Host: errorlookup.com HTTP/1.1 502 Bad Gateway
When you see this in production
502 triage in production:
1. Check if the application server process is running (systemctl status, docker ps, k8s pod status)
2. Check application server logs for crash or startup errors
3. Verify the proxy's upstream configuration (correct host:port, correct protocol)
4. Check network connectivity between proxy and upstream (firewall rules, security groups)
5. Look for upstream-specific errors in proxy logs (Nginx error.log, ALB access logs)
6. Check for recent deployments — 502 spikes correlate strongly with bad deploys
What developers usually do next
- Diagnosing 502:
- 1. Check Nginx/proxy error logs for the specific upstream error message
- 2. Verify the upstream application server process is running and listening on the correct port
- 3. curl directly to the upstream (bypassing the proxy) to verify the response is valid HTTP
- 4. Check application server startup logs for fatal errors
- 5. Verify the upstream returns HTTP/1.1 (not HTTP/1.0) if required by your proxy config
- 6. Rollback the last deployment if the 502 appeared immediately after a deploy
When NOT to use this code
Do not confuse 502 with 504 (timeout) or 500 (application-level error). 502 specifically means the proxy got an invalid/no response from upstream. Do not try to return 502 from your application code — it is a proxy/gateway response.
Related status codes
HTTP 503 Service Unavailable · HTTP 504 Gateway Timeout · HTTP 500 Internal Server Error
Behind Cloudflare or Nginx?
When a proxy layer sits in front of your origin, 502 may surface as a vendor-specific code. Common proxy-chain variants:
Comparisons
Frequently asked questions
What is the difference between 502 and 504?
502 means the gateway received an invalid or bad response from upstream. 504 means the gateway timed out waiting for a response. Both indicate upstream problems, but 504 is specifically about timeout.
Standards reference
This definition is derived from the IANA HTTP Status Code Registry and RFC 9110. Human-readable operational guidance by ErrorLookup. · HTTP 502 quick reference →