HTTP Status Codes — Complete List with Meanings and Examples

Interim response: the server has received the request headers and the client should go ahead and send the body.

Sent automatically by servers when a client includes "Expect: 100-continue" before uploading a large body, so the client does not waste bandwidth on a request that would be rejected.

Do not send it from application code as a final status; it is never the response to a request, only a step before the real one.

Not applicable

RFC 9110 §15.2.1

PUT /upload HTTP/1.1
Content-Length: 104857600
Expect: 100-continue

HTTP/1.1 100 Continue

The server agrees to switch the connection to the protocol named in the Upgrade header.

The handshake response for WebSocket connections (Upgrade: websocket) and, historically, HTTP/1.1 to h2c upgrades.

HTTP/2 and HTTP/3 do not use it; WebSockets over HTTP/2 use the extended CONNECT method (RFC 8441) instead.

Not applicable

RFC 9110 §15.2.2

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

Interim response telling the client the server is still working on a long WebDAV request, so it should not time out.

WebDAV. Removed from WebDAV in RFC 4918 but still in the IANA registry.

Only in legacy WebDAV servers handling slow recursive operations such as a deep COPY or MOVE.

New APIs should return 202 Accepted with a status URL for long-running work instead.

Not applicable

RFC 2518 §10.1

HTTP/1.1 102 Processing

Interim response carrying Link headers so the browser can start preloading or preconnecting while the server is still preparing the final response.

When the HTML takes time to generate (server-side rendering, database queries) and you know which CSS, fonts or origins the page needs. Chromium browsers and Firefox act on preload and preconnect hints in 103 responses; Safari acts on preconnect.

Do not put headers in it that must only apply to the final response, such as Set-Cookie; browsers ignore most headers in 103.

Not applicable

RFC 8297

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html

Interim response telling the client that the upload it has started can be resumed later, and where.

Temporary IANA registration for the IETF resumable uploads draft; not yet a final RFC.

Experimental: servers implementing the resumable uploads draft send it with a Location header for the upload resource.

Not for general use until the draft is published as an RFC; most clients and proxies do not know it.

Not applicable

draft-ietf-httpbis-resumable-upload

HTTP/1.1 104 Upload Resumption Supported
Upload-Draft-Interop-Version: 6
Location: https://example.com/upload/b530ce8ff

The request succeeded. What the body contains depends on the method: the resource for GET, the result of the action for POST.

The normal success response for GET, and for POST, PUT, PATCH or DELETE when you return a body describing the result.

Do not return 200 with an error message in the body ("soft errors"). Clients, monitoring, caches and search engines read the status code, not your JSON.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.3.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 42, "name": "Ada"}

The request succeeded and created one or more new resources.

After a POST (or a PUT to a new URL) that creates something. Include a Location header pointing to the new resource; the body usually describes it.

Do not use it when nothing new was created, for example an update to an existing record (use 200 or 204).

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.3.2

HTTP/1.1 201 Created
Location: /users/42
Content-Type: application/json

{"id": 42}

The request was accepted for processing, but processing has not finished and may still fail.

Queued or asynchronous work: video encoding, report generation, bulk imports. Return a link where the client can check the job status.

Do not use it to mean "success" for synchronous work; it explicitly promises nothing about the outcome.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.3.3

HTTP/1.1 202 Accepted
Location: /jobs/7f3a
Content-Type: application/json

{"status": "queued"}

Success, but a transforming proxy has modified the origin server’s 200 response.

Only by intermediaries that change content, such as a proxy that compresses images or rewrites HTML, to tell the client it is not the origin’s exact response.

Origin servers and APIs should not send it.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.3.4

HTTP/1.1 203 Non-Authoritative Information
Content-Type: image/webp

Success, and there is intentionally no body.

DELETE that succeeded, PUT or PATCH when you do not return the updated resource, a form autosave, or a CORS preflight response.

Never include a body; clients will not read it, and on HTTP/1.1 a stray body corrupts the next response on the connection. Use 200 if you have something to return.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.3.5

HTTP/1.1 204 No Content

Success; the client should reset the document view, for example clear the form that was submitted.

Data-entry interfaces where the user submits a form and immediately enters another record.

Browsers do not implement the reset behaviour, so in practice it acts like 204. Must not include a body.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.3.6

HTTP/1.1 205 Reset Content

The server is returning only the byte range(s) the client asked for with a Range header.

