HTTP Status Code Reference for APIs, websites, proxies, and debugging

Look up HTTP response status codes by number, phrase, category, source, lifecycle, and practical troubleshooting context. This reference covers standard RFC status codes, common WebDAV extensions, CDN and proxy-specific codes, and the differences that matter when debugging REST APIs, browser requests, SEO crawl issues, redirects, authentication failures, rate limits, gateway errors, and upstream timeouts.

  • Search by status code, phrase, category, related code, vendor, or debugging keyword.
  • Compare 1xx, 2xx, 3xx, 4xx, and 5xx semantics without leaving the page.
  • Read practical guidance for API design, browser debugging, CDN incidents, and server-side troubleshooting.

Search HTTP status codes

Enter a code such as 404, a phrase such as Bad Gateway, or a keyword such as cache, redirect, WebSocket, Cloudflare, timeout, authentication, or rate limit.

1xx Informational

Interim responses sent before the final response. They are usually handled by HTTP clients, servers, proxies, or browser networking layers.

100

Continue

The server has received the request headers, and the client may continue sending the request body.

1xx Informational Standard Not recommended RFC 9110
Details

100 Continue means the server has received the initial part of the request, usually the request line, request headers, and enough metadata to make an early decision, and it has not found a reason to reject the request yet. It is an informational, interim response; it does not mean the request has succeeded. Its main purpose is to tell the client that it may continue sending the remaining request content, especially a large request body. It is most commonly used with the Expect: 100-continue mechanism, where the client sends headers first, waits for the server to perform early checks such as authentication, permissions, Content-Type, Content-Length, and resource limits, and then sends the body only after receiving permission to continue. The final result is still determined by a later final response status code.

Common situations
  • A client is about to upload a large file, a large form submission, bulk JSON data, or another large request body and wants to confirm that the server is willing to receive it before sending everything.
  • The request includes Expect: 100-continue, so the client sends headers first and waits for 100 Continue before sending the body.
  • The server wants to evaluate authentication, authorization, content type, content length, routing, or resource limits before accepting the full body.
  • A reverse proxy, load balancer, gateway, or origin server must correctly forward the interim response between client and server.
  • The client wants to avoid wasting bandwidth when a request would be rejected before the body is needed.
What to check
  • After receiving 100 Continue, the client should keep sending the remaining request body, such as file content, form data, JSON, or another payload.
  • Do not treat 100 Continue as the final result. The client must still wait for a final status code such as 200, 201, 204, 400, 401, 403, 413, 415, or 417.
  • If a request appears stuck around 100 Continue, check whether the client actually sends the body after the interim response.
  • If the client never receives 100 Continue, verify that the server, reverse proxy, load balancer, or gateway supports and forwards Expect: 100-continue correctly.
  • If the server already knows it will reject the request, return a final error such as 401, 403, 413, 415, or 417 instead of 100 Continue.
Avoid using it when
  • Do not manually return 100 Continue from normal REST API or JSON API business logic; it is usually handled by HTTP servers, runtimes, proxies, or frameworks.
  • Do not use 100 Continue as a success response.
  • Do not return 100 Continue after the full request body has already been received and processed.
  • Do not use 100 Continue to mean an asynchronous task has started; use 202 Accepted for that.
Source: RFC 9110 Related codes: 101, 102, 103, 200, 202, 204, 413, 417
101

Switching Protocols

The server agrees to switch to the protocol requested by the client.

1xx Informational Standard Not recommended RFC 9110
Details

101 Switching Protocols means the server understood the client's protocol upgrade request, usually expressed with the Upgrade header, and agrees to switch the current connection to another protocol. It is an informational response used during a protocol upgrade handshake, not a normal success response for returning business data. After 101 is sent, subsequent bytes on the same connection are interpreted according to the protocol named in the Upgrade response header instead of the original HTTP message format. The most common example is the WebSocket handshake: the client starts with an HTTP request, the server validates Upgrade, Connection, and WebSocket headers, returns 101, and the connection becomes a bidirectional WebSocket channel.

Common situations
  • A client uses the Upgrade header to request that the current HTTP connection be upgraded to another protocol.
  • A WebSocket connection is being established and the server accepts the WebSocket handshake.
  • The client and server need to switch from HTTP request-response messages to another protocol over the same underlying connection.
  • A reverse proxy, API gateway, or load balancer must preserve Upgrade and Connection headers for WebSocket or similar traffic.
  • The server wants to make it explicit that future bytes on the connection should be parsed using the upgraded protocol.
What to check
  • After receiving 101, the client should stop parsing the connection as a normal HTTP response body and switch to the protocol named by the Upgrade header.
  • If a WebSocket handshake fails, check Upgrade: websocket, Connection: Upgrade, Sec-WebSocket-Key, Sec-WebSocket-Version, TLS, and routing configuration.
  • If the server does not return 101, confirm that the target service supports protocol upgrades on that path and port.
  • If the connection fails behind Nginx, a CDN, a gateway, or a load balancer, verify that the intermediary allows long-lived upgraded connections.
  • If a browser reports WebSocket handshake failed, inspect the actual status code returned, such as 400, 401, 403, 404, 426, or 500.
Avoid using it when
  • Do not return 101 from ordinary REST APIs or JSON APIs unless the endpoint is actually switching protocols.
  • Do not use 101 as a generic success response.
  • Do not return 101 when the client did not send an Upgrade request.
  • Do not use 101 to merely suggest that the client should upgrade; 426 Upgrade Required is closer to that meaning.
Source: RFC 9110 Related codes: 100, 200, 204, 400, 426
102

Processing

The server has received the complete request and is still processing it.

1xx Informational Deprecated Not recommended RFC 2518
Details

102 Processing means the server has received the complete request and is working on it, but no final response is available yet. It originally came from WebDAV and was intended for operations that may take a long time, such as multi-resource file operations. Its purpose is to reassure the client that the request was not lost and that the server is still processing it. 102 is not a final response and does not mean success. It was defined in RFC 2518 and later removed from the updated WebDAV specification, so modern general-purpose web services rarely send it intentionally.

Common situations
  • A WebDAV request may take a long time and the server wants to show that processing is still active.
  • A request involves multiple files, directories, resource collections, locks, or recursive operations.
  • A client or intermediary might close the connection if no response is received for a long time.
  • A legacy WebDAV client or old server implementation expects or emits 102 Processing.
What to check
  • After receiving 102, the client should continue waiting for the final response instead of treating it as success or failure.
  • If a request stays at 102 for a long time, check for deadlocks, blocked queues, backend timeouts, or resource lock waits.
  • If clients or proxies time out during long operations, review read timeouts, gateway timeouts, buffering, and backend task duration.
  • For modern APIs that accept work for later processing, prefer 202 Accepted with a task ID or status URL.
  • When a final result is known, return a final status code such as 200, 201, 204, 207, 400, 409, 423, 500, or 507.
Avoid using it when
  • Do not use 102 in ordinary REST APIs to mean an asynchronous job was created; use 202 Accepted instead.
  • Do not treat 102 as a final success response.
  • Do not keep returning 102 when a final response is already available.
  • Do not use 102 to tell the client to continue sending a request body; that is 100 Continue.
Source: RFC 2518 Related codes: 100, 103, 200, 202, 207, 408, 409, 423, 504, 507
103

Early Hints

The server sends response-header hints before the final response is ready.

1xx Informational Standard Not recommended RFC 8297
Details

103 Early Hints lets the server send headers that are likely to appear in the final response before the final response itself is ready. It is mainly a performance optimization, not a business result. The most common use is sending Link headers early while the server is still generating HTML, waiting on a database, rendering a page, or calling an upstream service. A browser can then preconnect, preload, or prefetch critical resources such as CSS, JavaScript, fonts, images, or third-party origins. 103 does not replace the final response; the client must still wait for the final status code.

Common situations
  • The server is generating an HTML response but already knows the critical CSS, JavaScript, font, or image resources the page will need.
  • The service wants to send Link headers with rel=preload, rel=preconnect, or rel=dns-prefetch before the final page is available.
  • Page performance metrics such as LCP, TTFB-to-resource-load gap, or first render time are important.
  • A CDN, edge service, reverse proxy, or application server can infer critical resources from route metadata or templates.
  • The final response is waiting for rendering, authentication, database work, or an upstream call, but resource dependencies are predictable.
What to check
  • Do not treat 103 as the final response. Continue waiting for the final status code and final headers.
  • Browsers may act on Link headers in 103, but whether those resources are ultimately used still depends on the final response.
  • If 103 has no performance effect, check Link header syntax and attributes such as rel, as, crossorigin, and type.
  • If Early Hints is sent through a CDN, Nginx, reverse proxy, or gateway, verify that the intermediary does not drop 1xx responses.
  • Avoid sending too many early hints; only include high-confidence, critical resources.
Avoid using it when
  • Do not use 103 as an API success response.
  • Do not use 103 in ordinary REST or JSON APIs to describe business progress.
  • Do not preload low-confidence or large resources that may waste bandwidth.
  • Do not expose sensitive or permission-dependent resource URLs before access is confirmed.
Source: RFC 8297 Related codes: 100, 102, 200, 204, 304, 404, 500
104

Upload Resumption Supported

The server indicates that the current upload supports resumable recovery.

1xx Informational Temporary Not recommended draft-ietf-httpbis-resumable-upload-05
Details

104 Upload Resumption Supported tells the client, during an upload request, that the target resource supports HTTP upload resumption. It is an informational status code for resumable upload scenarios and is currently a temporary registration tied to an HTTP draft, not a stable RFC. Its purpose is not to say that the upload succeeded; it tells the client that if the upload is interrupted by a network failure, tab close, connection reset, or mobile network switch, the client may later resume according to the protocol instead of starting from scratch.

Common situations
  • A client is uploading a large video, archive, backup, or other long-running payload and wants to resume after interruption.
  • The server implements the HTTP resumable upload draft and wants to advertise upload resumption support early.
  • The environment is unreliable, such as mobile networks, weak connectivity, app backgrounding, or browser refreshes.
  • The upload service needs to expose an upload resource, recovery URL, Upload-Offset, or resumable session state.
  • Both client and server explicitly support the resumable upload draft and understand 1xx interim responses.
What to check
  • After receiving 104, the client should not assume the upload is complete; it should continue uploading and wait for the final response.
  • If an upload is interrupted, resume from the Upload-Offset confirmed by the server.
  • If resumption fails, check Upload-Offset handling, content length, upload resource identity, session expiration, and concurrent upload conflicts.
  • If 104 disappears behind a proxy, CDN, gateway, or load balancer, verify that 1xx responses are forwarded correctly.
  • If a normal upload endpoint does not implement resumable upload semantics, return a normal final status such as 201, 204, or an error instead.
Avoid using it when
  • Do not treat 104 as an upload success response.
  • Do not return 104 unless upload resumption, offset validation, session persistence, and recovery behavior are implemented.
  • Do not use 104 from ordinary JSON APIs or simple upload endpoints.
  • Do not assume all browsers, HTTP clients, proxies, CDNs, or frameworks support this temporary code.

2xx Success

Successful responses. Use the most precise success code so clients can distinguish completed work, created resources, accepted jobs, empty responses, and partial content.

