HTTP 5xx Server Error Codes and CDN Troubleshooting

An HTTP 5xx response means a server failed to fulfil an apparently valid request. On a CDN-backed service, “the server” may be an edge node, reverse proxy, load balancer, gateway, or origin. The status alone does not identify the failing layer.

5xx code reference

500 Internal Server Error

500 is a general failure when a more specific status is not suitable. Common causes include an unhandled exception, invalid configuration, exhausted memory, failed dependency, or file-permission error.

Log a correlation ID, the failing component, and a safe error category. Do not return a stack trace, credential, internal hostname, or database detail to the client.

501 Not Implemented

Use 501 when the server does not recognise or cannot implement a request method or capability. Use 405 Method Not Allowed when the server knows the method but the target resource does not permit it. Servers are required to support GET and HEAD, so 501 is not appropriate for those methods.

502 Bad Gateway

502 means a proxy or gateway received an invalid response from upstream. Possible causes include:

• the origin closed the connection before completing the response;
• TLS negotiation or certificate validation failed between the CDN and origin;
• the upstream response was malformed;
• DNS resolved the origin incorrectly;
• a load balancer selected an unhealthy target.

A 502 generated by the CDN is different from a 502 generated by the origin application. Response headers, request IDs, and provider logs usually identify the layer.

503 Service Unavailable

Use 503 for temporary overload, maintenance, or loss of capacity. Include Retry-After when the server can estimate when a retry is useful.

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Cache-Control: no-store

For planned maintenance, keep the response body small and useful. Do not return 200 OK for an error page: monitoring and clients need the real service status.

504 Gateway Timeout

504 means a gateway did not receive an upstream response before its timeout. Unlike 502, the gateway did not receive a timely usable response at all.

Check origin latency, connection-pool exhaustion, upstream DNS, firewall rules, keepalive settings, and timeout mismatches. Increasing every timeout can move the bottleneck and increase queued work; identify which operation is slow first.

505 HTTP Version Not Supported

Use 505 when the server refuses the HTTP major version used in the request. Protocol negotiation failures at TLS or HTTP/2 framing level do not always produce an HTTP response, so many version problems appear in connection logs instead.

506 Variant Also Negotiates

506 indicates a content-negotiation configuration in which the selected variant itself tries to negotiate, creating a loop. It is rare outside systems implementing transparent content negotiation.

507 Insufficient Storage

507 originated in WebDAV and means the server cannot store the representation needed to complete the request. It can reflect quota exhaustion or unavailable storage, but it is not a generic substitute for every disk problem.

508 Loop Detected

508 means the server ended an operation because it encountered an infinite loop. It is defined for WebDAV. A CDN redirect loop normally appears as repeated 3xx responses, not 508.

510 Not Extended

510 indicates that the request needs further extensions. It is rarely used and clients should not assume support without specific protocol documentation.

511 Network Authentication Required

511 is for an intercepting network, such as a captive portal, that requires authentication. It is not an origin-server authentication response; use 401 or 407 for HTTP authentication cases.

Diagnose a 5xx response behind a CDN

Use a layer-by-layer check:

1. Record the URL, method, status, timestamp, request or trace ID, edge location, cache status, and a small response sample.
2. Check whether all users, one region, one hostname, or one route is affected.
3. Compare the CDN path with an authorised direct-origin request that preserves the Host header and TLS name.
4. Inspect CDN edge logs, load-balancer logs, and origin application logs for the same request ID and time.
5. Check recent deployments, certificate changes, DNS changes, connection limits, queues, and dependency health.
6. Confirm recovery from more than one region and with both cached and uncached requests.

Do not bypass origin protections or expose a private origin during diagnosis. Direct-origin tests should come from authorised monitoring locations.

Retries, failover, and stale content

Retries can turn a small failure into an outage. Retry only when the operation is safe to repeat, cap the number of attempts, use exponential backoff with jitter, and keep a total time budget.

GET, HEAD, PUT, and DELETE are defined as idempotent, but an application can still implement them incorrectly. POST is not inherently idempotent. Use idempotency keys when a duplicate action would be harmful.

The stale-if-error Cache-Control extension can allow a cache to reuse a stale response when a fresh request would return 500, 502, 503, or 504. This can improve availability for cacheable content, but it must not serve private, unsafe, or unacceptably old data.

Origin failover also needs an explicit policy. Confirm which failures trigger failover, whether both origins share the same content and credentials, how recovery avoids flapping, and what happens to non-idempotent requests.

Monitoring

Track the status code and the component that emitted it. A single “5xx rate” can hide the difference between application exceptions, bad upstream responses, capacity loss, and timeouts.

Useful dimensions include hostname, route, method, edge region, origin, deployment version, cache status, and upstream response time. Alert on user impact and error-budget burn rather than one isolated response.

Sources and related reading

• RFC 9110: 5xx server errors
• RFC 9111: HTTP caching
• RFC 5861: stale-if-error
• HTTP 4xx client errors
• Cache-Control guide
• Purging CDN content
• Multi-CDN origin architecture
• Choosing an HTTP status code