HTTP status code reference

The server has received the request headers and the client should proceed to send the body. Used with an Expect: 100-continue header so a large upload is not sent to a server that would reject it.

Behind a CDN: Usually handled hop by hop and not forwarded. A proxy that mishandles Expect: 100-continue is a classic cause of large uploads stalling for exactly the client timeout.

The server is switching to the protocol the client asked for in Upgrade — in practice almost always WebSockets.

Behind a CDN: A CDN must be explicitly configured to allow the upgrade, otherwise the connection is terminated at the edge and the WebSocket never establishes. Upgraded connections are proxied, never cached.

An informational response sent before the final one, carrying Link headers so the browser can start preloading critical assets while the origin is still assembling the real response.

Behind a CDN: One of the few genuinely free performance wins available at the edge: a CDN can emit 103 from cache while the origin thinks, converting origin latency into useful preload time.

The request succeeded and the body carries the requested resource.

Behind a CDN: The response a cache most wants to store. Whether it actually does depends entirely on Cache-Control, Vary, and whether a Set-Cookie is attached.

The request succeeded and created a new resource, whose location is given in the Location header.

Behind a CDN: Not cacheable in practice — it answers a write, and writes are not idempotent. CDNs pass it straight through.

The request was accepted for processing but has not completed. Common for transcoding jobs and other long-running work.

Behind a CDN: Frequently seen from video-encoding APIs. Never cache it: the whole point is that the state it describes is about to change.

The request succeeded and there is deliberately no body to return.

Behind a CDN: Heuristically cacheable, which surprises people using 204 for analytics beacons — a shared cache may absorb repeat beacons unless you send Cache-Control: no-store.

The response carries only the byte range the client asked for via a Range header.

Behind a CDN: The backbone of video delivery: a player seeking through an MP4 or fetching HLS segments generates a stream of range requests. A CDN that cannot cache ranges independently will re-fetch the whole object from origin for every seek.

The resource has a new permanent URL, given in Location. Clients and search engines should update their references.

Behind a CDN: Heuristically cacheable, and browsers cache it aggressively and for a long time. A 301 issued by mistake is genuinely hard to recall — use 302 while you are still deciding.

The resource is temporarily at a different URL. The original URL should keep being used for future requests.

Behind a CDN: Not cached by default, which makes it the safe choice for redirects you may want to change. Long redirect chains at the edge are a common and easily fixed source of added latency.

The response to the request can be found elsewhere and should be retrieved with GET, regardless of the original method.

Behind a CDN: The correct code for the redirect after a form POST. Passed through by caches.

The client’s cached copy is still valid, so no body is sent. Produced when an If-None-Match or If-Modified-Since request matches.

Behind a CDN: The payoff for having an ETag. An expired cache entry costs a few hundred bytes of headers instead of the entire object — which on a large asset is the difference between a revalidation and a re-download.

Like 302, but the client is explicitly forbidden from changing the request method when following it.

Behind a CDN: Preferred over 302 when a POST must stay a POST across the redirect. Also the code used by HSTS preloading.

Like 301, but the method is guaranteed to be preserved.

Behind a CDN: Heuristically cacheable and equally sticky in browsers. The right code for a permanent move of an endpoint that accepts POST.

The server cannot process the request because it is malformed — bad syntax, an invalid header, or a body the server cannot parse.

Behind a CDN: Often generated by the edge rather than your origin, for oversized headers or a malformed request line. If your origin logs show no matching request, the CDN rejected it first.

Authentication is required and has either not been provided or has failed. The response must include a WWW-Authenticate header.

Behind a CDN: Never cache without care: a cached 401 locks out users who are correctly authenticated. Responses to requests carrying an Authorization header are excluded from shared caches by default for exactly this reason.

The server understood the request and refuses to fulfil it. Unlike 401, authenticating will not help.

Behind a CDN: The most ambiguous code to debug behind a CDN, because either layer can produce it: a WAF rule, a hotlink-protection rule, an expired signed URL, or an origin ACL. Identifying which layer answered is the whole diagnostic problem.