200

OK

The request succeeded and the response is meaningful for the request method.

2xx Success Standard Recommended RFC 9110
Details

200 OK means that the server successfully processed the request and returned a response appropriate to the method. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • GET requests that return resources, POST requests that return processing results, successful JSON APIs, and normal web pages
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 200 OK, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Use 201 Created when a new resource was created.
  • Use 202 Accepted when processing has only been accepted for later work.
Avoid using it when
  • Do not wrap application failures in 200 with an error flag in the body.
  • Do not use 200 for every successful path when a more precise status exists.
  • Do not serve real error pages as 200; soft errors can confuse users, crawlers, and monitoring.
Source: RFC 9110 Related codes: 201, 202, 204, 206, 304, 400, 500
201

Created

The request succeeded and a new resource was created.

2xx Success Standard Recommended RFC 9110
Details

201 Created means that the request succeeded and the server created a new resource as a result. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • creating users, orders, articles, files, comments, access tokens, or other server-side resources
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 201 Created, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Include a Location header when there is a canonical URL for the new resource.
  • Return the new resource ID, summary, status, or next action in the body when helpful.
Avoid using it when
  • Do not mix 201 with 201, 200, 202, 204, 303, 409, and 422; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not return 201 when no new resource was created.
  • Do not use 201 for ordinary updates; 200 or 204 is usually clearer.
Source: RFC 9110 Related codes: 200, 202, 204, 303, 409, 422
202

Accepted

The request was accepted, but processing has not finished yet.

2xx Success Standard Recommended RFC 9110
Details

202 Accepted means that the server accepted the request for processing, but the final outcome is not available yet. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • asynchronous jobs, imports, exports, video encoding, report generation, queue processing, and bulk operations
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 202 Accepted, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return a job ID, status URL, polling interval, or callback information.
  • Document whether the final job may still fail.
Avoid using it when
  • Do not mix 202 with 202, 200, 201, 204, 102, and 303; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 202 to mean the job succeeded.
  • Do not return 202 without any way to discover the final outcome.
Source: RFC 9110 Related codes: 100, 102, 200, 201, 204, 303, 409
203

Non-Authoritative Information

The request succeeded, but the payload was transformed or supplied by a non-authoritative intermediary.

2xx Success Standard Use with care RFC 9110
Details

203 Non-Authoritative Information means that the response is successful but differs from the origin's authoritative representation because an intermediary modified it. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • proxies, gateways, content transformers, mirrors, or cache layers returning modified successful responses
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 203 Non-Authoritative Information, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Compare the origin response with the transformed response when debugging data differences.
  • Document any transformation such as compression, filtering, translation, redaction, or enrichment.
Avoid using it when
  • Do not mix 203 with 203, 200, 204, and 304; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 203 for normal success responses.
  • Do not hide proxy-induced data changes behind an unexplained 203.
Source: RFC 9110 Related codes: 200, 204, 304, 502
204

No Content

The request succeeded and no response body should be returned.

2xx Success Standard Recommended RFC 9110
Details

204 No Content means that the server successfully completed the request and intentionally has no content to send in the response body. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • successful deletes, saves, toggle updates, unsubscribe actions, and APIs where the client does not need returned data
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 204 No Content, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Clients should not try to parse a JSON body from a 204 response.
  • Use 200 when the client needs updated data after the operation.
Avoid using it when
  • Do not mix 204 with 204, 200, 201, 202, and 205; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not include a JSON response body with 204.
  • Do not use 204 to mean an async task started.
Source: RFC 9110 Related codes: 200, 201, 202, 205
205

Reset Content

The request succeeded and the client should reset the current input view.

2xx Success Standard Use with care RFC 9110
Details

205 Reset Content means that the operation succeeded and the user agent is expected to reset the document view, form, or input state. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • form submissions where the UI should clear fields, reset an editor, or return to an initial input state
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 205 Reset Content, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Make sure the frontend actually handles 205 by resetting the relevant form or view.
  • Use 204 if no reset behavior is intended.
Avoid using it when
  • Do not mix 205 with 205, 200, and 204; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 205 when the UI should keep its current state.
  • Do not put business data in a 205 response body.
Source: RFC 9110 Related codes: 200, 204
206

Partial Content

The server returned only part of a resource in response to a Range request.

2xx Success Standard Use with care RFC 9110
Details

206 Partial Content means that the response contains one or more ranges of the target resource instead of the complete representation. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • range downloads, video seeking, audio streaming, file chunking, and large object retrieval
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 206 Partial Content, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Verify that the request contains a valid Range header.
  • Return Content-Range so the client can understand which bytes were sent.
Avoid using it when
  • Do not mix 206 with 206, 200, 304, and 416; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 206 for paginated API lists; pagination normally returns 200.
  • Do not return 206 without a valid range semantics.
Source: RFC 9110 Related codes: 200, 304, 416
207

Multi-Status

The response body contains separate status results for multiple resources or sub-operations.

2xx Success Standard Not recommended RFC 4918
Details

207 Multi-Status means that the server is returning a multi-part status report, usually for WebDAV operations across multiple resources. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • WebDAV batch operations, collection operations, multi-file property updates, and resource trees
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 207 Multi-Status, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Clients must inspect each embedded resource status, not only the overall 207.
  • For ordinary batch JSON APIs, 200 with a structured result array may be easier for clients than WebDAV semantics.
Avoid using it when
  • Do not mix 207 with 207, 200, 206, 208, and 424; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 207 in ordinary REST APIs unless WebDAV-style multi-status semantics are intentional.
  • Do not treat 207 as meaning every sub-operation succeeded.
Source: RFC 4918 Related codes: 200, 206, 208, 424
208

Already Reported

A WebDAV binding member has already been reported earlier in the response.

2xx Success Standard Not recommended RFC 5842
Details

208 Already Reported means that the response is avoiding duplicate reporting of the same WebDAV binding member. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • WebDAV depth requests and collection traversal where the same resource appears through multiple bindings
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 208 Already Reported, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Interpret 208 inside the surrounding 207 Multi-Status response.
  • Use it only when WebDAV binding semantics are actually involved.
Avoid using it when
  • Do not mix 208 with 208, 207, and 508; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 208 to mean a business duplicate submission.
  • Do not use 208 in normal REST APIs.
Source: RFC 5842 Related codes: 207, 226, 508
226

IM Used

The server returned a representation after applying an instance manipulation.

2xx Success Standard Not recommended RFC 3229
Details

226 IM Used means that the server satisfied a GET request using delta encoding or another instance manipulation supported by the client. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • HTTP delta encoding and clients that explicitly support instance manipulations
  • It appears in successful API or browser responses where the caller must decide whether data was returned, a resource was created, work was accepted, or no response body should be parsed.
What to check
  • First confirm that the situation really matches the semantics of 226 IM Used, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Confirm that the client requested and supports the instance manipulation used.
  • Validate cache validators, ETags, and delta encoding consistency.
Avoid using it when
  • Do not mix 226 with 226, 200, 206, and 304; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 226 for ordinary partial downloads; Range requests use 206.
  • Do not use 226 in normal JSON APIs without explicit protocol support.
Source: RFC 3229 Related codes: 200, 206, 304

3xx Redirection

Redirect and cache-related responses. They affect browser navigation, crawlers, canonical URLs, API clients, and retry behavior.

300

Multiple Choices

The target resource has multiple possible representations or destinations.

3xx Redirection Standard Use with care RFC 9110
Details

300 Multiple Choices means that the request matches more than one representation and the user or client may need to choose. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • multi-language resources, multiple formats, mirrors, versions, or variant URLs
  • It appears when clients, browsers, crawlers, or SDKs need to follow or interpret a redirect or content-selection response correctly.
What to check
  • First confirm that the situation really matches the semantics of 300 Multiple Choices, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Provide a clear list of choices in the response body.
  • Use a more specific redirect when the server already knows the best target.
Avoid using it when
  • Do not mix 300 with 300, 301, 302, 303, and 406; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not return 300 when there is only one obvious target.
  • Do not return 300 without a usable list of alternatives.
Source: RFC 9110 Related codes: 301, 302, 303, 406
301

Moved Permanently

The resource has permanently moved to a new URL.

3xx Redirection Standard Recommended RFC 9110
Details

301 Moved Permanently means that the target resource has a new permanent URI and clients or search engines may update stored references. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • site migrations, URL canonicalization, HTTP-to-HTTPS redirects, domain moves, and permanent path changes
  • It appears in browser developer tools, SEO crawls, or API clients when a request is being redirected and the caller must understand whether the move is temporary, permanent, or method-preserving.
What to check
  • First confirm that the situation really matches the semantics of 301 Moved Permanently, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Always include a correct Location header.
  • Check for redirect loops, redirect chains, wrong targets, and mixed HTTP/HTTPS behavior.
Avoid using it when
  • Do not mix 301 with 301, 302, 307, 308, 404, and 410; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 301 for temporary campaigns or A/B tests.
  • Do not redirect all missing pages to the homepage.
Source: RFC 9110 Related codes: 302, 307, 308, 404, 410
302

Found

The resource is temporarily available at another URL.

3xx Redirection Standard Recommended RFC 9110
Details

302 Found means that the client may temporarily use another URL, but future requests should still use the original URL. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • temporary redirects, login return flows, short-term campaigns, experiments, and temporary traffic shifting
  • It appears in browser developer tools, SEO crawls, or API clients when a request is being redirected and the caller must understand whether the move is temporary, permanent, or method-preserving.
What to check
  • First confirm that the situation really matches the semantics of 302 Found, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Include a Location header pointing to the temporary target.
  • Use 307 when the original method and body must be preserved.
Avoid using it when
  • Do not mix 302 with 302, 301, 303, 307, and 308; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 302 for permanent migrations.
  • Do not redirect API authentication failures to an HTML login page when 401 is expected.
Source: RFC 9110 Related codes: 301, 303, 307, 308, 401
303

See Other

The client should retrieve another URL with GET to see the result.

3xx Redirection Standard Use with care RFC 9110
Details

303 See Other means that the result of the request can be found at another URI, and the client should use GET for that URI. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • POST-submit-redirect-get flows, form submissions, task creation pages, and result pages
  • It appears in browser developer tools, SEO crawls, or API clients when a request is being redirected and the caller must understand whether the move is temporary, permanent, or method-preserving.
What to check
  • First confirm that the situation really matches the semantics of 303 See Other, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Include a Location header pointing to a GET-friendly resource.
  • Use it to avoid duplicate form submission on browser refresh.
Avoid using it when
  • Do not mix 303 with 303, 201, 202, 302, and 307; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 303 for permanent relocation.
  • Do not point Location to an endpoint that cannot be retrieved with GET.
Source: RFC 9110 Related codes: 201, 202, 302, 307
304

Not Modified

The cached representation is still valid and can be reused.

3xx Redirection Standard Recommended RFC 9110
Details

304 Not Modified means that the conditional request matched the current resource state, so the client may use its cached copy. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • browser caching, CDN caching, ETag, Last-Modified, If-None-Match, and conditional GET
  • It appears during cache validation when the browser or CDN asks whether a stored copy can still be reused.
