HTTP Status Code Explorer — All 70+ Codes With Meaning, Causes and Troubleshooting

The initial part of the request was received and the client should continue sending the body. Used with the Expect: 100-continue header before uploading a big body.

• Client sent `Expect: 100-continue` before a large PUT/POST body.
• curl --expect100-timeout kicked in.
• gRPC/HTTP2 client probing the server.

• Uploading a 2GB file via PUT and watching the proxy log.
• API client logs show 100 right before the real 201.

• No action needed — 100 is informational, the real response follows.
• If client hangs after 100, check upload body parsing on the server.
• Disable Expect header with `curl -H "Expect:"` if proxy mangles it.

The server agrees to switch protocols as the client requested in the Upgrade header. Most commonly seen for WebSocket handshakes.

• WebSocket handshake — client sent Upgrade: websocket and server accepts.
• HTTP/2 over cleartext upgrade.
• Custom protocol negotiated via Upgrade header.

• Real-time chat opening a WS connection — DevTools shows 101 then "pending".
• Live dashboard subscribing to server-pushed events.

• WS hangs after 101? Check `proxy_read_timeout` (nginx default 60s kills idle WS).
• Make sure nginx forwards `Upgrade` + `Connection: upgrade` headers and `proxy_http_version 1.1`.
• CloudFlare / ALB in front? Their own idle timeouts also cut the TCP.

WebDAV interim response — the server has accepted the request but processing is not complete. Tells the client not to time out.

• WebDAV PROPFIND / COPY / MOVE on a large hierarchy.
• Long-running batch operation keeping the connection alive.

• Copying a 50k-file WebDAV folder.
• Nextcloud / SabreDAV server signalling progress.

• Not an error — wait for the real response.
• Increase client/proxy read timeout for big WebDAV ops.

Server preloads hints (usually Link: rel=preload) to the browser before the final response is ready. Speeds up render by warming CDN/font/JS fetches.

• Server sent `Link: </app.css>; rel=preload` before the HTML body finished rendering.
• CDN with 103 support (Fastly, Cloudflare) forwarding preload hints.
• Origin uses Express `res.writeEarlyHints()` or Node 18+ early hints API.

• SSR app warming font + critical CSS while DB query is still running.
• Documentation site preloading hero image before HTML is built.

• 103 alone never breaks anything — if hints are ignored, check that the proxy in front actually forwards them.
• Chrome supports it; some older proxies strip 1xx responses entirely.
• Verify with `curl -v --http2` and look for two response sets.

The classic success. Request worked and the body contains what was asked for. GET returns the resource, POST returns the result of the action.

• GET /api/users — resource exists and was returned.
• POST /login — successful auth, body has the session token.
• Health check passing.

• Page loads, data renders, user happy.
• Cron job hits /healthz every minute and gets 200.

• If the body is wrong but status is 200 — your handler returned success when it should have returned 4xx/5xx. Audit the error path.
• 200 with empty body on a POST that should create — confirm whether 201 fits better.

A new resource was created as a result of the request. The Location header should point to it. Right answer for successful POST that creates.

• POST /api/users — new user row inserted, returning the created object.
• PUT /api/files/foo.png — file uploaded to a new path.
• Idempotent PUT creating a fresh resource.

• Sign-up form submit returns 201 + the new account JSON.
• CI uploading a build artifact gets 201 with artifact URL.

• Always return the Location header — frontends and integration tools depend on it.
• If the same POST creates the same resource twice, use 409 the second time OR make the endpoint idempotent.

The request was accepted for processing but is not done yet. Use for async jobs — return a job ID so the client can poll.

• POST /api/export — long export queued, server returns 202 + job_id.
• Webhook handler that pushes to a queue and returns immediately.
• AI image generation — model run is queued.

• Click "Export 100k rows" → 202 → frontend polls /jobs/:id every 2s.
• Stripe webhook returns 202 to avoid blocking the upstream.

• Always return a way to find the job: Location header or job_id in body.
• If the client never sees the job finish, audit the worker — 202 only promises "accepted", not "will succeed".

Request succeeded but the returned payload was modified from the origin by a transforming proxy (e.g. content rewriter).

• Transforming proxy rewriting response (legacy mobile carriers).
• CDN edge rewriting HTML for optimisation.

• Carrier proxy injecting compression hints.
• Edge worker stripping comments from HTML.

• Verify the response matches what your origin sent — bypass the proxy with a direct curl.
• If the proxy is breaking your app, disable transformation or use HTTPS end-to-end.