Video and audio seeking, resumable downloads and download managers that fetch a file in parallel chunks. Include Content-Range.

Do not send it unless the request had a Range header you are honouring. If you ignore Range, send 200 with the whole body.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.3.7

GET /video.mp4 HTTP/1.1
Range: bytes=0-1023

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024

The body (XML) contains a separate status for each of several resources.

WebDAV

WebDAV operations such as PROPFIND that act on many resources. Some JSON APIs borrow it for batch endpoints.

For batch APIs, many teams prefer 200 with per-item results, since generic clients treat 207 as plain success.

Cacheable only with explicit Cache-Control or Expires

RFC 4918 §11.1

HTTP/1.1 207 Multi-Status
Content-Type: application/xml; charset="utf-8"

Used inside a 207 response to say a resource was already listed earlier, so it is not repeated (avoids loops with bindings).

WebDAV

WebDAV servers that support bindings (RFC 5842).

Not meaningful as a top-level response outside WebDAV.

Cacheable only with explicit Cache-Control or Expires

RFC 5842 §7.1

<D:status>HTTP/1.1 208 Already Reported</D:status>

The server fulfilled a GET with a delta (instance manipulation) applied to the current resource rather than the full resource.

Delta encoding for HTTP (A-IM / IM headers). Rarely deployed.

Not supported by browsers; do not use it in ordinary APIs.

Cacheable only with explicit Cache-Control or Expires

RFC 3229 §10.4.1

HTTP/1.1 226 IM Used
IM: vcdiff
ETag: "v2"

The resource has several representations and the client (or user) should pick one.

Rare: agent-driven content negotiation, for example offering a document in several languages or formats with links to each.

Browsers do not choose automatically. For language or format selection, server-driven negotiation or a normal page with links works better.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.4.1

HTTP/1.1 300 Multiple Choices
Link: </doc.en.html>; rel=alternate; hreflang=en
Link: </doc.fr.html>; rel=alternate; hreflang=fr

The resource has a new permanent URL, given in the Location header.

Domain moves, HTTP to HTTPS, changed slugs, consolidating duplicate URLs. Search engines transfer ranking signals to the new URL.

Browsers may change POST to GET when following a 301. If the method must be kept (an API endpoint that moved), use 308. Browsers cache 301s aggressively, so test before deploying.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.4.2

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

The resource is temporarily at a different URL; keep using the original URL in future.

Temporary redirects: login redirects, A/B tests, maintenance pages, geo or language redirects.

Browsers change POST to GET when following a 302 (historical behaviour the RFC allows). Use 303 for “go see the result” after a POST, and 307 when the method must be preserved.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.4.3

HTTP/1.1 302 Found
Location: /login?next=%2Faccount

Redirect the client to another URL, which it must fetch with GET.

The Post/Redirect/Get pattern: after a form POST, send 303 to the result page so a page refresh does not resubmit the form.

Not for moved content; it says nothing about the original URL having moved.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.4.4

HTTP/1.1 303 See Other
Location: /orders/1234

Response to a conditional GET or HEAD (If-None-Match or If-Modified-Since): the client’s cached copy is still valid.

Cache revalidation: not stored itself, but it refreshes the cached response the client already holds.

Automatically by servers and CDNs when the ETag or Last-Modified date matches, saving the transfer of an unchanged body.

Never send a body. Do not send it to a request that was not conditional; the client has nothing to reuse.

Not applicable

RFC 9110 §15.4.5

GET /app.js HTTP/1.1
If-None-Match: "33a64df5"

HTTP/1.1 304 Not Modified
ETag: "33a64df5"
Cache-Control: max-age=3600

Deprecated. Once told the client to repeat the request through a proxy named in Location.

Nothing. It was deprecated for security reasons and browsers ignore it.

Do not send it.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.4.6

HTTP/1.1 305 Use Proxy

Reserved. It was used in a draft for "Switch Proxy" and is no longer used.

Nothing.

Do not send it.

Not applicable

RFC 9110 §15.4.7

Temporary redirect where the client must repeat the request with the same method and body.

Temporarily redirecting POST, PUT or DELETE requests (an API endpoint moved for maintenance). Browsers also show an internal 307 when HSTS forces HTTPS.

For a permanent move, use 308. For "go fetch the result with GET", use 303.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.4.8

HTTP/1.1 307 Temporary Redirect
Location: https://api2.example.com/v1/orders