What to check
  • First confirm that the situation really matches the semantics of 304 Not Modified, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Verify ETag, Last-Modified, Cache-Control, and resource versioning.
  • Do not send a full response body with 304.
Avoid using it when
  • Do not mix 304 with 304, 200, 204, 206, and 412; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not return 304 without a conditional request.
  • Do not use 304 as a business success response.
Source: RFC 9110 Related codes: 200, 204, 206, 412
305

Use Proxy

A historical status code indicating that a proxy should be used.

3xx Redirection Deprecated Not recommended RFC 9110
Details

305 Use Proxy means that the requested response must be accessed through a proxy, but this mechanism is obsolete and unsafe for modern use. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • legacy proxy behavior or historical compatibility documentation
  • It appears when clients, browsers, crawlers, or SDKs need to follow or interpret a redirect or content-selection response correctly.
What to check
  • First confirm that the situation really matches the semantics of 305 Use Proxy, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • If seen in logs, investigate whether an old proxy or custom implementation generated it.
  • Modern systems should configure proxies outside the HTTP response path.
Avoid using it when
  • Do not mix 305 with 305, 300, 307, and 308; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 305 in new systems.
  • Do not use 305 as an ordinary redirect.
Source: RFC 9110 Related codes: 300, 307, 308
306

Unused

A historical reserved status code with no current semantics.

3xx Redirection Reserved Not recommended RFC 9110
Details

306 Unused means that there is no active meaning assigned to this code today. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • documentation, compatibility notes, or explaining old status code lists
  • It appears when clients, browsers, crawlers, or SDKs need to follow or interpret a redirect or content-selection response correctly.
What to check
  • First confirm that the situation really matches the semantics of 306 Unused, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • If 306 appears in production, suspect a custom implementation or misconfiguration.
  • Classify it as unusual in logs and monitoring.
Avoid using it when
  • Do not mix 306 with 306, 305, and 307; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not return 306 from business APIs.
  • Do not assign your own public meaning to 306.
Source: RFC 9110 Related codes: 305, 307
307

Temporary Redirect

The resource is temporarily redirected and the client must not change the method.

3xx Redirection Standard Recommended RFC 9110
Details

307 Temporary Redirect means that the client should repeat the same request method and body at the temporary Location. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • temporary API migration, maintenance routing, short-term failover, and method-preserving redirects
  • It appears in browser developer tools, SEO crawls, or API clients when a request is being redirected and the caller must understand whether the move is temporary, permanent, or method-preserving.
What to check
  • First confirm that the situation really matches the semantics of 307 Temporary Redirect, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Include a Location header.
  • Use 307 rather than 302 when preserving POST, PUT, PATCH, or DELETE semantics matters.
Avoid using it when
  • Do not mix 307 with 307, 302, 303, and 308; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 307 for permanent migration; use 308 instead.
  • Do not use 307 to represent authentication failure.
Source: RFC 9110 Related codes: 302, 303, 308
308

Permanent Redirect

The resource is permanently redirected and the client must not change the method.

3xx Redirection Standard Recommended RFC 9110
Details

308 Permanent Redirect means that the client should use the new URI permanently while preserving the original request method. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • permanent API moves, method-preserving HTTPS/domain migrations, and permanent path canonicalization
  • It appears in browser developer tools, SEO crawls, or API clients when a request is being redirected and the caller must understand whether the move is temporary, permanent, or method-preserving.
What to check
  • First confirm that the situation really matches the semantics of 308 Permanent Redirect, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Use 308 when POST/PUT/PATCH method preservation matters during a permanent migration.
  • Check client, CDN, SDK, and search engine support before large migrations.
Avoid using it when
  • Do not mix 308 with 308, 301, and 307; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 308 for temporary routing.
  • Do not use 308 before the new URL is stable.
Source: RFC 9110 Related codes: 301, 307

4xx Client error

Client-side request problems such as invalid syntax, authentication, authorization, missing resources, validation errors, conflicts, rate limits, or legal restrictions.

400

Bad Request

The request is malformed, syntactically invalid, or missing basic required structure.

4xx Client error Standard Recommended RFC 9110
Details

400 Bad Request means that the server cannot understand or process the request because of invalid syntax, malformed JSON, invalid parameters, or bad framing. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • malformed JSON, wrong parameter types, missing required fields, bad URLs, invalid headers, and request parsing failures
  • It appears in API responses when the caller needs to fix input, resolve a conflict, or retry with a corrected request instead of blindly retrying the same payload.
What to check
  • First confirm that the situation really matches the semantics of 400 Bad Request, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return field or parameter details so the caller can correct the request.
  • Use 422 when the syntax is valid but semantic validation fails.
Avoid using it when
  • Do not use 400 for every client-side problem.
  • Do not use 400 for server exceptions.
  • Do not return only 'Bad Request' when you can explain which field or format is wrong.
Source: RFC 9110 Related codes: 401, 403, 404, 409, 415, 422
401

Unauthorized

Authentication is required or the provided credentials are invalid.

4xx Client error Standard Recommended RFC 9110
Details

401 Unauthorized means that the request lacks valid authentication credentials for the target resource. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • missing login, missing token, expired token, invalid Authorization header, bad signature, and OAuth failures
  • It appears when access fails and the client must distinguish authentication, authorization, proxy authentication, session expiry, and network login problems.
What to check
  • First confirm that the situation really matches the semantics of 401 Unauthorized, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return WWW-Authenticate when an authentication scheme applies.
  • Clients can prompt login, refresh a token, or retry with credentials.
Avoid using it when
  • Do not use 401 for an authenticated user who lacks permission; 403 is usually clearer.
  • Do not use 401 for business validation errors.
  • Do not expose excessive authentication details in the response.
Source: RFC 9110 Related codes: 403, 407, 419, 440
402

Payment Required

Payment, subscription, balance, or quota action is required, although the standard meaning is intentionally broad.

4xx Client error Standard Use with care RFC 9110
Details

402 Payment Required means that the request cannot be fulfilled without payment or commercial entitlement, but the standard does not define a universal payment flow. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • paid APIs, expired subscriptions, insufficient balance, paywalled content, and account quota restrictions
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 402 Payment Required, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Document exactly what payment or subscription condition triggered 402.
  • Provide a billing URL, plan information, or support contact when appropriate.
Avoid using it when
  • Do not mix 402 with 402, 403, and 429; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 402 for unrelated business errors.
  • Do not assume generic HTTP clients have built-in behavior for 402.
Source: RFC 9110 Related codes: 403, 429
403

Forbidden

The server understood the request but refuses to authorize it.

4xx Client error Standard Recommended RFC 9110
Details

403 Forbidden means that the requester is not allowed to perform the operation, even if the request is syntactically valid. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • insufficient permissions, forbidden roles, IP blocks, policy denial, WAF denial, and resource access restrictions
  • It appears when access fails and the client must distinguish authentication, authorization, proxy authentication, session expiry, and network login problems.
What to check
  • First confirm that the situation really matches the semantics of 403 Forbidden, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Confirm whether the user is authenticated; unauthenticated requests usually need 401.
  • Return a clear permission message when safe to do so.
Avoid using it when
  • Do not use 403 for missing authentication; 401 is usually clearer.
  • Do not use 403 for a missing resource unless you intentionally hide it.
  • Do not leak sensitive authorization rules in the response.
Source: RFC 9110 Related codes: 401, 404, 451
404

Not Found

The server cannot find the target resource or is unwilling to reveal it.

4xx Client error Standard Recommended RFC 9110
Details

404 Not Found means that the requested URL, route, resource ID, or endpoint does not exist from the caller's perspective. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • missing pages, unmatched routes, deleted resources, wrong API paths, wrong environment domains, and hidden sensitive resources
  • It appears in websites, APIs, crawlers, and logs when a resource cannot be served and the caller must distinguish missing, permanently removed, hidden, or legally blocked content.
What to check
  • First confirm that the situation really matches the semantics of 404 Not Found, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check path, route prefix, resource ID, casing, API version, domain, and environment.
  • Use 410 when a resource used to exist and is permanently gone.
Avoid using it when
  • Do not use 404 for every error.
  • Do not return 404 for a permanent migration; use 301 or 308.
  • Do not let frontend routing hide real API 404 responses.
Source: RFC 9110 Related codes: 400, 403, 410, 301
405

Method Not Allowed

The resource exists but does not support the request method.

4xx Client error Standard Recommended RFC 9110
Details

405 Method Not Allowed means that the target resource is known, but the HTTP method is not allowed for it. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • GET sent to a POST-only endpoint, DELETE on a non-deletable resource, or method mismatch in route configuration
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 405 Method Not Allowed, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return an Allow header listing supported methods.
  • Check frontend method, route definitions, CORS preflight behavior, and proxy method rewrites.
Avoid using it when
  • Do not mix 405 with 405, 400, 404, and 501; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 405 when the resource does not exist.
  • Do not return 405 without telling clients which methods are allowed.
Source: RFC 9110 Related codes: 400, 404, 501
406

Not Acceptable

The server cannot produce a representation acceptable to the client.

4xx Client error Standard Use with care RFC 9110
Details

406 Not Acceptable means that the client's Accept-related headers require a response format, language, charset, or encoding the server cannot provide. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • strict content negotiation, unsupported response formats, language negotiation, and API clients requesting unavailable media types
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 406 Not Acceptable, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Inspect Accept, Accept-Language, Accept-Encoding, and similar headers.
  • Document supported response media types.
Avoid using it when
  • Do not mix 406 with 406, 300, and 415; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 406 for invalid request body Content-Type.
  • Do not overuse 406 in simple APIs that always return JSON.
Source: RFC 9110 Related codes: 300, 415
407

Proxy Authentication Required

The client must authenticate with a proxy before the request can proceed.

4xx Client error Standard Not recommended RFC 9110
Details

407 Proxy Authentication Required means that a proxy server, not the origin server, requires authentication. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • enterprise proxies, forward proxies, network gateways, and corporate access layers
  • It appears when access fails and the client must distinguish authentication, authorization, proxy authentication, session expiry, and network login problems.
What to check
  • First confirm that the situation really matches the semantics of 407 Proxy Authentication Required, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Confirm the response came from a proxy rather than the origin server.
  • Check Proxy-Authenticate and Proxy-Authorization headers.
Avoid using it when
  • Do not mix 407 with 407, 401, and 403; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not return 407 from ordinary origin application code.
  • Do not confuse proxy authentication with website login.
Source: RFC 9110 Related codes: 401, 403
408

Request Timeout

The server timed out waiting for the client to send the complete request.

4xx Client error Standard Use with care RFC 9110
Details

408 Request Timeout means that the client did not send the full request quickly enough, or the connection stayed idle too long before completion. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • slow uploads, idle keep-alive connections, incomplete request bodies, and unstable client networks
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 408 Request Timeout, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check client network quality, upload speed, request body size, and timeout settings.
  • Servers may close the connection after sending 408.
Avoid using it when
  • Do not mix 408 with 408, 400, 499, and 504; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 408 for slow server processing.
  • Do not confuse 408 with Nginx 499, where the client closed the request.
Source: RFC 9110 Related codes: 400, 499, 504
409

Conflict

The request conflicts with the current state of the target resource.