Success, but no body to return. Perfect for DELETE and for PUT that just updates without echoing the resource back.

• DELETE /api/users/123 — row gone, nothing to say.
• PUT /api/settings — saved, no need to echo.
• OPTIONS preflight response (CORS).

• Settings page save returns 204 — frontend just shows "Saved".
• Browser CORS preflight gets 204 from the API.

• Do NOT send a body with 204 — some HTTP clients and proxies will choke.
• If a fetch returns 204, `await res.json()` will throw. Check `res.status === 204` first.

Tells the client to reset the document view that caused the request — usually clear a form so the user can enter another entry.

• Bulk-entry form server tells the client "submitted, reset for the next one".
• Kiosk / data-entry app workflow.

• Warehouse barcode entry — submit and clear instantly.

• Like 204, the response body MUST be empty.
• On the client, react by calling `form.reset()`.

Server returned only part of the resource as requested via Range header. Used for resumable downloads, video seek, byte-serving PDFs.

• Video player seeking past the buffered range — sends Range: bytes=1048576-.
• Download resumed after pause.
• PDF.js fetching pages on demand.

• MP4 streaming via <video> with seek bar.
• Resume large download via curl -C -.

• Always include `Content-Range: bytes start-end/total` and `Accept-Ranges: bytes`.
• If nginx serves static and you see 200 instead of 206 on Range request — make sure no upstream gzip is stripping Range (nginx does this for gzipped responses by default).

WebDAV — the response body is XML containing multiple status codes, one per sub-resource. Useful when one request touches many resources.

• WebDAV PROPFIND on a collection with mixed-permission children.
• Batch COPY where some destinations fail.

• Nextcloud listing a folder where some files are locked.
• CalDAV bulk update with partial failures.

• Parse the XML body — each <response> has its own <status>.
• Do not treat 207 as "all good" — drill into the per-resource statuses.

WebDAV — members of a DAV binding have already been enumerated in a preceding part of the (multi-status) response and are not being included again.

• Recursive PROPFIND on overlapping collections.

• Large WebDAV listing with cross-references.

• No action required — the client already saw these members earlier in the response.

HTTP Delta encoding — the response is the result of applying one or more instance manipulations (e.g. delta) to the current instance. Very rare in the wild.

• Delta-encoded responses (RFC 3229) to save bandwidth on incremental updates.

• Bandwidth-constrained syndication feeds in the early 2000s.

• Almost never needed today — gzip + ETag/If-None-Match solves the same problem better.

Resource has multiple representations and the server cannot pick one. Client should choose. Rarely used because automatic content negotiation handles most cases.

• Resource available in multiple languages/formats without a clear best match.

• Manual content negotiation in some academic / standards-driven sites.

• Body usually lists the alternatives. Re-request with a more specific Accept header.

The resource has permanently moved to the URL in the Location header. Browsers and search engines cache this aggressively — get it wrong and you bake a bad URL into the world.

• Site moved from http://example.com to https://example.com.
• Old URL structure replaced (/blog/123 → /posts/123).
• Domain change after rebrand.

• HTTPS migration with `return 301 https://$host$request_uri;`.
• SEO: old article URL points to the canonical new one.

• Stuck in a 301 loop? Clear browser cache + check that the target URL does NOT 301 back.
• Use 302 first to test — only switch to 301 once the new URL is stable for a week.
• POST 301-ed becomes GET in older clients — that may lose form data. Use 308 if you must preserve method+body.

Temporary redirect to the Location URL. Clients keep using the original URL next time. Safe for A/B routing or temporary maintenance.

• Login redirect — after auth, jump back to ?next=… .
• Country-based routing to a local mirror.
• Form POST → GET (POST/Redirect/GET pattern).

• Old framework defaults `redirect()` to 302 for safety.
• A/B test routes 50% of users to /new/.

• 302 method-change behaviour is technically undefined; in practice browsers turn POST into GET. Use 303 for explicit POST→GET, 307 to preserve.
• For HTTPS migration use 301 (or 308), not 302 — 302 will never get baked into HSTS/SEO.

Redirect AND change method to GET. The right code for the POST/Redirect/GET pattern after a form submit.

• POST /orders → 303 Location: /orders/123 — browser does GET on the new URL.
• API returns 303 to point to a freshly created resource.

• Server-rendered checkout: submit cart → 303 → render order page.
• Avoid double-submit on refresh after POST.