Permanent redirect where the client must repeat the request with the same method and body.

A permanently moved API endpoint that receives POST or PUT. Search engines treat it like 301. Next.js and Vercel use 308 for permanent redirects by default.

Very old clients (Internet Explorer on Windows 7 and earlier) do not understand it; for plain page moves 301 is equally good.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.4.9

HTTP/1.1 308 Permanent Redirect
Location: https://example.com/api/v2/upload

The server will not process the request because of a client error: malformed syntax, invalid framing or invalid parameters.

Unparseable JSON, a missing required parameter, a value of the wrong type. Explain the problem in the body (RFC 9457 problem+json is a good format).

For well-formed input that fails business rules, many APIs use 422. For authentication problems use 401 or 403.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.1

HTTP/1.1 400 Bad Request
Content-Type: application/problem+json

{"title": "Invalid JSON", "detail": "Unexpected token } at position 41"}

The request lacks valid authentication credentials. Despite the name, it means "unauthenticated".

No token, an expired token or a wrong password. The response must include a WWW-Authenticate header describing how to authenticate.

If the user is logged in but not allowed, use 403. Do not send 401 without WWW-Authenticate.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.2

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token"

Reserved for future use. There is no standard semantics.

Some APIs use it for "quota exhausted, upgrade your plan" or a failed payment (Stripe returns 402 for declined card requests).

Do not rely on clients understanding it; describe the problem in the body.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.3

HTTP/1.1 402 Payment Required
Content-Type: application/json

{"error": "card_declined"}

The server understood the request and knows who you are (or does not care) but refuses to fulfil it.

The authenticated user lacks permission, an IP is blocked, directory listing is disabled, or a WAF rule fired. Re-authenticating will not help.

If credentials are missing or invalid, use 401. If revealing that the resource exists is itself a leak, return 404 instead.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.4

HTTP/1.1 403 Forbidden
Content-Type: application/json

{"error": "You do not have access to this project"}

The server has no current representation for the URL, or will not say whether one exists.

Unknown URLs, deleted records when you do not track deletions, or hiding resources from unauthorised users.

If the resource existed and is gone for good, 410 states that explicitly. Do not return a 200 page that says "not found" (a soft 404).

Cacheable by default (heuristically cacheable)

RFC 9110 §15.5.5

HTTP/1.1 404 Not Found
Content-Type: text/html

The URL exists, but does not support this HTTP method.

A DELETE to a read-only resource or a POST to a GET-only page. The response must include an Allow header listing the supported methods.

Do not use it for permission problems (403) or for methods the server does not implement at all (501).

Cacheable by default (heuristically cacheable)

RFC 9110 §15.5.6

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD

The server cannot produce a response matching the request’s Accept, Accept-Language or Accept-Encoding headers.

An API that only speaks JSON receiving "Accept: application/xml" with no fallback.

Most servers ignore unmatched Accept headers and send their default format instead, which is usually friendlier.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.7

HTTP/1.1 406 Not Acceptable
Content-Type: application/json

{"supported": ["application/json"]}

Like 401, but the client must authenticate with the proxy in between.

Sent by forward proxies (corporate proxies), with a Proxy-Authenticate header.

Origin servers should never send it.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.8

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="corp-proxy"

The server did not receive a complete request in the time it was prepared to wait, and is closing the connection.

Sent by servers on idle keep-alive connections or slow uploads. Clients may retry the request on a new connection.

Not for slow back-end processing; that is a 504 at a gateway or simply a slow response. Send "Connection: close" with it.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.9

HTTP/1.1 408 Request Timeout
Connection: close

The request conflicts with the current state of the resource.

Creating a user whose email already exists, editing a record someone else changed (version mismatch), deleting a non-empty folder.

For failed If-Match / If-Unmodified-Since conditions, use 412. For validation errors, use 400 or 422.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.10

HTTP/1.1 409 Conflict
Content-Type: application/json

{"error": "Email already registered"}

The resource used to exist here, is gone permanently, and has no forwarding address.

Discontinued products, expired promotions, deleted accounts, retired API versions. Google treats 404 and 410 almost the same, though a 410 may be dropped from the index a little sooner.

If the content moved, redirect with 301 instead. If you are not sure it is permanent, use 404.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.5.11

HTTP/1.1 410 Gone

The server requires a Content-Length header on this request.

Servers that refuse chunked uploads and need to know the body size in advance.