4xx Client error Standard Recommended RFC 9110
Details

409 Conflict means that the server cannot complete the request because it would conflict with resource state, versioning, uniqueness, or concurrency rules. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • version conflicts, duplicate creation, invalid state transitions, concurrent updates, and uniqueness conflicts
  • It appears in API responses when the caller needs to fix input, resolve a conflict, or retry with a corrected request instead of blindly retrying the same payload.
What to check
  • First confirm that the situation really matches the semantics of 409 Conflict, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return enough detail to explain the conflicting field, version, state, or resource.
  • Use 412 when a conditional header such as If-Match failed.
Avoid using it when
  • Do not mix 409 with 409, 400, 412, 422, and 423; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 409 for every business error.
  • Do not return 409 without explaining how the conflict can be resolved.
Source: RFC 9110 Related codes: 400, 412, 422, 423
410

Gone

The resource used to exist but is now permanently unavailable.

4xx Client error Standard Recommended RFC 9110
Details

410 Gone means that the target resource is intentionally and permanently gone. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • removed articles, retired API endpoints, permanently deleted resources, expired campaigns, and removed downloads
  • It appears in websites, APIs, crawlers, and logs when a resource cannot be served and the caller must distinguish missing, permanently removed, hidden, or legally blocked content.
What to check
  • First confirm that the situation really matches the semantics of 410 Gone, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Use 410 when permanence matters to clients or search engines.
  • Provide an alternative link if a replacement resource exists.
Avoid using it when
  • Do not mix 410 with 410, 404, 301, and 451; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 410 for temporary outages.
  • Do not use 410 for resources that never existed.
  • Do not use 410 for legal blocking; 451 is clearer.
Source: RFC 9110 Related codes: 404, 301, 451
411

Length Required

The server requires a Content-Length header.

4xx Client error Standard Use with care RFC 9110
Details

411 Length Required means that the request has a body or expected body but does not provide the required length information. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • servers or gateways that do not accept chunked uploads, fixed-size upload APIs, and strict request body handling
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 411 Length Required, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Add a correct Content-Length header when sending a body.
  • Verify whether chunked transfer encoding is supported by the server and intermediaries.
Avoid using it when
  • Do not mix 411 with 411, 400, and 413; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not return 411 for requests without a body.
  • Do not use 411 when the body is too large; use 413.
Source: RFC 9110 Related codes: 400, 413
412

Precondition Failed

A condition in the request headers evaluated to false.

4xx Client error Standard Recommended RFC 9110
Details

412 Precondition Failed means that a conditional request failed, often because the client's resource version is stale. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • If-Match, If-Unmodified-Since, ETag optimistic locking, and lost-update prevention
  • It appears in API responses when the caller needs to fix input, resolve a conflict, or retry with a corrected request instead of blindly retrying the same payload.
What to check
  • First confirm that the situation really matches the semantics of 412 Precondition Failed, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check If-Match, If-None-Match, If-Unmodified-Since, and related conditional headers.
  • Fetch the latest resource representation and retry with the current ETag when appropriate.
Avoid using it when
  • Do not mix 412 with 412, 304, 409, and 428; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 412 for ordinary validation errors.
  • Do not return 412 without a conditional request context.
Source: RFC 9110 Related codes: 304, 409, 428
413

Content Too Large

The request content is larger than the server is willing to process.

4xx Client error Standard Recommended RFC 9110
Details

413 Content Too Large means that the request body or uploaded content exceeds server, gateway, framework, or policy limits. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • large file uploads, oversized JSON bodies, huge forms, reverse proxy body limits, and API payload caps
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 413 Content Too Large, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check client upload size, Nginx client_max_body_size, gateway limits, framework limits, and object storage limits.
  • Tell the client the maximum allowed size when possible.
Avoid using it when
  • Do not mix 413 with 413, 400, 411, 415, and 494; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 413 for invalid field formats.
  • Do not forget intermediary limits; the proxy may reject before the app sees the request.
Source: RFC 9110 Related codes: 400, 411, 415, 494
414

URI Too Long

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

4xx Client error Standard Recommended RFC 9110
Details

414 URI Too Long means that the URL, path, or query string is too long. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • too many query parameters, large data encoded into a GET URL, redirect loops, and generated URLs that exceed limits
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 414 URI Too Long, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Move large data from the URL into a POST body when appropriate.
  • Check for redirect loops or repeated query-string appends.
Avoid using it when
  • Do not mix 414 with 414, 400, 431, and 494; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 414 for oversized request bodies.
  • Do not use URLs to carry sensitive or massive payloads.
Source: RFC 9110 Related codes: 400, 431, 494
415

Unsupported Media Type

The request body media type or content encoding is not supported.

4xx Client error Standard Recommended RFC 9110
Details

415 Unsupported Media Type means that the server refuses the request because Content-Type, Content-Encoding, or uploaded format is unsupported. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • wrong Content-Type, XML sent to a JSON-only API, unsupported file formats, and unsupported compression
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 415 Unsupported Media Type, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check Content-Type, Content-Encoding, multipart boundaries, file MIME type, and upload format.
  • Document supported request media types.
Avoid using it when
  • Do not mix 415 with 415, 400, 406, and 422; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 415 for response content negotiation; that is closer to 406.
  • Do not use 415 for malformed JSON syntax when the media type is otherwise supported.
Source: RFC 9110 Related codes: 400, 406, 422
416

Range Not Satisfiable

The requested byte range cannot be served.

4xx Client error Standard Use with care RFC 9110
Details

416 Range Not Satisfiable means that the Range header asks for a portion of the resource that is invalid or outside the available representation. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • download resumption errors, video seeking beyond file length, stale cached file sizes, and invalid byte ranges
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 416 Range Not Satisfiable, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check the Range header and the current resource length.
  • Return Content-Range: */length when appropriate.
Avoid using it when
  • Do not mix 416 with 416, 200, 206, and 404; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 416 for ordinary pagination.
  • Do not return 416 when no Range request was made.
  • Do not use 416 when the resource itself does not exist.
Source: RFC 9110 Related codes: 200, 206, 404
417

Expectation Failed

The server cannot satisfy the expectation declared in the Expect header.

4xx Client error Standard Use with care RFC 9110
Details

417 Expectation Failed means that the server or an intermediary cannot meet the client's Expect header requirements. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • Expect: 100-continue rejection, unsupported expectation values, and early refusal of large uploads
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 417 Expectation Failed, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Inspect the Expect header.
  • If rejecting a large body for a specific reason, consider 401, 403, 413, or 415.
Avoid using it when
  • Do not mix 417 with 417, 100, 400, and 413; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 417 for ordinary business validation failures.
  • Do not return 417 when no Expect header is involved.
Source: RFC 9110 Related codes: 100, 400, 413
418

I'm a teapot

A humorous reserved status code from the HTCPCP tradition.

4xx Client error Reserved Not recommended RFC 9110
Details

418 I'm a teapot means that the server is, humorously, a teapot and refuses to brew coffee. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • developer easter eggs, documentation examples, test pages, and humorous error pages
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 418 I'm a teapot, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • If seen in production, verify whether it is an intentional easter egg, framework behavior, or misconfiguration.
  • Replace it with a real 4xx or 5xx for production API errors.
Avoid using it when
  • Do not mix 418 with 418, 400, and 501; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 418 as a real business error code.
  • Do not use 418 to mean a feature is not implemented; 501 is clearer.
Source: RFC 9110 Related codes: 400, 501
419

Page Expired

the page session, login session, or CSRF token has expired

4xx Client error Non-standard Use with care Laravel / Web framework convention
Details

419 Page Expired is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Laravel or a web framework convention. It usually indicates that the page session, login session, or CSRF token has expired. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Laravel or a web framework convention generates the code in a specific infrastructure or framework scenario.
  • A form submission uses an expired CSRF token.
  • A user leaves a page open for a long time and submits it later.
  • A login session expires while the frontend still sends old requests.
What to check
  • First determine whether the response was generated by Laravel or a web framework convention rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Refresh the page to obtain a new CSRF token.
  • Check session lifetime, cookies, SameSite behavior, cross-origin settings, and HTTPS configuration.
Avoid using it when
  • Do not use 419 for all authentication failures; standard authentication problems are closer to 401.
  • Do not expect third-party API clients to understand 419.
  • Do not present 419 as an RFC-standard status code; explain the product or server that generates it.
Source: Laravel / Web framework convention Related codes: 400, 401, 403, 440, 422
420

Enhance Your Calm

the client is sending too many requests or behaving aggressively

4xx Client error Non-standard Not recommended Twitter legacy API convention
Details

420 Enhance Your Calm is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Twitter legacy API convention. It usually indicates that the client is sending too many requests or behaving aggressively. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Twitter legacy API convention generates the code in a specific infrastructure or framework scenario.
  • A legacy API uses it as a rate-limit or abuse-protection signal.
  • A service-specific policy asks the client to slow down.
What to check
  • First determine whether the response was generated by Twitter legacy API convention rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Prefer 429 Too Many Requests in new APIs.
  • Reduce request frequency and inspect the response body for rate-limit details.
Avoid using it when
  • Do not use 420 in new public APIs.
  • Do not force clients to depend on this historical code.
  • Do not present 420 as an RFC-standard status code; explain the product or server that generates it.
Source: Twitter legacy API convention Related codes: 429, 403, 503
421

Misdirected Request

The request was sent to a server that cannot produce a response for the target authority.

4xx Client error Standard Use with care RFC 9110
Details

421 Misdirected Request means that the connection or routing layer delivered the request to the wrong authoritative server. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • HTTP/2 connection reuse, SNI mistakes, virtual hosts, reverse proxy routing errors, and multi-domain TLS setups
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 421 Misdirected Request, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check Host, SNI, TLS certificate coverage, HTTP/2 connection reuse, and proxy routing rules.
  • Clients may retry on a new connection for the correct origin.
Avoid using it when
  • Do not mix 421 with 421, 400, and 502; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 421 for ordinary missing routes.
  • Do not use 421 for authorization failures.
Source: RFC 9110 Related codes: 400, 502
422

Unprocessable Content

The request is syntactically valid but semantically invalid.

4xx Client error Standard Recommended RFC 9110
Details

422 Unprocessable Content means that the server understands the request format, but the submitted values or business rules cannot be processed. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • form validation failures, duplicate email, insufficient inventory, invalid field values, and business rule violations
  • It appears in API responses when the caller needs to fix input, resolve a conflict, or retry with a corrected request instead of blindly retrying the same payload.
What to check
  • First confirm that the situation really matches the semantics of 422 Unprocessable Content, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return field-level validation errors so the caller can correct the request.
  • Use 400 when the request cannot be parsed syntactically.
Avoid using it when
  • Do not mix 422 with 422, 400, 409, and 415; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 422 for malformed JSON.
  • Do not use 422 for authentication or permission failures.
  • Do not return 422 without actionable validation detail.
Source: RFC 9110 Related codes: 400, 409, 415
423

Locked

The target resource is locked and cannot be modified right now.

4xx Client error Standard Use with care RFC 4918
Details