• If the browser stays on the POST URL after 303, you sent the wrong status — confirm it is 303 not 200.
• Some old HTTP/1.0 clients turn 303 into 302; for them, set both Location and Cache-Control: no-cache.

Conditional GET — the resource has not changed since the client cached it. No body returned; client reuses its cache.

• Client sent `If-None-Match: "etag"` and ETag still matches.
• Client sent `If-Modified-Since: <date>` and resource is older.
• CDN revalidating with the origin.

• Browser refresh on a static asset — DevTools shows 304 with 0 bytes transferred.
• CDN cache check before serving stale.

• 304 body MUST be empty — sending a body breaks caching layers.
• Always echo the same ETag header back on 304.
• If the client never sees 304, check that the server actually compares If-None-Match.

Deprecated. Originally told the client to access the resource via a specific proxy. Browsers ignore it because of security concerns.

• Legacy server using deprecated semantics.

• Almost never seen today; modern browsers ignore.

• Do NOT use 305 in new code. Configure clients to use a proxy explicitly via HTTP_PROXY env.

Reserved status code. No longer used — the original proposal was abandoned. You should never see this in the wild.

• Legacy server returning an obsolete code by mistake.

• Almost never seen.

• Do not implement. Pick another 3xx code that fits the actual intent.

Like 302 but the method and body MUST be preserved. POST stays POST after the redirect, body comes along.

• API moved temporarily but accepts POST with the same payload at the new URL.
• Maintenance switch routing all traffic to a sibling region without changing method.

• Region failover where POSTs must reach the alt endpoint.
• Webhook receiver moved temporarily.

• Some HTTP libraries strip the body on redirect — verify with a wire dump.
• Use 308 instead if you mean "permanent + preserve method".

Like 301 but method and body MUST be preserved. Modern replacement for 301 when you need to keep POST as POST permanently.

• Permanent API endpoint rename where POST clients should not silently turn into GET.
• Upload endpoint moved permanently.

• API v1 → v2 path migration that needs to keep PUT semantics.
• Permanent move of a multipart upload endpoint.

• Older curl/clients may not honour 308 — verify your callers support it before flipping.
• For pure URL canonicalisation (no body), 301 is still fine.

The server could not parse or accept the request because it is malformed. Catch-all for "your client sent garbage".

• JSON body has a syntax error (trailing comma, wrong quotes).
• Required field missing in the payload.
• Query string parameter has wrong type ("limit=abc").
• Header line longer than the server limit.

• Frontend forgot to `JSON.stringify(body)` before fetch().
• API caller hand-crafted a curl with one missing brace.

• Read the response body — most APIs return a JSON `error` field explaining exactly what failed.
• Reproduce with `curl -v` and check Content-Type matches what you sent.
• If hitting only some clients, suspect intermediate proxies rewriting headers.

Despite the misleading name, this is "unauthenticated" — no valid credentials. Server returned WWW-Authenticate telling you how to log in.

• No Authorization header sent.
• Bearer token expired.
• API key invalid or revoked.
• Cookie session expired or was cleared.

• User leaves a tab open for 24h, comes back, every API call 401s.
• CI calling our API after the deploy key rotated.

• Refresh the token / re-login, retry the request.
• Check the WWW-Authenticate header — it tells you the expected scheme (Bearer, Basic, Digest).
• If 401 only after some time, check token expiry and refresh-token flow.
• On the server: distinguish 401 (no/bad creds) from 403 (creds OK but no permission).

Originally reserved for future use. Today some SaaS APIs return it when the account is unpaid, over quota, or trial expired.

• API account hit monthly free tier limit.
• Subscription lapsed.
• Pay-per-request balance went to zero.

• Stripe-style: every request 402 until card updated.
• AI API: prepaid credits depleted.

• Read the response body for the billing portal URL.
• Add a card / top up credits, retry.
• If your own API uses 402, document the meaning clearly — clients do not expect it.

The server understood the request and knows who you are — but you are not allowed to do this. Different from 401 (which says "log in first").

• Logged-in user trying to access another user's resource.
• IP / region blocked.
• WAF rule (Cloudflare, AWS WAF) tripped.
• File permission on disk — nginx `permission denied` in error log.
• CSRF token missing on a state-changing request.

• Standard user clicks an admin-only link.
• Cloudflare blocks suspicious traffic with a colourful 403 page.
• Static site nginx returns 403 because the file is `chmod 600`.