Rarely needed by applications; usually emitted by the web server itself.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.12

HTTP/1.1 411 Length Required

A condition in the request headers (If-Match, If-Unmodified-Since, If-None-Match on a write) evaluated to false.

Optimistic concurrency: the client sent If-Match with an old ETag, meaning someone else changed the resource first.

Do not use it for business-rule failures that have nothing to do with conditional headers (409 or 422).

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.13

PUT /docs/7 HTTP/1.1
If-Match: "v3"

HTTP/1.1 412 Precondition Failed
ETag: "v4"

The request body is larger than the server is willing to process. Called "Payload Too Large" before RFC 9110.

Uploads over the limit (nginx client_max_body_size, a 10 MB API cap). If the limit is temporary, add Retry-After.

For a URL that is too long use 414; for too-large headers use 431.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.14

HTTP/1.1 413 Content Too Large
Connection: close

The request target (URL) is longer than the server will interpret.

Huge query strings, often a GET form that should be a POST, or a redirect loop that keeps appending parameters.

Move large inputs to a request body (POST) rather than raising the limit indefinitely.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.5.15

HTTP/1.1 414 URI Too Long

The server refuses the request because the body’s format (Content-Type or Content-Encoding) is not supported.

An endpoint that accepts JSON receiving form data or XML, or a missing Content-Type header. Include Accept-Post or Accept-Patch to show what is supported.

Not for a body in the right format with invalid content (400 or 422).

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.16

HTTP/1.1 415 Unsupported Media Type
Accept-Post: application/json

None of the byte ranges in the Range header overlap the resource, for example asking for bytes beyond the end of the file.

Resumed downloads where the file has shrunk or the client asks past its end. Include Content-Range: bytes */<length>.

Servers may simply ignore an invalid Range and return 200 with the full body, which is also allowed.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.17

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */47022

The server cannot meet the requirement in the request’s Expect header.

A client sent "Expect: 100-continue" to a server or proxy that does not support it, or an unknown expectation.

Clients that get it should retry without the Expect header.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.18

HTTP/1.1 417 Expectation Failed

Reserved by RFC 9110 because 418 was widely deployed as the “I’m a teapot” joke code; it has no defined meaning in HTTP.

Reserved. Famous as “I’m a teapot” from the 1998 April Fools’ RFC 2324 (HTCPCP).

Only as an Easter egg. Some services use it to answer requests they want to reject in a humorous way.

Do not use it for real errors; it cannot be assigned a meaning and clients will not know what to do.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.19

HTTP/1.1 418 I'm a teapot

Laravel returns it when the CSRF token is missing or has expired, usually after a session timed out on a page with a form.

Sent by Laravel’s CSRF middleware. Fix by refreshing the page, including @csrf in forms, or sending the X-CSRF-TOKEN header with AJAX requests.

Not a standard code; do not send it from non-Laravel APIs.

Not applicable

Laravel (not in the IANA registry)

HTTP/1.1 419 unknown status

The old Twitter API’s rate-limit response, replaced by the standard 429.

Nothing new. You may still meet it in old client libraries. Spring once defined 420 "Method Failure", now deprecated.

Use 429 for rate limiting.

Not applicable

Twitter API v1 (not in the IANA registry)

HTTP/1.1 420 Enhance Your Calm

The request reached a server that cannot produce a response for that host and scheme.

HTTP/2 connection coalescing went wrong: the browser reused a connection for another hostname covered by the same certificate, but the server does not serve it. The client should retry on a new connection.

Not for ordinary unknown hostnames on a single server; that is usually a 404 or the default virtual host.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.20

HTTP/2 421

The request is well-formed and in a supported format, but its content fails validation. Called "Unprocessable Entity" in RFC 4918.

Form and API validation errors: an email that is not an email, an end date before the start date. Rails, Laravel and FastAPI use it by default.

For malformed syntax (unparseable JSON) use 400.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.21

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors": {"email": ["is invalid"]}}

The resource is locked, so the request cannot change it.

WebDAV

WebDAV LOCK semantics. Some APIs use it for records being edited by someone else or accounts locked after failed logins.

Outside WebDAV, 409 is better understood by generic clients.

Cacheable only with explicit Cache-Control or Expires

RFC 4918 §11.3

HTTP/1.1 423 Locked

The action failed because another action it depended on failed.

WebDAV