423 Locked means that the requested resource is locked, often in WebDAV or collaborative editing contexts. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • WebDAV locks, document collaboration locks, file operation locks, and workflow locks
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 423 Locked, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return lock owner, timeout, or unlock instructions when safe.
  • Clients can retry later or ask the user who holds the lock.
Avoid using it when
  • Do not mix 423 with 423, 409, 424, and 507; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 423 for simple permission denial.
  • Do not use 423 when the system has no lock concept.
Source: RFC 4918 Related codes: 409, 424, 507
424

Failed Dependency

The request failed because a previous or dependent operation failed.

4xx Client error Standard Not recommended RFC 4918
Details

424 Failed Dependency means that a dependent action in the same WebDAV or batch operation did not succeed. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • WebDAV batch operations and multi-step resource operations where later actions depend on earlier ones
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 424 Failed Dependency, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Identify which dependency failed first.
  • Return enough detail for the client to fix the root failure before retrying.
Avoid using it when
  • Do not mix 424 with 424, 207, 409, and 423; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 424 for ordinary missing parameters.
  • Do not hide the true dependency failure.
Source: RFC 4918 Related codes: 207, 409, 423
425

Too Early

The server is unwilling to risk processing a request that might be replayed.

4xx Client error Standard Use with care RFC 8470
Details

425 Too Early means that the request may have been sent as TLS early data, and replaying it could be unsafe. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • TLS 0-RTT early data, non-idempotent requests, payments, orders, and create/update operations with side effects
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 425 Too Early, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Retry after a full handshake rather than early data.
  • Use it only when replay risk matters.
Avoid using it when
  • Do not mix 425 with 425, 400, 409, and 429; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 425 to mean the service is busy.
  • Do not use 425 for rate limiting; use 429.
Source: RFC 8470 Related codes: 400, 409, 429
426

Upgrade Required

The client must switch to a different protocol before the server will process the request.

4xx Client error Standard Use with care RFC 9110
Details

426 Upgrade Required means that the server refuses the request under the current protocol but may accept it after an upgrade. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • requiring TLS, HTTP/2, WebSocket, or another protocol capability
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 426 Upgrade Required, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Include an Upgrade header explaining what protocol is required.
  • Use 101 when the upgrade handshake succeeds.
Avoid using it when
  • Do not mix 426 with 426, 101, 400, and 505; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 426 as a normal redirect.
  • Do not return 426 without telling the client what to upgrade to.
Source: RFC 9110 Related codes: 101, 400, 505
428

Precondition Required

The server requires the request to be conditional.

4xx Client error Standard Recommended RFC 6585
Details

428 Precondition Required means that the server requires precondition headers to prevent lost updates or unsafe overwrites. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • ETag-based optimistic locking, If-Match requirements, and concurrency-safe updates
  • It appears in API responses when the caller needs to fix input, resolve a conflict, or retry with a corrected request instead of blindly retrying the same payload.
What to check
  • First confirm that the situation really matches the semantics of 428 Precondition Required, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Tell the client which precondition header is required.
  • Clients should fetch the current representation and retry with If-Match or similar headers.
Avoid using it when
  • Do not mix 428 with 428, 409, and 412; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 428 for normal validation errors.
  • Do not return 428 without explaining the required condition.
Source: RFC 6585 Related codes: 409, 412
429

Too Many Requests

The client has sent too many requests in a given period.

4xx Client error Standard Recommended RFC 6585
Details

429 Too Many Requests means that the server is rate limiting the client, user, IP, tenant, API key, or route. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • API rate limits, login throttling, SMS code limits, bot protection, crawler control, and tenant quota protection
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 429 Too Many Requests, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return Retry-After or rate limit headers when possible.
  • Clients should use exponential backoff rather than immediate retry loops.
Avoid using it when
  • Do not mix 429 with 429, 403, and 503; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 429 for general service outages; 503 is usually better.
  • Do not omit retry guidance when clients can retry later.
Source: RFC 6585 Related codes: 403, 503
430

Request Header Fields Too Large

request headers are too large or rejected by a platform-specific rule

4xx Client error Non-standard Not recommended Non-standard platform convention
Details

430 Request Header Fields Too Large is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with a non-standard platform convention. It usually indicates that request headers are too large or rejected by a platform-specific rule. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • a non-standard platform convention generates the code in a specific infrastructure or framework scenario.
  • A platform uses 430 for oversized Cookie, Authorization, or custom headers.
  • A security layer rejects the request before origin processing.
What to check
  • First determine whether the response was generated by a non-standard platform convention rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Reduce Cookie and header size.
  • Prefer standard 431 when possible.
Avoid using it when
  • Do not prefer 430 for new systems.
  • Do not use 430 for an oversized body.
  • Do not present 430 as an RFC-standard status code; explain the product or server that generates it.
Source: Non-standard platform convention Related codes: 400, 431, 494
431

Request Header Fields Too Large

One or more request header fields are too large.

4xx Client error Standard Recommended RFC 6585
Details

431 Request Header Fields Too Large means that the server refuses the request because headers are too large individually or in total. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • oversized cookies, too many custom headers, huge Authorization values, and tracing header growth
  • It appears when a request fails because the client, credentials, request format, resource state, or legal context needs to be corrected.
What to check
  • First confirm that the situation really matches the semantics of 431 Request Header Fields Too Large, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Reduce Cookie size, shorten headers, and remove unnecessary custom headers.
  • Check CDN, gateway, Nginx, and application header limits.
Avoid using it when
  • Do not mix 431 with 431, 400, 414, and 494; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 431 for oversized request bodies.
  • Do not let tracking or cookie data grow without limits.
Source: RFC 6585 Related codes: 400, 414, 494
440

Login Time-out

the login session timed out and the user must authenticate again

4xx Client error Non-standard Use with care Microsoft IIS
Details

440 Login Time-out is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Microsoft IIS or Exchange ecosystem. It usually indicates that the login session timed out and the user must authenticate again. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Microsoft IIS or Exchange ecosystem generates the code in a specific infrastructure or framework scenario.
  • An enterprise app session expires.
  • OWA, Exchange, or an internal portal requires re-login.
What to check
  • First determine whether the response was generated by Microsoft IIS or Exchange ecosystem rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Sign in again and refresh the session.
  • Check session lifetime, cookies, reverse proxy settings, and SSO configuration.
Avoid using it when
  • Do not treat 440 as standard HTTP authentication semantics.
  • Public APIs should generally use 401.
  • Do not present 440 as an RFC-standard status code; explain the product or server that generates it.
Source: Microsoft IIS Related codes: 401, 403, 419
444

No Response

Nginx closed the connection without sending a response

4xx Client error Non-standard Not recommended Nginx
Details

444 No Response is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Nginx. It usually indicates that Nginx closed the connection without sending a response. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Nginx generates the code in a specific infrastructure or framework scenario.
  • Nginx silently drops malicious traffic, scanners, invalid hosts, or requests matched by security rules.
  • A configuration uses return 444 to close connections.
What to check
  • First determine whether the response was generated by Nginx rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check Nginx configuration, server_name rules, WAF rules, and access logs.
  • Verify that legitimate clients, health checks, and crawlers are not accidentally blocked.
Avoid using it when
  • Do not return 444 from application code.
  • Do not treat 444 as an origin business error.
  • Do not accidentally block health checks, crawlers, or legitimate users.
Source: Nginx Related codes: 400, 403, 499
449

Retry With

the request needs additional information before retrying

4xx Client error Non-standard Not recommended Microsoft IIS
Details

449 Retry With is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Microsoft IIS extension. It usually indicates that the request needs additional information before retrying. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Microsoft IIS extension generates the code in a specific infrastructure or framework scenario.
  • A Microsoft-related service asks the client to retry with extra data.
  • A legacy system uses it for prerequisite information.
What to check
  • First determine whether the response was generated by Microsoft IIS extension rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Inspect the response body or platform documentation to learn what is missing.
  • Use 400, 401, or 428 in new APIs when possible.
Avoid using it when
  • Do not use 449 in new public APIs.
  • Do not leave callers guessing what to retry with.
  • Do not present 449 as an RFC-standard status code; explain the product or server that generates it.
Source: Microsoft IIS Related codes: 400, 401, 428
450

Blocked by Windows Parental Controls

access was blocked by Windows parental-control-like policy

4xx Client error Non-standard Not recommended Microsoft IIS
Details

450 Blocked by Windows Parental Controls is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Microsoft or Windows ecosystem. It usually indicates that access was blocked by Windows parental-control-like policy. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Microsoft or Windows ecosystem generates the code in a specific infrastructure or framework scenario.
  • A legacy local policy blocks access.
  • Enterprise or local safety controls prevent a request.
What to check
  • First determine whether the response was generated by Microsoft or Windows ecosystem rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check local OS policy, browser controls, enterprise policy, and security software.
  • Do not start debugging origin application code first.
Avoid using it when
  • Do not use 450 for legal blocking; use 451.
  • Do not use it in modern API designs.
  • Do not present 450 as an RFC-standard status code; explain the product or server that generates it.
Source: Microsoft IIS Related codes: 403, 451
451

Unavailable For Legal Reasons

The resource is unavailable because of a legal demand or legal restriction.

4xx Client error Standard Use with care RFC 7725
Details

451 Unavailable For Legal Reasons means that the server cannot provide the resource because access is blocked for legal reasons. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • copyright complaints, court orders, regulatory restrictions, regional legal blocking, and compliance takedowns
  • It appears in websites, APIs, crawlers, and logs when a resource cannot be served and the caller must distinguish missing, permanently removed, hidden, or legally blocked content.
What to check
  • First confirm that the situation really matches the semantics of 451 Unavailable For Legal Reasons, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Explain the legal reason, affected region, or appeal path when appropriate and safe.
  • Use 404 if revealing the resource's existence would be inappropriate.
Avoid using it when
  • Do not mix 451 with 451, 403, 404, and 410; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 451 for ordinary permissions.
  • Do not use 451 to hide technical failures.
Source: RFC 7725 Related codes: 403, 404, 410
460

Client Closed Connection

the client closed the connection before the load balancer returned a response

4xx Client error Non-standard Not recommended AWS Elastic Load Balancing
Details

460 Client Closed Connection is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with AWS Elastic Load Balancing. It usually indicates that the client closed the connection before the load balancer returned a response. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • AWS Elastic Load Balancing generates the code in a specific infrastructure or framework scenario.
  • A browser, mobile app, or API client disconnects before ALB responds.
  • Client timeout is shorter than backend processing time.
What to check
  • First determine whether the response was generated by AWS Elastic Load Balancing rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Inspect ALB access logs and timing fields.
  • Review frontend timeouts, mobile network behavior, and backend latency.
Avoid using it when
  • Do not treat 460 as an origin application response.
  • Do not ignore ALB logs when debugging it.
  • Do not present 460 as an RFC-standard status code; explain the product or server that generates it.
Source: AWS Elastic Load Balancing Related codes: 408, 499, 504
463

Too Many IP Addresses

forwarded IP headers contain too many addresses

4xx Client error Non-standard Not recommended AWS Elastic Load Balancing
Details

463 Too Many IP Addresses is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with AWS Elastic Load Balancing. It usually indicates that forwarded IP headers contain too many addresses. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • AWS Elastic Load Balancing generates the code in a specific infrastructure or framework scenario.
  • X-Forwarded-For grows too long through many proxies.
  • A client or intermediary pollutes forwarded IP headers.