• Check who you are vs what you are accessing — auth working, permission missing.
• For nginx: `sudo tail -f /var/log/nginx/error.log` will say "Permission denied" or "directory index forbidden". Fix chmod / chown or add the file.
• WAF false-positive? Add an allow rule by URI or IP.
• CSRF? Re-send with a fresh CSRF token from the page.

The classic. Server cannot find anything matching the URL. May mean the resource never existed, was deleted, or your client built the wrong URL.

• Typo in the URL path.
• Resource was deleted.
• Frontend hard-coded an old API path.
• SPA hits the server on refresh with a route the server does not know (missing try_files / catch-all).
• Reverse proxy `location` block does not match.

• User refreshes /dashboard on an SPA without proper rewrite — 404 instead of the app.
• API client still hitting /v1/ after /v2/ launched.
• Article URL changed but old link still floats around the web.

• Confirm the URL — `curl -v` the exact bytes the client sends.
• For SPA: nginx `try_files $uri $uri/ /index.html;` or framework router catch-all.
• For removed resources: serve a custom 404 page with helpful links instead of the default white screen.
• Add a 301 from the old URL to the new one to recover SEO.

The URL exists but the HTTP method you used is not supported. Server should return an Allow header listing what works.

• POST to an endpoint that only accepts GET.
• DELETE on a read-only resource.
• Frontend uses the wrong method after a refactor.
• CORS preflight (OPTIONS) hits a route that handles GET only.

• Renamed handler accidentally dropped the POST branch.
• Newman / Postman test using DELETE on a list endpoint.

• Read the Allow header in the response — it lists supported methods.
• Add the missing method handler OR fix the client to use the supported one.
• For CORS: handle OPTIONS explicitly with a 204.

Server cannot produce a response in any of the formats requested by the client's Accept header.

• Client sent `Accept: application/xml` but API only returns JSON.
• Browser request with restrictive Accept-Language and no fallback.

• Legacy SOAP client demanding XML from a REST-only API.
• Strict content negotiation in a microservice.

• Fix the client Accept header to a supported type.
• Or relax the server: fall back to `application/json` when negotiation fails.

Client took too long to send the complete request. Different from 504 — 408 is the CLIENT being slow, 504 is the upstream being slow.

• Slow upload over flaky network.
• Idle keep-alive connection getting closed by the server.
• Slowloris-style attack triggering server defence.

• Mobile user on bad signal uploading a photo.
• Server-side request body timeout triggered.

• Retry the request — usually transient.
• Bump client-side timeout if uploading large bodies.
• For servers: tune `client_body_timeout` and `client_header_timeout` (nginx).

The request conflicts with the current state of the resource. Classic for "creating something that already exists" or "concurrent edit".

• Trying to register a username that is already taken.
• Optimistic concurrency check failed (If-Match ETag mismatch).
• Git push rejected — non-fast-forward.
• Idempotent POST detected the resource already exists.

• Two users editing the same wiki page, second save 409s.
• Sign-up form on a popular email getting 409.

• Show the user what conflicts and offer "overwrite" / "merge" / "pick a different name".
• For ETag conflicts: re-fetch, re-apply changes, retry.
• Add idempotency keys to make retries safe.

The resource is permanently gone and there is NO forwarding address. Stronger than 404 — tells search engines and clients to forget the URL.

• User deleted their account.
• Sunset API endpoint after migration grace period.
• GDPR removal request.

• Old API path returns 410 after v2 has been stable for months.
• Deleted user profile page.

• Use 410 instead of 404 when you actively want crawlers to drop the URL.
• Document the sunset timeline so callers can migrate.

Server insists on a Content-Length header and the client did not send one.

• Hand-crafted HTTP request omitted Content-Length.
• Chunked encoding disabled by an intermediate.

• Telnet-style HTTP testing.
• Old proxy chain rejecting chunked POSTs.

• Add `Content-Length: <bytes>` to the request.
• Or use a real HTTP library that handles it automatically.

One or more conditions in the request headers (If-Match, If-Unmodified-Since, etc.) evaluated to false. Server refused to act.

• ETag in If-Match no longer matches the resource — someone else updated it.
• If-Unmodified-Since is older than the resource.

• Concurrent edit detection — second writer's ETag is stale.
• CalDAV / CardDAV optimistic locking.

• Re-GET the resource to pick up the fresh ETag, merge changes, retry the write.
• Surface the conflict to the user (just like 409) so they can decide what to keep.

Request body exceeded the server's max size. Classic for upload endpoints. Used to be called "Payload Too Large".