In a WebDAV PROPPATCH or a batch request, items that were not attempted because an earlier item failed.

Not for upstream service failures; those are 502 or 503.

Cacheable only with explicit Cache-Control or Expires

RFC 4918 §11.4

HTTP/1.1 424 Failed Dependency

The server will not process a request sent in TLS 1.3 early data (0-RTT) because it might be replayed.

CDNs and servers that accept 0-RTT but reject non-idempotent requests (POST) in early data. The client retries after the handshake completes.

Not a general "try later" code; use 503 with Retry-After for that.

Cacheable only with explicit Cache-Control or Expires

RFC 8470 §5.2

HTTP/1.1 425 Too Early

The server refuses the request on the current protocol but would accept it after an upgrade named in the Upgrade header.

Requiring TLS or a newer protocol, or a WebSocket endpoint hit with a plain HTTP request. Must include an Upgrade header.

For HTTP to HTTPS on websites, a 301 or 308 redirect plus HSTS is the usual approach.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.5.22

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.3, HTTP/1.1
Connection: Upgrade

The server requires the request to be conditional (If-Match etc.), to prevent lost updates.

APIs that insist clients send If-Match with the ETag they last saw before a PUT, PATCH or DELETE.

Use 412 when a precondition was sent and failed; 428 is for when none was sent.

Must not be stored by caches

RFC 6585 §3

HTTP/1.1 428 Precondition Required
Content-Type: application/json

{"error": "Send If-Match with the current ETag"}

The client sent too many requests in a given time (rate limiting).

API rate limits, login throttling, scraping protection. Include Retry-After so well-behaved clients know when to come back; RateLimit headers help too.

For a server that is overloaded for everyone, use 503. Googlebot treats 429 like 503 and slows down crawling.

Must not be stored by caches

RFC 6585 §4

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json

{"error": "Rate limit exceeded: 100 requests per minute"}

The headers, individually or together, are too large for the server.

Usually oversized cookies accumulated on a domain, or huge Authorization tokens. Clearing cookies often fixes it for users.

For a long URL use 414; for a large body use 413.

Must not be stored by caches

RFC 6585 §5

HTTP/1.1 431 Request Header Fields Too Large

The client’s session expired and it must log in again (Outlook Web Access and other IIS apps).

Seen in Exchange/OWA environments.

Use 401 for expired sessions in your own apps.

Not applicable

Microsoft IIS (not in the IANA registry)

HTTP/1.1 440 Login Time-out

nginx-internal code: "return 444;" closes the connection without sending any response at all.

Dropping requests from scanners, requests for unknown Host headers in a default server block, or abusive clients. It appears in nginx logs; the client sees an empty reply.

The client never receives a 444, so it is not something to handle in client code.

Not applicable

nginx (not in the IANA registry)

server {
  listen 80 default_server;
  return 444;
}

Microsoft extension: the request should be retried after the client performs a specific action.

Seen in some Microsoft services (Exchange ActiveSync, Azure Cosmos DB uses 449 for retryable write conflicts).

Not standard; use 409 or 503 with Retry-After in your own APIs.

Not applicable

Microsoft IIS (not in the IANA registry)

HTTP/1.1 449 Retry With

Windows Parental Controls blocked access to the page.

Generated on Windows systems with parental controls.

Do not send it from servers.

Not applicable

Microsoft (not in the IANA registry)

HTTP/1.1 450 Blocked by Windows Parental Controls

Access is denied because of a legal demand: a court order, government censorship or a geo-restriction for legal reasons.

Content blocked in a jurisdiction (sanctions, GDPR-related geo-blocks, takedown orders). A Link header with rel="blocked-by" can name who imposed it.

Not for ordinary permission denials (403) or for content you simply chose to remove (410).

Cacheable by default (heuristically cacheable)

RFC 7725 §3

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://authority.example/>; rel="blocked-by"

Logged by an AWS ALB when the client closed the connection before the idle timeout elapsed.

Seen in ALB access logs; usually a client with a shorter timeout than the target’s processing time.

Not sent to clients.

Not applicable

AWS Elastic Load Balancing (not in the IANA registry)

elb_status_code=460

The ALB received an X-Forwarded-For header with more than 30 IP addresses.

Usually a proxy loop that keeps appending addresses.

Not for application use.

Not applicable

AWS Elastic Load Balancing (not in the IANA registry)

HTTP/1.1 463

nginx-internal code for headers exceeding large_client_header_buffers; the client receives a 400.