The server has no resource at that URL and will not say whether it ever did.

Behind a CDN: Heuristically cacheable — a fact that surprises almost everyone. A CDN may cache your 404s, so a resource that appears shortly after someone requests it can stay "missing" at the edge until that entry expires or is purged.

The method is understood but not permitted for this resource. The response must list what is allowed in an Allow header.

Behind a CDN: Heuristically cacheable. Commonly produced by a CDN configured for static delivery when it receives a POST it was never set up to forward.

The server cannot produce a response matching the client’s Accept headers.

Behind a CDN: Rare in practice — most servers ignore unsatisfiable Accept headers and send their best guess instead. When it does appear behind a CDN it usually points at content negotiation misconfigured alongside Vary.

The server closed an idle connection because the client did not complete its request in time.

Behind a CDN: Frequently the edge timing out a slow client rather than your origin timing out. On uploads it usually means the client’s connection could not deliver the body within the edge’s receive window.

The request conflicts with the current state of the resource — typically a concurrent-edit collision.

Behind a CDN: Passed through. Common from object-storage APIs on concurrent writes to the same key.

The resource is permanently gone and no forwarding address is known. Stronger and more deliberate than 404.

Behind a CDN: Heuristically cacheable, and search engines de-index a 410 faster than a 404. Use it when you actually mean "never coming back".

A conditional header such as If-Match or If-Unmodified-Since evaluated false, so the request was not performed.

Behind a CDN: The mechanism behind safe concurrent writes: send If-Match with the ETag you read, and a 412 tells you someone else changed it first.

The request body exceeds the limit the server is willing to accept. Formerly "Payload Too Large".

Behind a CDN: Very often an edge limit rather than an origin one, and edge upload caps are usually lower than people expect. Large media uploads normally need a direct-to-storage path that bypasses the proxy entirely.

The request URI is longer than the server is willing to interpret.

Behind a CDN: Heuristically cacheable. Usually a runaway query string, or a GET that should have been a POST.

The body is in a format the server does not support for this resource.

Behind a CDN: Passed through. Common on APIs when the Content-Type header is missing rather than wrong.

The requested byte range lies outside the size of the resource.

Behind a CDN: Shows up in video delivery when a player’s range request is served against a cached object of a different length — typically after the asset was replaced without a purge.

The request reached a server that is not configured to produce a response for that authority.

Behind a CDN: A connection-coalescing artefact: HTTP/2 lets a browser reuse one connection for several hostnames covered by the same certificate, and 421 is how a server says "not this one, open a new connection".

The syntax is valid but the content is semantically wrong — the classic validation-failure code for JSON APIs.

Behind a CDN: Passed straight through. Nothing edge-specific.

The server is unwilling to process a request sent in TLS early data, because replaying it would be unsafe.

Behind a CDN: Only appears where 0-RTT resumption is enabled. Non-idempotent requests should not be sent in early data at all.

The server refuses to serve this request over the current protocol and names the required one in Upgrade.

Behind a CDN: Occasionally used to force TLS, though a 301 to the https:// URL plus HSTS is the conventional path.

The server requires the request to be conditional, to prevent a lost update from a blind overwrite.

Behind a CDN: Pairs with 412. Rare, but the correct way for an API to insist that clients send If-Match.

The client has sent too many requests in a given period. Should carry a Retry-After header.

Behind a CDN: Usually generated by edge rate limiting, so your origin may have no record of it. A 429 on cacheable content generally means the rate limiter is counting requests that should have been absorbed by the cache.

The request’s headers are collectively or individually too large to process.

Behind a CDN: Nearly always cookies. Accumulated tracking cookies on a long-lived domain routinely push requests past an 8 KB edge header limit.

Access is denied as a consequence of a legal demand, such as a court order or a geographic restriction.