• User uploaded a 100MB file to an endpoint capped at 10MB.
• nginx `client_max_body_size` default is 1MB.
• Cloudflare free plan caps uploads at 100MB.

• Profile picture upload silently fails because nginx 413's before the app sees the request.
• Large JSON payload to an internal service.

• nginx: bump `client_max_body_size 50m;` in http / server / location block, reload.
• Express: `app.use(express.json({ limit: '10mb' }))`.
• CloudFlare: paid plans needed for >100MB.
• Tell users the limit BEFORE they upload — frontend file-size check saves a round trip.

The URL is longer than the server is willing to parse. Usually means too many query params or someone stuffing data into the URL.

• GET with hundreds of IDs in `?ids=1,2,3,…,9999`.
• Server set `large_client_header_buffers` too small.
• Attack probe with massive URL.

• Frontend "select all then fetch" sending 5000 IDs in query.
• Tracking pixel with deeply nested params.

• Switch the request to POST with a body — URLs are not the place for arbitrary data.
• Tune nginx `large_client_header_buffers 4 16k;` cautiously.
• Use pagination instead of mega-batches.

Client sent a Content-Type the server cannot process.

• POSTing raw text to an endpoint that requires application/json.
• Wrong multipart boundary on file upload.
• Forgot to set Content-Type on a JSON fetch.

• fetch(url, { body: JSON.stringify(x) }) without headers — server gets text/plain and bails.
• Image API rejects WebP.

• Set the correct Content-Type header on the client.
• Or relax the server to accept more types.

The Range header in the request asks for bytes the server cannot provide — usually past the end of the file.

• Client asked for `bytes=10000-` but file is only 5000 bytes.
• Negative offset on a server that does not support it.

• Video player computing offset wrong on a truncated file.
• Resumable download after the source was overwritten with a smaller file.

• Re-fetch the resource size, then request a valid range.
• Server should include `Content-Range: bytes */<total>` so the client can recover.

Server cannot meet the requirements of the Expect request-header field.

• Client sent `Expect: 100-continue` to a server that does not support it.
• Old proxy chain breaking Expect semantics.

• curl uploading to a basic HTTP server that rejects Expect.

• Remove the Expect header — `curl -H "Expect:"` to suppress.

April Fools RFC 2324 joke status — a teapot cannot brew coffee. Some sites use it as a deliberate "go away" response for bots.

• You hit /coffee on an HTCPCP teapot.
• Anti-bot rule responding with 418 instead of 403.

• Easter egg endpoint at /teapot.
• Cloudflare worker returning 418 for known scrapers.

• Use a real coffee maker.
• For serious APIs, do NOT use 418 — pick 403 / 429 / 503.

Request was sent to a server that cannot produce a response — usually HTTP/2 connection coalescing sending to a server that does not own the hostname.

• HTTP/2 connection reuse across hostnames with mismatched cert SAN.
• Origin pinning to wrong IP.

• Multi-domain HTTPS site behind a single IP, browser coalesces incorrectly.

• Disable HTTP/2 coalescing or use distinct origin IPs.
• Ensure cert SANs cover all coalesced hostnames.

The request is syntactically fine but semantically invalid. Body parses, fields are missing or wrong shape, validation rejects it.

• Email field has a typo and fails the format check.
• Required relationship missing in the payload.
• Numeric field below the allowed minimum.
• Rails / Laravel / FastAPI default for validation errors.

• Sign-up form with weak password rejected by API.
• API receiving JSON that does not match the schema.

• Read the body — frameworks usually return a `errors` map: `{ "email": ["invalid format"] }`.
• Surface those errors next to the form fields, not as a generic toast.
• Use 422 over 400 when distinguishing parse errors (400) from validation errors (422).

WebDAV — the resource is locked and the request requires a lock token.

• Another client holds the WebDAV lock.
• Editing-collaboration system enforcing exclusive access.

• Two users editing the same DAV file.

• Wait for the lock to release or unlock with the proper lock token.

WebDAV — the request failed because a previous request it depended on also failed.

• PROPPATCH dependent on a prior locked or failed operation.

• Batch WebDAV operation where step 2 needed step 1.

• Find and fix the root failure, then replay the dependent request.

Server is unwilling to process the request because it might be a replay (TLS 1.3 early data).

• TLS 1.3 0-RTT early data sent for a non-idempotent endpoint.
• Anti-replay protection in front of POST/PUT/DELETE.

• CDN with 0-RTT enabled bouncing POSTs to upstream.
• Cloudflare 425 on a write endpoint.