What to check
  • First determine whether the response was generated by AWS Elastic Load Balancing rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Clean up forwarding chains and limit header growth.
  • Check whether proxies append X-Forwarded-For repeatedly.
Avoid using it when
  • Do not treat it as a normal parameter validation error.
  • Do not ignore possible header injection.
  • Do not present 463 as an RFC-standard status code; explain the product or server that generates it.
Source: AWS Elastic Load Balancing Related codes: 400, 431, 494
464

Incompatible Protocols

the client, load balancer, and target group protocols are incompatible

4xx Client error Non-standard Not recommended AWS Elastic Load Balancing
Details

464 Incompatible Protocols is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with AWS Elastic Load Balancing. It usually indicates that the client, load balancer, and target group protocols are incompatible. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • AWS Elastic Load Balancing generates the code in a specific infrastructure or framework scenario.
  • ALB, target group, HTTP/1, HTTP/2, gRPC, or TLS settings do not match.
  • A backend listener expects a different protocol.
What to check
  • First determine whether the response was generated by AWS Elastic Load Balancing rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Review listener protocol, target group protocol version, and backend service protocol.
  • Confirm gRPC, HTTP/2, and TLS settings are consistent.
Avoid using it when
  • Do not misdiagnose it as an origin 500.
  • Do not fix only application code while ALB config is wrong.
  • Do not present 464 as an RFC-standard status code; explain the product or server that generates it.
Source: AWS Elastic Load Balancing Related codes: 400, 426, 502
494

Request Header Too Large

Nginx rejected the request because headers were too large

4xx Client error Non-standard Not recommended Nginx
Details

494 Request Header Too Large is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Nginx. It usually indicates that Nginx rejected the request because headers were too large. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Nginx generates the code in a specific infrastructure or framework scenario.
  • Cookies, request headers, or the request line exceed Nginx limits.
  • A browser sends bloated cookies to the site.
What to check
  • First determine whether the response was generated by Nginx rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Reduce Cookie and header size.
  • Review large_client_header_buffers and related Nginx configuration.
Avoid using it when
  • Do not confuse it with standard 431; document the relationship if exposing it.
  • Do not use 494 for oversized request bodies.
  • Do not present 494 as an RFC-standard status code; explain the product or server that generates it.
Source: Nginx Related codes: 400, 431, 414
495

SSL Certificate Error

Nginx encountered an error while validating the client certificate

4xx Client error Non-standard Not recommended Nginx
Details

495 SSL Certificate Error is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Nginx. It usually indicates that Nginx encountered an error while validating the client certificate. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Nginx generates the code in a specific infrastructure or framework scenario.
  • Mutual TLS client certificate validation fails.
  • Certificate chain, CA, expiration, or signature validation is wrong.
What to check
  • First determine whether the response was generated by Nginx rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check client certificate, CA bundle, certificate chain, and ssl_client_certificate settings.
  • Confirm whether mTLS is required.
Avoid using it when
  • Do not confuse it with Cloudflare 526.
  • Do not use it for ordinary login failure.
  • Do not present 495 as an RFC-standard status code; explain the product or server that generates it.
Source: Nginx Related codes: 401, 403, 496, 526
496

SSL Certificate Required

Nginx required a client certificate but none was provided

4xx Client error Non-standard Not recommended Nginx
Details

496 SSL Certificate Required is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Nginx. It usually indicates that Nginx required a client certificate but none was provided. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Nginx generates the code in a specific infrastructure or framework scenario.
  • An mTLS endpoint requires a client certificate.
  • The browser or HTTP client did not present a certificate.
What to check
  • First determine whether the response was generated by Nginx rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Configure the client certificate correctly.
  • Check ssl_verify_client and related Nginx TLS settings.
Avoid using it when
  • Do not use 496 for missing bearer tokens.
  • Do not use it outside mTLS contexts.
  • Do not present 496 as an RFC-standard status code; explain the product or server that generates it.
Source: Nginx Related codes: 401, 403, 495
497

HTTP Request Sent to HTTPS Port

plain HTTP was sent to an HTTPS port

4xx Client error Non-standard Not recommended Nginx
Details

497 HTTP Request Sent to HTTPS Port is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Nginx. It usually indicates that plain HTTP was sent to an HTTPS port. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Nginx generates the code in a specific infrastructure or framework scenario.
  • A user or proxy sends http:// traffic to a TLS-only listener.
  • A load balancer or proxy has protocol mismatch.
What to check
  • First determine whether the response was generated by Nginx rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Use https:// for the request.
  • Check port, listener, TLS termination, and redirect configuration.
Avoid using it when
  • Do not treat 497 as application business logic.
  • Do not simulate it in backend code.
  • Do not present 497 as an RFC-standard status code; explain the product or server that generates it.
Source: Nginx Related codes: 400, 426, 301
498

Invalid Token

a token is invalid, expired, or not accepted

4xx Client error Non-standard Use with care Esri ArcGIS
Details

498 Invalid Token is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Esri ArcGIS or a custom API convention. It usually indicates that a token is invalid, expired, or not accepted. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Esri ArcGIS or a custom API convention generates the code in a specific infrastructure or framework scenario.
  • ArcGIS or a gateway rejects the token.
  • Token signature, expiration, environment, or permission scope is wrong.
What to check
  • First determine whether the response was generated by Esri ArcGIS or a custom API convention rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Obtain a fresh token.
  • Check signing keys, expiration time, clock skew, and scopes.
Avoid using it when
  • Public APIs usually should use 401 or 403.
  • Do not use 498 for unrelated validation errors.
  • Do not present 498 as an RFC-standard status code; explain the product or server that generates it.
Source: Esri ArcGIS Related codes: 401, 403, 419
499

Client Closed Request

the client closed the request before the server responded

4xx Client error Non-standard Not recommended Nginx
Details

499 Client Closed Request is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Nginx. It usually indicates that the client closed the request before the server responded. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Nginx generates the code in a specific infrastructure or framework scenario.
  • A user closes the page, a browser cancels the request, frontend code aborts it, or mobile networking drops.
  • Nginx is waiting on upstream when the client disconnects.
What to check
  • First determine whether the response was generated by Nginx rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Inspect Nginx access logs, request_time, upstream_response_time, and frontend timeout settings.
  • Optimize slow endpoints so clients do not cancel them prematurely.
Avoid using it when
  • Do not treat 499 as a server-generated response to the client.
  • Do not rely only on backend error logs; the application may not have thrown an error.
  • Do not ignore frontend request cancellation, client timeouts, or users closing the page.
Source: Nginx Related codes: 408, 460, 504

5xx Server error

Server-side or gateway failures involving application errors, upstream services, proxies, CDNs, DNS, TLS, overload, maintenance, or timeout conditions.

500

Internal Server Error

The server encountered an unexpected internal failure.

5xx Server error Standard Recommended RFC 9110
Details

500 Internal Server Error means that the server failed while processing the request and does not have a more specific 5xx response. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • uncaught exceptions, application crashes, template failures, dependency errors, and unexpected backend failures
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 500 Internal Server Error, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Inspect server logs, stack traces, trace IDs, recent deployments, and dependency changes.
  • Convert expected business errors to clear 4xx responses instead of throwing generic 500s.
Avoid using it when
  • Do not use 500 for client input mistakes.
  • Do not expose stack traces, connection strings, or secrets in production responses.
  • Do not use 500 as a permanent catch-all for predictable errors.
Source: RFC 9110 Related codes: 502, 503, 504, 400, 422
501

Not Implemented

The server does not support the functionality required to fulfill the request.

5xx Server error Standard Recommended RFC 9110
Details

501 Not Implemented means that the server lacks support for the method, feature, or protocol capability needed by the request. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • unsupported HTTP methods, unimplemented protocol features, and server capabilities that do not exist
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 501 Not Implemented, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Confirm whether the entire server lacks the capability, not just the target resource.
  • Use 405 when a specific resource does not allow the method.
Avoid using it when
  • Do not mix 501 with 501, 405, 426, and 505; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 501 for ordinary business features that are disabled or hidden.
  • Do not use 501 for authorization failures.
Source: RFC 9110 Related codes: 405, 426, 505
502

Bad Gateway

A gateway or proxy received an invalid response from an upstream server.

5xx Server error Standard Recommended RFC 9110
Details

502 Bad Gateway means that an intermediary could not get a valid HTTP response from the upstream service. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • reverse proxies, API gateways, CDNs, service meshes, and load balancers receiving invalid upstream responses
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 502 Bad Gateway, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check origin service health, upstream logs, proxy logs, protocol mismatch, TLS, ports, and response headers.
  • Determine whether the app crashed, closed the connection early, or returned malformed headers.
Avoid using it when
  • Do not label every backend failure as 502.
  • Do not confuse 502 with 504; 504 is a timeout.
  • Do not debug only the browser error page; inspect gateway and origin logs.
Source: RFC 9110 Related codes: 500, 503, 504, 521, 522
503

Service Unavailable

The service is temporarily unable to handle the request.

5xx Server error Standard Recommended RFC 9110
Details

503 Service Unavailable means that the server is overloaded, under maintenance, temporarily unavailable, or protecting itself. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • maintenance windows, overload, capacity exhaustion, circuit breakers, dependency outages, and temporary throttling
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 503 Service Unavailable, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Return Retry-After when possible.
  • Check instance capacity, queues, thread pools, connection pools, databases, and downstream services.
Avoid using it when
  • Do not use 503 for permanently removed resources.
  • Do not use 503 for per-user rate limiting; 429 is clearer.
  • Do not return 503 for long periods without a recovery plan.
Source: RFC 9110 Related codes: 500, 502, 504, 429
504

Gateway Timeout

A gateway or proxy timed out waiting for an upstream server.

5xx Server error Standard Recommended RFC 9110
Details

504 Gateway Timeout means that an intermediary connected to an upstream service but did not receive a timely response. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • slow upstream APIs, slow database queries, blocked service chains, proxy read timeouts, and long-running requests
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 504 Gateway Timeout, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check gateway timeout settings, upstream latency, slow queries, and distributed traces.
  • Move long-running work to a 202 Accepted asynchronous flow when appropriate.
Avoid using it when
  • Do not use 504 for slow client uploads; 408 is closer.
  • Do not use 504 for invalid upstream responses; 502 is closer.
  • Do not just increase timeouts without fixing slow work.
Source: RFC 9110 Related codes: 408, 502, 503, 524
505

HTTP Version Not Supported

The server does not support the HTTP version used by the request.

5xx Server error Standard Use with care RFC 9110
Details

505 HTTP Version Not Supported means that the client used an HTTP version the server refuses or cannot support. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • unsupported HTTP/1.0, HTTP/2, HTTP/3, ALPN, or protocol-version mismatches
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 505 HTTP Version Not Supported, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check client protocol version, TLS ALPN, proxy configuration, and server protocol support.
  • Use 426 when an upgrade path is available.
Avoid using it when
  • Do not mix 505 with 505, 400, 426, and 501; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 505 for API versioning problems.
  • Do not use 505 for TLS handshake failures.