Appears in nginx logs and error_page configuration.

The standard code is 431.

Not applicable

nginx (not in the IANA registry)

error_page 494 /header-too-large.html;

nginx-internal: the client presented an invalid client certificate (mutual TLS). Sent to the client as 400.

Custom error pages for mTLS failures.

Not a wire status code.

Not applicable

nginx (not in the IANA registry)

error_page 495 /bad-client-cert.html;

nginx-internal: a client certificate was required but not provided. Sent to the client as 400.

Custom error pages when ssl_verify_client is on.

Not a wire status code.

Not applicable

nginx (not in the IANA registry)

error_page 496 /client-cert-required.html;

nginx-internal: a plain HTTP request arrived on a port that expects TLS. Sent to the client as 400.

A common trick is "error_page 497 =301 https://$host$request_uri;" to redirect such requests to HTTPS.

Not a wire status code.

Not applicable

nginx (not in the IANA registry)

error_page 497 =301 https://$host:$server_port$request_uri;

ArcGIS returns it for an expired or otherwise invalid token.

Only relevant when calling ArcGIS services.

Use 401 for invalid tokens in your own APIs.

Not applicable

Esri ArcGIS (not in the IANA registry)

HTTP/1.1 498 Invalid Token

nginx logs 499 when the client closed the connection before nginx sent a response.

Seen in access logs: users navigating away, mobile clients timing out, or a load balancer in front of nginx with a shorter timeout. Many 499s on one endpoint usually mean it is too slow.

The client never receives it. Esri also uses 499 for "Token Required".

Not applicable

nginx (not in the IANA registry)

203.0.113.9 - - [16/Oct/2026:10:12:01 +0000] "GET /report HTTP/1.1" 499 0

The server hit an unexpected condition that stopped it from fulfilling the request.

Unhandled exceptions and bugs. It is the generic fallback when no more specific 5xx applies.

Do not use it for client mistakes (4xx). Do not leak stack traces in the body in production; log them instead.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.6.1

HTTP/1.1 500 Internal Server Error
Content-Type: application/problem+json

{"title": "Internal Server Error", "traceId": "4bf92f35"}

The server does not support the functionality required, typically an HTTP method it does not recognise at all.

A request with an unknown method (e.g. a WebDAV method on a plain web server), or a feature the server has deliberately not built yet.

If the method is known but not allowed on this URL, use 405.

Cacheable by default (heuristically cacheable)

RFC 9110 §15.6.2

HTTP/1.1 501 Not Implemented

A gateway or proxy got an invalid response from the upstream server.

Sent by reverse proxies and load balancers (nginx, Cloudflare, AWS ALB) when the app server crashed, closed the connection or returned garbage.

Application code rarely needs to send it, except API gateways that call another service which failed.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.6.3

HTTP/1.1 502 Bad Gateway
Server: nginx

The server cannot handle the request right now: overloaded, or down for maintenance. Expected to be temporary.

Planned maintenance, load shedding, a dependency outage. Add Retry-After. Search engines keep the page indexed during short 503 periods, unlike a 200 maintenance page or 404.

Do not leave a site on 503 for days; Google eventually drops URLs that keep returning it.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.6.4

HTTP/1.1 503 Service Unavailable
Retry-After: 3600

A gateway or proxy did not get a response from the upstream server in time.

Sent by proxies and load balancers when the application takes longer than the proxy timeout (nginx proxy_read_timeout defaults to 60 seconds).

For long jobs, do not just raise timeouts; return 202 and process asynchronously.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.6.5

HTTP/1.1 504 Gateway Timeout
Server: awselb/2.0

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

A server receiving a protocol version it cannot speak.

Rarely seen; clients negotiate HTTP/2 and HTTP/3 through ALPN and Alt-Svc rather than by trial.

Cacheable only with explicit Cache-Control or Expires

RFC 9110 §15.6.6

HTTP/1.1 505 HTTP Version Not Supported

Server configuration error: the chosen variant is itself set up to negotiate, creating a loop.

Transparent content negotiation (experimental)

Only servers implementing RFC 2295 transparent content negotiation.

Not for application errors.

Cacheable only with explicit Cache-Control or Expires

RFC 2295 §8.1

HTTP/1.1 506 Variant Also Negotiates

The server cannot store what is needed to complete the request.

WebDAV

WebDAV or file-storage APIs when the disk or the user’s quota is full.