• Disable 0-RTT for write endpoints, or retry the request — usually a one-shot.

Client must switch to a different protocol (e.g. HTTPS, HTTP/2) to access the resource.

• HTTP-only client hitting an HTTPS-only API.
• Server requiring HTTP/2 for performance reasons.

• Legacy IoT device upgraded server now demands TLS.
• gRPC server requiring HTTP/2.

• Read the Upgrade header in the response — it tells you what to use.
• Update the client to support the required protocol.

Server requires the request to be conditional (e.g. with If-Match) to prevent the lost-update problem.

• PUT without If-Match on an endpoint that demands optimistic concurrency.
• API forcing safe concurrent edits.

• Wiki API requiring If-Match: ETag on every save.
• Configuration management API.

• Add `If-Match: "<etag>"` to the request — get the etag from the previous GET.

Client hit a rate limit. Server should return a Retry-After header telling you when to try again.

• Per-IP rate limit hit (nginx `limit_req_zone`).
• API key over its quota.
• Misconfigured client retrying in a tight loop.
• GitHub / Twitter / OpenAI API throttling.

• Scraper hammering the API gets 429 after 60 req/min.
• CI flooding webhooks during a deploy.

• Read the Retry-After header — wait that long, then retry. Implement exponential backoff with jitter.
• Cache responses to reduce request volume.
• Bump quota with the API provider if legitimately needed.
• On the server: 429 with Retry-After is way friendlier than dropping connections.

The total size or single field of request headers exceeded the server limit.

• Cookie jar bloated past 8KB.
• Huge JWT in Authorization header.
• Tracking headers stacked by multiple middlewares.

• After 6 months of A/B testing, cookies trip the nginx default 8k header buffer.
• Long claim list in JWT.

• Trim cookies and headers — clear stale A/B flags, drop unused tracking.
• For nginx: `large_client_header_buffers 4 16k;` to raise the limit cautiously.
• Compress JWT claims or move state out of the token.

Nginx custom — server closed the connection without sending any response. Used to silently drop unwanted traffic without giving away that anything is listening.

• `return 444;` in nginx config for unwanted Host headers.
• Default block for unmatched server_name.

• Anti-scan: respond 444 to any Host that is not the real domain.
• Drop bot traffic by user-agent.

• If your own client gets 444, check that the Host header matches the configured server_name.
• Use carefully — 444 makes debugging harder for legitimate misconfigured clients.

Resource blocked by legal demand — court order, DMCA, GDPR removal, government censorship. Named after Bradbury's Fahrenheit 451.

• DMCA takedown.
• GDPR right-to-be-forgotten request.
• Geo-blocking on legal grounds.

• Music platform region-blocking after rights expired.
• News article taken down by court order.

• Include a Link header pointing to a page explaining the legal basis.
• Users in blocked regions may not be able to access — that is the point.

Nginx custom — client closed the connection before the server finished responding. Common when impatient users navigate away.

• User clicked stop / navigated away before page finished.
• Mobile app cancelled an in-flight request.
• Upstream timeout shorter than nginx waiting on backend.

• Slow report endpoint — users give up after a few seconds.
• Mobile network switching from Wi-Fi to LTE mid-request.

• Speed up the slow endpoint — 499 spikes mean impatient users.
• Distinguish "user gave up" (499) from "we timed out" (504) when alerting.
• For mobile: check abort patterns in the client SDK.

The server hit an unhandled exception. The catch-all for "something blew up and we did not classify it better".

• Unhandled exception in the application code.
• DB query threw an error and the handler did not catch.
• Null pointer / division by zero / type error.
• Out of memory / out of file descriptors.

• New code path with a bug only the production data triggers.
• DB connection pool exhausted during traffic spike.
• Third-party dependency throwing a new exception class.

• Read application logs FIRST — the stack trace is your friend.
• Add APM / Sentry for production stack traces.
• Never return raw exception messages to clients — leak vector.
• For ops: check disk / memory / FD limits in dashboards before chasing app bugs.

The server does not support the functionality required for this request — usually because the HTTP method is not supported at all.

• Client used TRACE or CONNECT and the server does not handle them.
• gRPC method not yet implemented.
• Placeholder route returned 501 deliberately.

• Probing tool sending TRACE to test security.
• API still under construction.

• If you actually mean "feature coming later", document a roadmap.
• For unsupported methods, also return an Allow header.

A gateway/proxy got an invalid response from upstream. nginx says "I connected but the backend gave me garbage or nothing". The upstream is the problem 99% of the time.