Source: RFC 9110 Related codes: 400, 426, 501
506

Variant Also Negotiates

The server has a content negotiation configuration loop.

5xx Server error Standard Not recommended RFC 2295
Details

506 Variant Also Negotiates means that the selected variant resource is itself configured to perform negotiation, causing a negotiation problem. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • transparent content negotiation misconfiguration and variant-resource loops
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 506 Variant Also Negotiates, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check content negotiation configuration and variant resource mappings.
  • Ensure variant resources do not point back into negotiation recursively.
Avoid using it when
  • Do not mix 506 with 506, 300, and 500; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 506 for ordinary Accept header mismatches; use 406.
  • Do not use 506 for business errors.
Source: RFC 2295 Related codes: 300, 500
507

Insufficient Storage

The server lacks enough storage to complete the request.

5xx Server error Standard Use with care RFC 4918
Details

507 Insufficient Storage means that the server cannot store the representation needed to complete the operation. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • WebDAV uploads, file writes, disk exhaustion, object storage quota, and user storage limits
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 507 Insufficient Storage, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Check disk space, temporary directories, object storage quota, and user quota.
  • Explain whether the limit is system-wide or user-specific.
Avoid using it when
  • Do not mix 507 with 507, 413, 423, and 500; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 507 for every write failure.
  • Do not use 507 when storage is not involved.
Source: RFC 4918 Related codes: 413, 423, 500
508

Loop Detected

The server detected a loop while processing the request.

5xx Server error Standard Not recommended RFC 5842
Details

508 Loop Detected means that the server found an infinite loop in resource bindings or traversal. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • WebDAV binding loops, recursive directory traversal, resource reference cycles, and collection processing loops
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 508 Loop Detected, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • Inspect WebDAV bindings, symbolic links, recursive traversal, and resource graph references.
  • Stop processing the loop and return diagnostic information.
Avoid using it when
  • Do not mix 508 with 508, 207, 208, and 500; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 508 for ordinary code infinite loops; application crashes are usually 500.
  • Do not use 508 without resource-loop semantics.
Source: RFC 5842 Related codes: 207, 208, 500
509

Bandwidth Limit Exceeded

the site or account exceeded a bandwidth quota

5xx Server error Non-standard Not recommended Apache/cPanel hosting convention
Details

509 Bandwidth Limit Exceeded is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Apache/cPanel hosting convention. It usually indicates that the site or account exceeded a bandwidth quota. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Apache/cPanel hosting convention generates the code in a specific infrastructure or framework scenario.
  • A shared hosting account exceeds monthly bandwidth.
  • A plan, tenant, or site traffic quota is exhausted.
What to check
  • First determine whether the response was generated by Apache/cPanel hosting convention rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check hosting control panel limits, CDN traffic, and abnormal crawler traffic.
  • Upgrade plan, enable caching, or block abusive traffic.
Avoid using it when
  • Do not treat 509 as a standard status code.
  • Use 429 for ordinary rate limiting.
  • Do not present 509 as an RFC-standard status code; explain the product or server that generates it.
Source: Apache/cPanel hosting convention Related codes: 429, 503, 507
510

Not Extended

The request lacks required extension information; this status code is obsolete in practice.

5xx Server error Deprecated Not recommended RFC 2774
Details

510 Not Extended means that the server expects extension information from an old HTTP extension framework. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • legacy HTTP extension mechanisms and historical compatibility notes
  • It appears in monitoring, gateway logs, or error pages when the failure is closer to the server or infrastructure layer than to ordinary user input.
What to check
  • First confirm that the situation really matches the semantics of 510 Not Extended, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • If found in old systems, investigate the extension framework being used.
  • Modern APIs should use clearer 400, 401, 403, 415, 422, or 501 responses.
Avoid using it when
  • Do not mix 510 with 510, 400, and 501; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 510 in new APIs.
  • Do not use 510 for ordinary missing parameters.
Source: RFC 2774 Related codes: 400, 501
511

Network Authentication Required

The client must authenticate to the network before accessing the origin.

5xx Server error Standard Not recommended RFC 6585
Details

511 Network Authentication Required means that network access authentication is required before normal internet access is available. A useful response should let the HTTP status code describe the protocol-level result, while the response body can carry a stable application error code, field-level validation details, trace ID, retry instruction, or documentation link.

Common situations
  • public Wi-Fi captive portals, hotel networks, enterprise network login, and campus network access
  • It appears when access fails and the client must distinguish authentication, authorization, proxy authentication, session expiry, and network login problems.
What to check
  • First confirm that the situation really matches the semantics of 511 Network Authentication Required, instead of using it as a generic catch-all status.
  • Inspect the request method, URL, headers, body, authentication context, resource state, cache validators, upstream services, and server logs to find the direct cause.
  • For APIs, return a response body with a stable application error code, human-readable message, field-level details when relevant, and a trace ID for debugging.
  • If the response passed through a CDN, reverse proxy, API gateway, or load balancer, compare origin logs with intermediary logs to determine which layer generated the status code.
  • The user usually needs to open a network login page.
  • This is generated by the network access layer, not the origin website.
Avoid using it when
  • Do not mix 511 with 511, 401, 407, and 403; doing so makes client behavior, caching, retries, redirects, SEO, and incident analysis less reliable.
  • Do not use 511 for website login failures; use 401 or 403.
  • Do not use 511 for proxy authentication; use 407.
Source: RFC 6585 Related codes: 401, 407, 403
520

Web Server Returned an Unknown Error

Cloudflare received an empty, unknown, or unclassifiable response from the origin

5xx Server error Non-standard Not recommended Cloudflare
Details

520 Web Server Returned an Unknown Error is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare received an empty, unknown, or unclassifiable response from the origin. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • Cloudflare can reach the origin, but the origin response is abnormal.
  • The origin resets the connection, sends malformed headers, or returns an empty response.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Use the Cloudflare Ray ID and origin logs together.
  • Check origin crashes, WAF rules, oversized headers, and premature connection closes.
Avoid using it when
  • Do not treat 520 as a standard 500.
  • Do not debug only the Cloudflare error page; use the Ray ID and origin logs together.
  • Do not ignore empty origin responses, malformed headers, or early connection closes.
Source: Cloudflare Related codes: 500, 502, 521, 522
521

Web Server Is Down

Cloudflare cannot connect to the origin web server

5xx Server error Non-standard Not recommended Cloudflare
Details

521 Web Server Is Down is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare cannot connect to the origin web server. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • The origin service is stopped, the port is not listening, or a firewall refuses Cloudflare IPs.
  • The origin is online but blocks Cloudflare.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Confirm that ports 80/443 are listening.
  • Allow Cloudflare IP ranges in firewall, security group, and origin network rules.
Avoid using it when
  • Do not treat 521 as a DNS problem.
  • Do not only restart the app; check ports, firewall rules, and Cloudflare IP allowlists.
  • Do not ignore whether the origin is actually listening on 80 or 443.
Source: Cloudflare Related codes: 502, 503, 522, 523
522

Connection Timed Out

Cloudflare timed out while connecting to the origin

5xx Server error Non-standard Not recommended Cloudflare
Details

522 Connection Timed Out is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare timed out while connecting to the origin. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • Cloudflare cannot complete the connection to origin in time.
  • The origin is overloaded, dropping packets, or blocked by firewall rules.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check origin load, packet loss, firewall, security groups, and connection limits.
  • Confirm Cloudflare IPs are not rate-limited or blocked.
Avoid using it when
  • Do not confuse 522 with 524; 522 is a connection-stage timeout.
  • Do not expect application logs when the connection never reaches the app.
  • Do not ignore firewall drops, security groups, packet loss, or origin overload.
Source: Cloudflare Related codes: 502, 504, 521, 524
523

Origin Is Unreachable

Cloudflare cannot reach the origin network

5xx Server error Non-standard Not recommended Cloudflare
Details

523 Origin Is Unreachable is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare cannot reach the origin network. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • The origin IP is unreachable, routing is broken, DNS points to the wrong place, or network access fails.
  • Cloudflare cannot reach the origin address from its network.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Verify DNS records and origin IP addresses.
  • Check public routing, firewalls, cloud networking, and ISP reachability.
Avoid using it when
  • Do not treat 523 as application code failure.
  • Do not confuse it with 530; 530 is more about origin hostname resolution.
  • Do not ignore DNS targets and public route reachability.
Source: Cloudflare Related codes: 502, 521, 522, 530
524

A Timeout Occurred

Cloudflare connected to the origin but did not receive an HTTP response in time

5xx Server error Non-standard Not recommended Cloudflare
Details

524 A Timeout Occurred is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare connected to the origin but did not receive an HTTP response in time. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • The origin accepted the connection but took too long to respond.
  • Long queries, exports, slow APIs, backend blocking, or heavy reports exceed Cloudflare timeouts.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Optimize slow requests or convert them to asynchronous jobs.
  • Check origin application logs, database slow queries, and Cloudflare timeout limits.
Avoid using it when
  • Do not confuse 524 with 522; Cloudflare already connected to the origin.
  • Do not merely extend timeouts without optimizing the slow endpoint.
  • Do not keep long-running work synchronous if a 202 async flow would be safer.
Source: Cloudflare Related codes: 504, 522, 503, 202
525

SSL Handshake Failed

Cloudflare could not complete a TLS handshake with the origin

5xx Server error Non-standard Not recommended Cloudflare
Details

525 SSL Handshake Failed is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare could not complete a TLS handshake with the origin. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • Origin TLS configuration is broken.
  • SNI, cipher suites, protocol versions, or certificate chain cause handshake failure.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check origin certificate, TLS versions, SNI, cipher suites, and Cloudflare SSL/TLS mode.
  • Use curl or openssl from outside to test origin TLS.
Avoid using it when
  • Do not treat 525 as a browser-to-Cloudflare certificate problem.
  • Do not confuse it with 526; 526 is certificate validation failure.
  • Do not ignore SNI, TLS versions, and cipher suites.
Source: Cloudflare Related codes: 502, 526, 495
526

Invalid SSL Certificate

Cloudflare could not validate the origin certificate

5xx Server error Non-standard Not recommended Cloudflare
Details

526 Invalid SSL Certificate is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare could not validate the origin certificate. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • In Full Strict mode, the origin certificate is expired, self-signed, hostname-mismatched, or has an invalid chain.
  • The certificate does not cover the proxied hostname.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Renew or replace the origin certificate.
  • Fix the certificate chain and SAN names.
Avoid using it when
  • Do not treat 526 as a user-browser certificate error.
  • Do not permanently lower TLS security to hide the issue.
  • Do not use expired, self-signed, or hostname-mismatched origin certificates in strict mode.
Source: Cloudflare Related codes: 525, 495, 403
527

Railgun Error

Cloudflare Railgun encountered an origin connection or protocol error

5xx Server error Non-standard Not recommended Cloudflare
Details

527 Railgun Error is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare Railgun. It usually indicates that Cloudflare Railgun encountered an origin connection or protocol error. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare Railgun generates the code in a specific infrastructure or framework scenario.
  • A site using Cloudflare Railgun has Railgun Listener or origin connection problems.
  • Railgun configuration or the origin link fails.