For a single upload that exceeds a size limit, 413 is clearer.

Cacheable only with explicit Cache-Control or Expires

RFC 4918 §11.5

HTTP/1.1 507 Insufficient Storage

The server stopped an operation because it found an infinite loop (WebDAV bindings with Depth: infinity).

WebDAV

WebDAV servers. CloudLinux-based shared hosts also send 508 "Resource Limit Is Reached" when an account hits its limits, which is non-standard.

Not for redirect loops; those are a client-side error the browser reports itself.

Cacheable only with explicit Cache-Control or Expires

RFC 5842 §7.2

HTTP/1.1 508 Loop Detected

The hosting account has exceeded its bandwidth allowance.

Shared hosting control panels.

Use 503 or 429 in your own systems.

Not applicable

Apache / cPanel (not in the IANA registry)

HTTP/1.1 509 Bandwidth Limit Exceeded

The request did not meet the policy for accessing the resource under the HTTP Extension Framework.

Marked obsoleted in the IANA registry: RFC 2774 was moved to Historic.

Nothing current; the extension framework was never widely implemented.

Do not send it.

Cacheable only with explicit Cache-Control or Expires

RFC 2774 §7

HTTP/1.1 510 Not Extended

The client must authenticate to gain network access: a captive portal.

Hotel, airport and café Wi-Fi portals intercepting traffic until the user logs in or accepts terms.

Origin servers must never send it; it is for intercepting network proxies only.

Must not be stored by caches

RFC 6585 §6

HTTP/1.1 511 Network Authentication Required
Content-Type: text/html

<meta http-equiv="refresh" content="0; url=https://login.example.net/">

The origin returned an empty, unknown or unexpected response to Cloudflare.

Check origin logs: crashes, connection resets, headers over Cloudflare’s limit, or an empty reply.

Only Cloudflare sends it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 520
server: cloudflare

Cloudflare could not connect to the origin: the connection was refused.

The origin web server is stopped, or a firewall is blocking Cloudflare’s IP ranges.

Only Cloudflare sends it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 521
server: cloudflare

Cloudflare timed out establishing a TCP connection to the origin.

Origin overloaded, packets dropped by a firewall, or a wrong origin IP in DNS.

Only Cloudflare sends it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 522
server: cloudflare

Cloudflare cannot reach the origin at all, typically a routing problem or wrong DNS record.

Check that the DNS A/AAAA records point at the right, reachable IP.

Only Cloudflare sends it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 523
server: cloudflare

Cloudflare connected to the origin, but the origin did not send an HTTP response within the timeout (100 seconds by default).

Long-running requests: move the work to a background job and poll, or stream progress.

Only Cloudflare sends it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 524
server: cloudflare

The TLS handshake between Cloudflare and the origin failed.

Origin not listening on 443, no certificate, no shared cipher suites, or SNI not configured, while the SSL mode is Full or Full (strict).

Only Cloudflare sends it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 525
server: cloudflare

In Full (strict) mode, Cloudflare could not validate the origin’s certificate: expired, self-signed, or wrong hostname.

Install a valid certificate or a Cloudflare Origin CA certificate on the origin.

Only Cloudflare sends it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 526
server: cloudflare

Connection problem between Cloudflare and a Railgun listener at the origin. Cloudflare has discontinued Railgun.

Historical only.

Only Cloudflare sent it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/1.1 527 Railgun Error

Returned with a Cloudflare 1xxx error page (such as 1016 Origin DNS error); the 1xxx code shown on the page is the real cause.

Look up the 1xxx error number shown on the page.

Only CDNs and hosts send it.

Not applicable

Cloudflare (not in the IANA registry)

HTTP/2 530
server: cloudflare

The ALB’s built-in authentication (OIDC or Cognito) failed with the identity provider.

Check the IdP configuration of the ALB listener rule.

Not for application use.

Not applicable

AWS Elastic Load Balancing (not in the IANA registry)

HTTP/1.1 561

Used by some proxies to signal a read timeout behind the proxy.

Rare; you may see it from certain proxy products.

Use 504.

Not applicable

Informal convention (not in the IANA registry)

HTTP/1.1 598

Used by some proxies and client libraries (Tornado’s HTTP client, for example) for a connection timeout.

Rare.

Use 504 for proxies.

Not applicable

Informal convention (not in the IANA registry)

HTTP/1.1 599