• Backend crashed mid-request.
• Backend not listening on the expected port.
• Backend returned malformed HTTP.
• Upstream timeout/idle close mid-stream.
• SELinux blocking nginx → backend (RHEL/CentOS).

• Deploy where the new container is not up yet.
• Node process crashed and PM2 has not restarted.
• Backend pod evicted by k8s.

• Hit the upstream directly: `curl -v http://127.0.0.1:3000`. If that fails too, restart the backend and read its logs first.
• `sudo tail -f /var/log/nginx/error.log` — look for "connect() failed (111: Connection refused)", "upstream prematurely closed connection", "no live upstreams".
• On RHEL/CentOS: `setsebool -P httpd_can_network_connect 1` for the SELinux gotcha.
• Bumping nginx timeouts does NOT fix 502 — that fixes 504.

Server is up but temporarily cannot handle the request — usually overloaded or down for maintenance. SHOULD include Retry-After.

• Maintenance window — load balancer returning 503 deliberately.
• Pool of workers exhausted, queue full.
• Rate limiter dropping requests when concurrency cap hit.
• Database failover in progress.

• Deploy script gracefully draining the old fleet.
• Traffic spike from a viral post.
• Background job worker pool overwhelmed.

• Read Retry-After. Retry with backoff.
• For ops: check worker / db / queue saturation in dashboards.
• Scale horizontally — add workers / pods.
• For maintenance: serve a friendly HTML page with 503 + Retry-After header instead of the default white screen.

Gateway/proxy waited too long for upstream and gave up. 504 = upstream is SLOW (or hung). 502 = upstream is BROKEN.

• Long DB query blocking the backend.
• Backend stuck in a loop or deadlock.
• External dependency (S3, third-party API) timing out.
• nginx `proxy_read_timeout` shorter than the backend's natural response time.

• Report endpoint runs a 3-minute aggregation but proxy timeout is 60s.
• AI inference taking 90s behind a default-timeout proxy.

• Profile the slow path — fix the DB query / dependency / loop. Do not just bump timeouts.
• If the long response is legitimate (exports, AI runs), move to a job queue and return 202 + job_id.
• For nginx: `proxy_read_timeout 300s;` on JUST the slow location, not globally.
• WebSockets default-timeout 60s? Add `proxy_read_timeout 3600s;` for the WS location.

Server does not support the HTTP version of the request.

• Ancient client speaking HTTP/0.9.
• Misconfigured proxy injecting wrong version line.

• Embedded device from the 90s probing a modern server.
• Broken HTTP client library.

• Upgrade the client to HTTP/1.1 or 2.
• Check the wire dump — version line should be `HTTP/1.1`.

A misconfigured content negotiation loop — server variant points back at another variant. Very rare.

• Apache mod_negotiation misconfiguration.
• Circular Transparent Content Negotiation setup.

• Old Apache site with TCN gone wrong.

• Audit the negotiation configuration to remove circular references.

Server is out of storage required to complete the request. WebDAV-flavoured but also seen on uploads.

• Upload destination disk full.
• WebDAV quota exceeded.
• Backup volume out of space.

• Photo upload service running out of S3 / volume capacity.
• Nextcloud user hitting personal quota.

• Check disk usage on the server.
• Clean up orphan uploads, raise quotas, or expand the volume.

WebDAV — server detected an infinite loop while processing the request (usually circular references in collections).

• WebDAV symlink loops.
• Recursive PROPFIND on a collection that references itself.

• Misconfigured WebDAV share with symlink that points back to root.

• Find and remove the symlink loop.
• Audit collection references for self-loops.

Server requires further extensions to fulfill the request (HTTP extension framework, rarely used).

• Client lacked required HTTP extensions per RFC 2774.

• Specialised research / academic protocols.

• Read the response for the required extension; implement it client-side.

The CLIENT must authenticate to gain network access. Returned by captive portals on hotel/airport Wi-Fi.

• Hotel Wi-Fi captive portal intercepting traffic.
• Public Wi-Fi terms-of-service page not yet accepted.

• Open laptop in a hotel lobby, every HTTPS request 511s.
• Browser detects 511 and pops the captive portal.

• Open a browser, accept the captive portal terms, then retry.
• Use a non-HTTPS first request (like `curl http://detectportal.firefox.com`) to surface the portal.

Cloudflare custom. The origin returned something Cloudflare cannot interpret — empty response, unexpected header, or connection reset.