What to check
  • First determine whether the response was generated by Cloudflare Railgun rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check Railgun Listener status, Cloudflare configuration, and origin network.
  • Remove stale Railgun configuration if the feature is no longer used.
Avoid using it when
  • Do not treat 527 as a normal origin 500.
  • Sites not using Railgun should not normally see it.
  • Do not present 527 as an RFC-standard status code; explain the product or server that generates it.
Source: Cloudflare Related codes: 502, 523, 524
530

Origin DNS Error

Cloudflare cannot resolve the origin hostname or has an origin DNS problem

5xx Server error Non-standard Not recommended Cloudflare
Details

530 Origin DNS Error is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Cloudflare. It usually indicates that Cloudflare cannot resolve the origin hostname or has an origin DNS problem. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Cloudflare generates the code in a specific infrastructure or framework scenario.
  • Cloudflare cannot resolve the configured origin hostname.
  • The response body may include a Cloudflare 1xxx error code for more detail.
What to check
  • First determine whether the response was generated by Cloudflare rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check Cloudflare DNS records, CNAME targets, origin hostnames, DNSSEC, and resolver behavior.
  • Use the Cloudflare 1xxx error in the body to narrow the cause.
Avoid using it when
  • Do not treat 530 as standard HTTP semantics.
  • Do not confuse it with 523, which is more about network reachability.
  • Do not ignore Cloudflare 1xxx details in the response body.
Source: Cloudflare Related codes: 523, 521, 522
561

Unauthorized

AWS load balancer authentication failed or could not complete

5xx Server error Non-standard Not recommended AWS Elastic Load Balancing
Details

561 Unauthorized is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with AWS Elastic Load Balancing. It usually indicates that AWS load balancer authentication failed or could not complete. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • AWS Elastic Load Balancing generates the code in a specific infrastructure or framework scenario.
  • ALB authentication with OIDC, Cognito, or another identity provider fails.
  • The load balancer cannot complete the authentication flow before forwarding to the target.
What to check
  • First determine whether the response was generated by AWS Elastic Load Balancing rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check ALB authentication configuration, IdP settings, callback URLs, client secrets, and tokens.
  • Compare ALB logs with identity provider logs.
Avoid using it when
  • Do not treat 561 as standard 401.
  • Do not debug only origin code when authentication fails at ALB.
  • Do not present 561 as an RFC-standard status code; explain the product or server that generates it.
Source: AWS Elastic Load Balancing Related codes: 401, 403, 511
598

Network Read Timeout Error

a proxy or client timed out while reading the upstream response

5xx Server error Non-standard Not recommended Proxy / Gateway convention
Details

598 Network Read Timeout Error is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Proxy / Gateway convention. It usually indicates that a proxy or client timed out while reading the upstream response. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Proxy / Gateway convention generates the code in a specific infrastructure or framework scenario.
  • A proxy or client library connected to upstream but did not receive a full response in time.
  • The upstream service is slow after the connection is established.
What to check
  • First determine whether the response was generated by Proxy / Gateway convention rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check upstream response time, read timeout, proxy timeout, and long-running request design.
  • Move long work to asynchronous processing when possible.
Avoid using it when
  • Do not treat 598 as an IANA standard status code.
  • Do not confuse it with 599, which is usually a connect timeout.
  • Do not only increase read timeouts without understanding why upstream is slow.
Source: Proxy / Gateway convention Related codes: 504, 524, 599
599

Network Connect Timeout Error

a proxy or client timed out while connecting to upstream

5xx Server error Non-standard Not recommended Proxy / Gateway convention
Details

599 Network Connect Timeout Error is not an IANA-registered standard HTTP status code. It is a non-standard code or implementation-specific extension associated with Proxy / Gateway convention. It usually indicates that a proxy or client timed out while connecting to upstream. However, they should not be treated as portable REST API contracts. Different browsers, HTTP clients, monitoring tools, crawlers, and intermediaries may not understand them consistently.

Common situations
  • Proxy / Gateway convention generates the code in a specific infrastructure or framework scenario.
  • A proxy or client library cannot connect to the upstream within its timeout.
  • DNS, routing, firewall, security group, port, or origin health may be wrong.
What to check
  • First determine whether the response was generated by Proxy / Gateway convention rather than the origin application.
  • Compare origin application logs with CDN, gateway, proxy, load balancer, and web server logs.
  • Check DNS, TLS, request header size, connection timeouts, origin health, firewall rules, WAF behavior, upstream routing, and proxy forwarding rules.
  • For public APIs, consider mapping this condition to a standard status code and keeping the implementation-specific reason in the response body or logs.
  • Check DNS, routing, firewall, security groups, port listeners, and upstream health.
  • Inspect proxy logs to confirm the timeout happened during connection rather than reading.
Avoid using it when
  • Do not treat 599 as an IANA standard status code.
  • Do not confuse it with 598 or 504.
  • Do not debug application logic before confirming that the upstream connection was established.
Source: Proxy / Gateway convention Related codes: 502, 522, 598

What this HTTP status code reference covers

The page is built for day-to-day API debugging and production incident review, not just memorizing numeric codes. Each entry combines protocol meaning with practical context so the same reference works for frontend developers, backend engineers, QA, SRE, SEO audits, and API documentation.

  • Standard and extended status codes

    Includes common RFC-defined status codes plus widely seen extension and vendor codes from WebDAV, Nginx, Cloudflare, AWS load balancers, Microsoft/IIS conventions, proxy gateways, and resumable upload drafts.

  • Searchable troubleshooting context

    Search works across code number, English phrase, category, summary, source, related codes, common situations, fixes, and avoid-when guidance, so queries like “cache”, “CORS”, “timeout”, “WebSocket”, or “rate limit” can lead to the right entry.

  • API design recommendations

    Each status code includes a recommendation level that helps separate codes that are safe for public REST or JSON APIs from codes that should usually remain internal, vendor-specific, or handled by infrastructure.

  • Operational and SEO impact

    Redirects, soft errors, crawler-facing 404/410 behavior, gateway failures, 429 rate limits, and 5xx outages are explained in terms that help teams debug both user-facing pages and automated clients.

How to use this HTTP status lookup

Use the reference while inspecting browser DevTools, server logs, API responses, CDN dashboards, load balancer logs, crawler reports, or monitoring alerts.

  1. 1

    Search for the numeric code, reason phrase, vendor name, or symptom you see in logs or network tools.

  2. 2

    Use the status class filters to narrow the table when you already know whether the response is informational, successful, redirected, client-side, or server-side.

  3. 3

    Open the matching entry and read the summary first, then check common situations to identify the layer that most likely generated the response.

  4. 4

    Compare related codes before changing an API contract; many common mistakes come from using 200, 400, 401, 403, 404, 409, 422, 429, 500, 502, 503, and 504 interchangeably.

  5. 5

    Use the source and lifecycle labels to decide whether a code is portable enough for public documentation or should stay as infrastructure detail.

Key details included for every status code

The entries are structured for fast reading during real debugging work and detailed enough for API documentation and internal engineering notes.

  • Official code number, reason phrase, and status class.
  • Short summary for quick lookup and longer explanation for deeper debugging.
  • Common situations where the status code appears in APIs, browsers, CDNs, gateways, proxies, and server logs.
  • Concrete checks and remediation steps for client requests, backend services, routing, authentication, caching, redirects, and infrastructure layers.
  • Avoid-when notes that call out misleading or overused status codes.
  • Related status codes to compare before changing implementation behavior.
  • Lifecycle and source information for standard, deprecated, temporary, vendor-specific, and implementation-specific codes.

Common use cases

This page is useful whenever a status code appears in a response, log line, SEO report, uptime alert, API test, SDK error, or reverse proxy dashboard.

  • REST API and JSON API design

    Choose the right status code for create, update, validation, authentication, authorization, conflict, rate limit, async job, and empty-response flows.

  • Frontend and browser debugging

    Understand redirects, CORS-like failures, authentication challenges, precondition errors, cache revalidation, WebSocket upgrades, and failed asset loads from the Network panel.

  • SEO and crawl diagnostics

    Review 301, 302, 307, 308, 404, 410, 429, 500, 503, soft-error behavior, redirect chains, unavailable pages, and crawler-visible server errors.

  • CDN, gateway, and load balancer incidents

    Separate origin errors from Cloudflare, Nginx, AWS ALB, proxy timeout, TLS, DNS, and upstream reachability conditions before changing application code.

HTTP status code best practices

A status code should describe the protocol-level result clearly. Response bodies can add application-specific error codes, field messages, trace IDs, retry hints, and support links.

  • Do not return 200 for application errors just because the server produced a JSON body.
  • Use 201 for newly created resources, 202 for accepted asynchronous work, and 204 when the operation succeeded but the response has no body.
  • Use 400 for malformed requests, 401 for missing or invalid authentication, 403 for authenticated but forbidden access, 404 for not found, 409 for state conflicts, and 422 for semantically invalid input when that distinction is useful.
  • Use 429 for rate limits and include retry guidance when the client can safely wait and try again.
  • Avoid exposing non-standard vendor codes as public API contracts unless callers explicitly need that infrastructure detail.
  • For public websites, ensure error pages return the correct status code so search engines do not index soft 404s or temporary outage pages as normal content.

Limitations and interpretation notes

HTTP status codes are standardized protocol signals, but the exact cause still depends on the route, request method, headers, response body, cache layer, proxy chain, and server logs.

  • A status code alone rarely proves which service generated the response; compare application logs with CDN, gateway, proxy, load balancer, and origin logs.
  • Some vendor and implementation-specific codes are useful in operations dashboards but are not portable HTTP semantics.
  • Browsers, API clients, crawlers, and SDKs may handle redirects, authentication challenges, caching, and interim responses differently.
  • For final API behavior, document both the HTTP status code and the structured response body so callers can make stable decisions.

HTTP status code FAQ

Answers to common questions about usage, data handling, result checks, and practical limits.

01

What is the difference between 401 and 403?

401 means the request lacks valid authentication or needs an authentication challenge. 403 means the server understood who the caller is, or at least understood the request, but refuses the action because the caller is not allowed to access that resource.

02

Should an API return 400 or 422 for validation errors?

Use 400 when the request is malformed or cannot be parsed. Use 422 when the syntax is valid but the submitted values fail business or semantic validation. Many teams choose one convention and document it consistently.

03

When should a website use 404 versus 410?

Use 404 when a resource is not found or the server does not want to reveal whether it exists. Use 410 when the resource is intentionally gone and that condition is expected to be permanent, which can be clearer for crawlers and clients.

04

Why do I see Cloudflare, Nginx, or AWS-specific status codes?

Those responses may be generated by infrastructure before the request reaches your application, or after the origin fails to respond correctly. Check proxy, CDN, gateway, DNS, TLS, firewall, and load balancer logs before assuming the application returned the code.

05

Are all 5xx responses server bugs?

Not always. A 5xx response means the server side of the exchange failed, but the cause may be an upstream dependency, maintenance mode, overload, gateway timeout, DNS issue, TLS problem, or reverse proxy configuration.

Continue browsing more reference tools

Use the reference category for adjacent lookup pages when HTTP debugging leads into network ports, MIME types, headers, URL behavior, or other implementation details.