Behind a CDN: Where geo-blocking is implemented at the edge, this is the honest code for it — more accurate than a generic 403.

The client disconnected before the server produced a response. Not part of the HTTP standard — an nginx logging convention.

Behind a CDN: Almost never a server fault: the user navigated away, the app was backgrounded, or the mobile connection dropped. A rising 499 rate on video is a strong signal of slow startup time, because viewers are abandoning before the first segment arrives.

A generic catch-all: the server hit an unexpected condition and has nothing more specific to say.

Behind a CDN: If your origin is healthy and you still see 500s, check edge compute — a worker or edge function throwing an exception produces a 500 that never reaches your application.

The server does not support the functionality required to fulfil the request — usually an unrecognised method.

Behind a CDN: Heuristically cacheable, and one of the very few 5xx codes that is.

A server acting as a gateway received an invalid response from the upstream server it was trying to reach.

Behind a CDN: By definition produced by the thing in front of your origin, not by your origin. It means the edge reached your server and could not make sense of the reply — a malformed response, a connection closed mid-response, or a crashed process.

The server is temporarily unable to handle the request, through overload or maintenance. Should carry Retry-After.

Behind a CDN: The correct code for planned maintenance, because it tells search engines not to de-index. Pair it with stale-if-error so the edge keeps serving cached content through the window instead of passing the 503 to visitors.

A gateway did not receive a timely response from the upstream server.

Behind a CDN: Distinguished from 502 by the failure mode: 502 means a bad answer, 504 means no answer in time. The timeout that fired is usually the edge’s, and it is usually shorter than your origin’s — so your application may still be happily processing a request whose client gave up.

The server does not support the HTTP protocol version used in the request.

Behind a CDN: Rare. Modern CDNs terminate HTTP/2 and HTTP/3 at the edge and speak HTTP/1.1 to origins, which hides most version mismatches.

The server cannot store the representation needed to complete the request. Defined by WebDAV.

Behind a CDN: Occasionally surfaced by object-storage backends when a quota is exhausted.

The server detected an infinite loop while processing the request.

Behind a CDN: Behind a CDN, usually a redirect loop between edge and origin — commonly an origin that redirects http to https while the edge is already sending it plain http.

The client must authenticate to gain network access — the captive-portal code.

Behind a CDN: Injected by an intermediary network, not by your infrastructure. Hotel and airport Wi-Fi.

A catch-all for an origin response Cloudflare could not interpret — an empty reply, a connection reset, or headers that violate the spec.

Behind a CDN: Effectively "something about your origin’s response was too broken to classify". Oversized headers and non-standard status lines are the usual causes.

The origin refused the connection outright.

Behind a CDN: Most often the origin firewall dropping the CDN’s IP ranges, rather than the server actually being down. Check that the edge’s published ranges are allowlisted before restarting anything.

The TCP connection to the origin could not be established within the timeout.

Behind a CDN: Different from 524: 522 means the handshake never completed, so the request never reached your application at all. Packet loss, an overloaded origin, or a firewall silently dropping packets rather than refusing them.

The origin could not be routed to at all.

Behind a CDN: Usually DNS: the origin record points at an address that no longer exists, or was deleted while the proxy record remained.

The connection to the origin succeeded but the origin did not send a complete response before the timeout.

Behind a CDN: The signature of a slow endpoint rather than a broken one — a long report, an unindexed query, a synchronous transcode. Moving the work to a job queue that returns 202 is the fix; raising the timeout is the workaround.

The TLS handshake between the edge and the origin failed.

Behind a CDN: Normally a cipher or protocol mismatch, or an origin certificate the edge will not accept in strict mode.

The origin presented a certificate that could not be validated.

Behind a CDN: Expired, self-signed, or covering the wrong hostname. Appears the moment strict origin validation is switched on over a certificate nobody had checked.

Displayed alongside a second, more specific 1xxx error code identifying the underlying problem.

Behind a CDN: The visible 530 is rarely the useful part — read the four-digit code shown on the error page itself.