• Origin crashed mid-response.
• Origin sent malformed headers (e.g. invalid Content-Length).
• Connection reset (RST) from origin during response.

• Origin server with a buggy reverse proxy mangling Content-Length.
• Random sporadic failures on a single origin in a pool.

• Bypass Cloudflare (`curl --resolve domain:443:<origin-ip>`) and reproduce against the origin directly.
• Check origin logs for crashes or RST.
• Watch for response header anomalies.

Cloudflare custom. The origin refused the TCP connection. Origin is not accepting connections on port 80/443.

• Origin server down / process not running.
• Firewall blocking Cloudflare IPs.
• Origin moved to a new IP that DNS / Cloudflare does not know.

• Server reboot in progress.
• Misconfigured iptables blocking 443.

• Bring the origin back up; verify with `curl --resolve` against the origin IP.
• Allow Cloudflare IP ranges (https://www.cloudflare.com/ips/) at the firewall.

Cloudflare custom. The TCP handshake to the origin timed out — no SYN-ACK in time.

• Origin overloaded — too many SYNs queued.
• Firewall silently dropping (DROP, not REJECT) Cloudflare traffic.
• Network routing issue between Cloudflare and origin.

• Origin under DDoS, kernel SYN queue full.
• Wrong iptables rule dropping packets from a new Cloudflare range.

• `tcpdump -i eth0 port 443 and host <cloudflare-ip>` to see if SYNs arrive.
• Bump `net.core.somaxconn` and listen backlog.
• Audit firewall and routing.

Cloudflare custom. Cloudflare cannot reach the origin at all — DNS, routing, or origin IP no longer responding.

• Origin DNS record points to a stale IP.
• BGP routing problem.
• Origin host gone permanently.

• Migration to a new origin without updating the Cloudflare record.
• Hosting provider rotated IPs.

• Verify origin DNS in Cloudflare dashboard.
• Ping / traceroute from a third-party host to the origin IP.

Cloudflare custom. TCP handshake succeeded but origin took too long to send the HTTP response (default ~100s on Free).

• Long-running endpoint (export, AI, big report).
• Origin stuck on a slow DB query.
• External dependency lag.

• Generating a 50MB PDF behind Cloudflare.
• AI image generation that takes 3 minutes.

• Move long jobs to async — return 202 + job_id, poll for completion.
• Use Cloudflare Workers / Streams to chunk the response.
• Enterprise plan raises the timeout, but redesigning is the real answer.

Cloudflare custom. TLS handshake between Cloudflare and origin failed — usually cert / protocol / cipher mismatch.

• Origin cert expired or self-signed (and Cloudflare mode is Full strict).
• Origin only supports SSLv3 / TLS 1.0 while Cloudflare requires 1.2+.
• Cipher suite mismatch.

• Forgot to renew the origin cert (Let's Encrypt expires in 90 days).
• Legacy origin behind a fancy CDN.

• Test from outside: `openssl s_client -connect origin:443 -servername host`.
• Renew the origin cert; update certbot crontab.
• Set Cloudflare SSL mode to "Full" (not "Full strict") only as a temporary diagnostic, not long term.

Cloudflare custom. Cloudflare in Full (strict) mode could not validate the origin cert — wrong hostname, untrusted CA, or expired.

• Origin cert CN/SAN does not include the hostname.
• Cert issued by an untrusted CA.
• Cert expired.

• Origin serving a self-signed cert.
• Wildcard cert that does not cover the new subdomain.

• Issue a proper publicly-trusted cert for the hostname (Let's Encrypt is free).
• Use Cloudflare Origin CA cert for origin if you do not want a public cert.

Cloudflare custom. Connection between Cloudflare and Railgun listener failed. Mostly historic — Railgun is deprecated.

• Railgun listener down on origin.
• Network issue between Cloudflare and Railgun.

• Legacy Cloudflare + Railgun setup.

• Migrate off Railgun — Cloudflare deprecated it. Use Argo Smart Routing instead.

Cloudflare custom. Typically rendered alongside a 1xxx Cloudflare error in the body — often means the origin DNS is broken, the zone is frozen, or another 5xx Cloudflare condition.

• Cloudflare zone frozen (account or domain issue).
• Origin DNS unresolvable.
• Argo Tunnel down.

• Origin nameservers down — Cloudflare cannot resolve.
• Account suspended.

• Read the body — Cloudflare prints the underlying 1xxx error and a help link.
• Check Cloudflare dashboard for account status.
• Verify origin DNS resolves from outside.