HTTP Status Codes Reference

Every HTTP status code explained: what it means, why you got it and how to fix it.

Developer No upload Works offline Free, no sign-up

Status code, phrase or problem

Try:

64 registered codes and 19 vendor codes

1xx Informational

5 codes

Interim responses: the request was received and is being processed (RFC 9110 §15.2).

100 Continue The server has the request headers and has not rejected them, so the client can send the body.

It answers Expect: 100-continue, which lets a client avoid uploading a large body that the server would refuse anyway (for example with 401 or 413).

Defined in: RFC 9110 §15.2.1
Caching: Interim. Never cached: interim (1xx) responses are not final responses.
Retry: An interim response: the client keeps waiting for the final one.
Headers: Expect

Typical causes

A client sent Expect: 100-continue before a request body; curl and many HTTP libraries do this for larger uploads.

How to fix it

Nothing to fix: the client goes on to send the body.
If a proxy mishandles it, send the request without the header (curl: -H "Expect:").

Example response

HTTP/1.1 100 Continue

101 Switching Protocols The server agrees to switch this connection to the protocol named in the Upgrade header — most often WebSocket.

Defined in: RFC 9110 §15.2.2
Caching: Interim. Never cached: interim (1xx) responses are not final responses.
Retry: An interim response: the client keeps waiting for the final one.
Headers: UpgradeConnectionSec-WebSocket-Accept

Typical causes

A WebSocket handshake (Upgrade: websocket) succeeded.
A client asked to upgrade an HTTP/1.1 connection to another protocol.

How to fix it

Nothing to fix: after this response the connection speaks the new protocol.
If WebSockets fail behind nginx, forward the upgrade headers: proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";.

Example response

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

102 Processing Obsolete An interim WebDAV response: the server has the whole request and is still working on it, so the client should not time out.

Defined in the original WebDAV specification (RFC 2518). RFC 4918 removed it, but it is still registered; few clients or servers use it.

Defined in: RFC 2518 §10.1
Caching: Interim. Never cached: interim (1xx) responses are not final responses.
Retry: An interim response: the client keeps waiting for the final one.

Typical causes

A WebDAV server working on a long request, such as a deep COPY or PROPFIND.

How to fix it

Nothing to fix: wait for the final response.

Example response

HTTP/1.1 102 Processing

103 Early Hints An interim response with Link headers, so the browser can start preloading or preconnecting while the server prepares the real response.

Defined in: RFC 8297 §2
Caching: Interim. Never cached: interim (1xx) responses are not final responses.
Retry: An interim response: the client keeps waiting for the final one.
Headers: Link

Typical causes

A server or CDN sends hints such as Link: </style.css>; rel=preload; as=style before the final response is ready.

How to fix it

Nothing to fix. The hints do not replace the final response’s own headers, so send them there too.

Example response

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script

104 Upload Resumption Supported Temporary registration An interim response saying this upload can be resumed, with the upload resource’s URL in Location.

Part of the IETF resumable uploads draft. The IANA registration is temporary and lapses unless it is renewed or made permanent.

Defined in: draft-ietf-httpbis-resumable-upload-05
Caching: Interim. Never cached: interim (1xx) responses are not final responses.
Retry: An interim response: the client keeps waiting for the final one.
Headers: LocationUpload-OffsetUpload-Limit

Typical causes

A server that implements the resumable-upload draft accepted an upload.

How to fix it

If the connection drops, ask the upload URL how much arrived (HEAD) and append the rest instead of starting again.

Example response

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

2xx Success

10 codes

The request was received, understood and accepted (RFC 9110 §15.3).

200 OK The request succeeded. For GET the body is the resource; for POST it is the result of the action.

Defined in: RFC 9110 §15.3.1
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: A success: nothing to retry.
Headers: Content-TypeETagLast-ModifiedCache-Control

Typical causes

The normal answer to a successful request.

How to fix it

Nothing to fix. Do not answer errors with 200 and an error message in the body: clients, caches and monitoring all treat 200 as success.

Example response

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "33a64df5"
Cache-Control: max-age=60

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

201 Created The request created a new resource; the Location header points to it.

Defined in: RFC 9110 §15.3.2
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: A success: nothing to retry.
Headers: LocationETag

Typical causes

A POST that created a record, or a PUT that created a resource that did not exist yet.

How to fix it

Return a Location header with the new resource’s URL, and usually its representation in the body.

Example response

HTTP/1.1 201 Created
Location: /api/orders/1042
Content-Type: application/json

{"id":1042,"status":"pending"}

202 Accepted The request was accepted for processing, which has not finished yet — and might still fail.

Defined in: RFC 9110 §15.3.3
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: A success: nothing to retry.
Headers: Location

Typical causes

Work handed to a background job: video encoding, reports, bulk imports.

How to fix it

Give the client a way to follow progress — a status URL in Location or in the body — and poll it, or notify the client when the job is done.

Example response

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

{"job":"7f3a","status":"queued"}

203 Non-Authoritative Information A success, but a transforming proxy changed the content from what the origin server sent.

Defined in: RFC 9110 §15.3.4
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: A success: nothing to retry.

Typical causes

A proxy that rewrites responses (for example recompressing images) and says so.

How to fix it

Rarely seen. If it is unexpected, find out which proxy modifies the responses.

Example response

HTTP/1.1 203 Non-Authoritative Information
Content-Length: 0

204 No Content A success with nothing to send back — common for DELETE, saves and CORS preflight requests.

Defined in: RFC 9110 §15.3.5
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: A success: nothing to retry.
Headers: ETag

Typical causes

A DELETE or update that has nothing to return.
Answers to CORS preflight (OPTIONS) requests.

How to fix it

Never include a body: a 204 cannot have one. Return 200 with a body if the client needs data back.

Example response

HTTP/1.1 204 No Content
ETag: "a1b2c3"

205 Reset Content A success; the client should reset the form or view that sent the request, ready for the next entry.

Defined in: RFC 9110 §15.3.6
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: A success: nothing to retry.

Typical causes

A data-entry form that should be cleared after each submission.

How to fix it

Rarely used. The response must not have a body; most applications use 204 or 200 instead.

Example response

HTTP/1.1 205 Reset Content
Content-Length: 0

206 Partial Content The response carries only the requested byte range — used for video seeking, resumed and parallel downloads.

Defined in: RFC 9110 §15.3.7
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: A success: nothing to retry.
Headers: RangeContent-RangeAccept-RangesIf-Range

Typical causes

The client sent a Range header (for example Range: bytes=0-1023) and the server supports ranges.

How to fix it

Nothing to fix. Check Content-Range to see which bytes arrived. Servers that support ranges send Accept-Ranges: bytes.

Example response

HTTP/1.1 206 Partial Content
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

207 Multi-Status WebDAV: the XML body reports a separate status for each of several resources.

Defined in: RFC 4918 §11.1
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Read the status of each resource in the body: some may have failed.

Typical causes

A WebDAV PROPFIND, PROPPATCH, COPY or MOVE that covers several resources.

How to fix it

Read each <D:response> in the body; the 207 only means that the report was produced.

Example response

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

<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/docs/a.txt</D:href>
    <D:status>HTTP/1.1 200 OK</D:status>
  </D:response>
</D:multistatus>

208 Already Reported WebDAV: inside a 207 report, the members of this collection were already listed under another binding, so they are not repeated.

Defined in: RFC 5842 §7.1
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: A success: nothing to retry.

Typical causes

A Depth: infinity PROPFIND over collections that are bound more than once.

How to fix it

Only appears inside 207 bodies, for clients that announced DAV: bind.

Example response

HTTP/1.1 208 Already Reported
Content-Length: 0

226 IM Used The server applied instance manipulations (such as delta encoding) to the response; the IM header lists them.

Defined in: RFC 3229 §10.4.1
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: A success: nothing to retry.
Headers: A-IMIMDelta-Base

Typical causes

Delta encoding: the client asked with A-IM and the server sent only what changed.

How to fix it

Rarely deployed. Clients that did not ask for delta encoding should never receive it.

Example response

HTTP/1.1 226 IM Used
Content-Length: 0

3xx Redirection

9 codes

Further action is needed to complete the request, usually following a Location (RFC 9110 §15.4).

300 Multiple Choices Several representations are available and the client (or the user) should choose one.

Defined in: RFC 9110 §15.4.1
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Follow one of the offered choices (or the Location, if one is given).
Headers: Location

Typical causes

Content negotiation that lists alternatives, for example several formats or languages.

How to fix it

Rare in practice. Prefer redirecting to one choice, or negotiate with Accept headers.

Example response

HTTP/1.1 300 Multiple Choices
Location: https://example.com/new-location
Content-Length: 0

301 Moved Permanently The resource has a new permanent URL (in Location); links and bookmarks should be updated.

Browsers may turn a POST into a GET when they follow a 301; use 308 to keep the method and body.

Defined in: RFC 9110 §15.4.2
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Follow the Location; browsers do it automatically.
Headers: Location

Typical causes

A page or a whole site moved: HTTP to HTTPS, www to non-www, renamed URLs, a new domain.

How to fix it

Point Location straight at the final URL to avoid redirect chains.
Use 308 instead when POST or PUT requests must keep their method and body.
Browsers remember 301s, so test a new redirect with 302 first; after changing a 301, clear the browser cache to see the change.

Example response

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

302 Found A temporary redirect to the URL in Location; keep using the original URL in future.

For historical reasons browsers turn a POST into a GET when following a 302; use 307 to keep the method.

Defined in: RFC 9110 §15.4.3
Also called: Moved Temporarily
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Follow the Location; browsers do it automatically.
Headers: Location

Typical causes

How to fix it

Use 303 for redirect-after-POST, 307 to keep the method, and 301 or 308 for permanent moves.

Example response

HTTP/1.1 302 Found
Location: /login?next=%2Faccount
Content-Length: 0

303 See Other Fetch the URL in Location with GET instead — the classic redirect after a form POST (Post/Redirect/Get).

Defined in: RFC 9110 §15.4.4
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Follow the Location with GET.
Headers: Location

Typical causes

A form or API POST that processed something and points to the result page.

How to fix it

Nothing to fix: because the result is fetched with GET, reloading the page does not submit the form again.

Example response

HTTP/1.1 303 See Other
Location: /orders/1042
Content-Length: 0

304 Not Modified The client’s cached copy is still valid (its If-None-Match or If-Modified-Since condition held), so no body is sent.

Defined in: RFC 9110 §15.4.5
Caching: Revalidates cache. Not stored itself: it tells the cache that its stored copy is still valid and refreshes that copy’s headers (RFC 9111 §4.3.4).
Retry: Use the cached copy.
Headers: ETagIf-None-MatchIf-Modified-SinceCache-ControlVary

Typical causes

A conditional request such as If-None-Match: "33a64df5" for a resource that has not changed.

How to fix it

Nothing to fix — it saves bandwidth. Send the same ETag, Cache-Control, Expires and Vary headers a 200 would carry.

Example response

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

305 Use Proxy Deprecated Deprecated. It once told the client to repeat the request through a proxy.

Deprecated because letting a response configure a proxy is a security risk (RFC 7231, Appendix B).

Defined in: RFC 9110 §15.4.6
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not act on it.

Typical causes

Very old or misconfigured software.

How to fix it

Do not send it.

Example response

HTTP/1.1 305 Use Proxy
Location: https://example.com/new-location
Content-Length: 0

306 (Unused) Reserved Reserved: it was defined in an earlier version of HTTP and is no longer used.

Defined in: RFC 9110 §15.4.7
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Not used.

Typical causes

Should never appear.

How to fix it

Do not send it.

Example response

HTTP/1.1 306 (Unused)
Location: https://example.com/new-location
Content-Length: 0

307 Temporary Redirect A temporary redirect that keeps the method and body: a POST is repeated as a POST at the new URL.

Defined in: RFC 9110 §15.4.8
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Follow the Location with the same method.
Headers: Location

Typical causes

Temporary moves where the method matters, such as API endpoints.
In Chrome’s developer tools, an HTTPS upgrade for a site on the HSTS list shows up as “307 Internal Redirect” — the browser made it, not the server.

How to fix it

Use 302 or 303 when switching to GET is fine, and 308 for permanent moves.

Example response

HTTP/1.1 307 Temporary Redirect
Location: https://api2.example.com/v1/orders
Content-Length: 0

308 Permanent Redirect A permanent redirect that keeps the method and body — the method-preserving version of 301.

Defined in: RFC 9110 §15.4.9
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Follow the Location with the same method.
Headers: Location

Typical causes

A permanently moved endpoint that receives POST or PUT requests.
Frameworks such as Next.js use 308 for their permanent redirects.

How to fix it

Current browsers support it. It is newer than the other redirects (RFC 7238, standardised in RFC 7538), so check very old HTTP clients before relying on it.

Example response

HTTP/1.1 308 Permanent Redirect
Location: https://api.example.com/v2/orders
Content-Length: 0

4xx Client error

38 codes

The request has a problem: bad syntax, missing credentials or a resource that cannot be served (RFC 9110 §15.5).

400 Bad Request The server will not process the request because of something it sees as a client error: malformed syntax, invalid framing or bad values.

Defined in: RFC 9110 §15.5.1
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

Malformed JSON or XML, a missing required parameter, a value of the wrong type.
Oversized or corrupt cookies or headers (nginx answers 400 “Request Header Or Cookie Too Large”).
A body that does not match the declared Content-Type.

How to fix it

Read the response body: good APIs say what is wrong.
Validate the payload (for example with a JSON validator) and check Content-Type.
If every page of a site returns 400 in your browser, clear that site’s cookies.

Example response

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

{"type":"https://example.com/problems/malformed-json","title":"The request body is not valid JSON","status":400,"detail":"Unexpected end of input at line 3, column 1"}

401 Unauthorized Authentication is missing or failed: the request needs valid credentials. Despite the name, it is about who you are, not what you may do.

A 401 must come with a WWW-Authenticate header describing how to authenticate.

Defined in: RFC 9110 §15.5.2
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry with new or corrected credentials (log in again, refresh the token).
Headers: WWW-AuthenticateAuthorization

Typical causes

No Authorization header, an expired or invalid token, a wrong password or API key.
A token issued for another audience or environment (staging versus production).

How to fix it

Log in again or refresh the access token, then retry with Authorization: Bearer ….
Check the token’s expiry (exp) and audience (aud) with the JWT Decoder.
Servers: send WWW-Authenticate with the scheme and, for bearer tokens, an error code.

Example response

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api", error="invalid_token", error_description="The access token expired"
Content-Type: application/problem+json

{"title":"Authentication required","status":401,"detail":"The access token expired. Request a new one and try again."}

402 Payment Required Reserved Reserved for future use. Some services send it for unpaid accounts or exhausted quotas, but it has no standard meaning.

Defined in: RFC 9110 §15.5.3
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Not until the account or billing problem is solved.

Typical causes

A billing or subscription problem in a particular service (non-standard use).

How to fix it

Check the service’s documentation and billing dashboard.

Example response

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

{"title":"Payment Required","status":402,"detail":"Reserved for future use."}

403 Forbidden The server understood the request and refuses it. Repeating it with the same credentials will not help.

Defined in: RFC 9110 §15.5.4
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

The user or API key lacks permission for this resource or action.
The web server cannot read the file (permissions or ownership), or a directory has no index file and listing is off.
A firewall, WAF, IP or country block, or hotlink protection.
A missing or invalid CSRF token.

How to fix it

Check the roles and permissions of the account or key.
Check file permissions and ownership with the Chmod Calculator, and that an index file exists.
Look in the WAF or firewall logs for the rule that blocked the request.

Example response

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

{"title":"Forbidden","status":403,"detail":"Your role (viewer) cannot delete invoices."}

404 Not Found The server has nothing at this URL — or will not say whether something exists.

Defined in: RFC 9110 §15.5.5
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Do not retry unchanged: fix the request first.

Typical causes

A typo, a broken link, a deleted or moved page.
A wrong base path or a missing rewrite rule (single-page apps need a fallback to index.html), or a file name with different upper and lower case.
A private resource answered with 404 on purpose to hide it.

How to fix it

Check the URL and the server or router configuration.
Redirect moved pages with 301 or 308, and use 410 for content removed for good.
For single-page apps, serve index.html for unknown paths and show a not-found page in the app.

Example response

HTTP/1.1 404 Not Found
Content-Type: application/problem+json

{"title":"Not found","status":404,"detail":"No order with id 1042."}

405 Method Not Allowed The method (for example POST) is known but not supported at this URL; the Allow header lists the methods that are.

Defined in: RFC 9110 §15.5.6
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Do not retry unchanged: fix the request first.
Headers: Allow

Typical causes

POST or PUT to a static file or a read-only endpoint.
A route that is defined only for GET.

How to fix it

Use a method from the Allow header, or add a handler for this method.
Servers must send Allow with a 405.

Example response

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Content-Length: 0

406 Not Acceptable The server has no representation that matches the request’s Accept headers and will not send a default one.

Defined in: RFC 9110 §15.5.7
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.
Headers: AcceptAccept-LanguageAccept-Encoding

Typical causes

A strict Accept header (for example only application/xml) to an API that only produces JSON.
An Accept-Language or Accept-Encoding with no match on the server.

How to fix it

Send Accept: */* or a type the server offers.
Servers: fall back to a default representation instead of refusing.

Example response

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

{"title":"Not Acceptable","status":406,"detail":"The server has no representation that matches the request’s Accept headers and will not send a default one."}

407 Proxy Authentication Required Like 401, but it is a proxy between you and the server that needs credentials.

Defined in: RFC 9110 §15.5.8
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry with proxy credentials.
Headers: Proxy-AuthenticateProxy-Authorization

Typical causes

A corporate or school proxy that requires a login.
Missing or wrong credentials in the tool’s proxy settings (for example HTTPS_PROXY).

How to fix it

Configure the proxy credentials in the client, or bypass the proxy for this host with NO_PROXY.

Example response

HTTP/1.1 407 Proxy Authentication Required
Content-Type: application/problem+json

{"title":"Proxy Authentication Required","status":407,"detail":"Like 401, but it is a proxy between you and the server that needs credentials."}

408 Request Timeout The server did not receive the complete request in time, and is closing the connection.

Defined in: RFC 9110 §15.5.9
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Safe to retry: RFC 9110 lets the client repeat the request, on a new connection if needed.

Typical causes

A slow or interrupted upload, a weak network connection.
An idle keep-alive connection that the server closes.

How to fix it

Retry the request.
Servers: raise the request timeouts for slow clients or large uploads (nginx client_header_timeout and client_body_timeout).

Example response

HTTP/1.1 408 Request Timeout
Connection: close
Content-Length: 0

409 Conflict The request conflicts with the current state of the resource; the client may be able to resolve it and try again.

Defined in: RFC 9110 §15.5.10
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry after resolving the conflict.

Typical causes

Saving changes to an outdated version of a document or record.
Creating something that already exists, such as a duplicate username.

How to fix it

Fetch the current state, merge or resolve the conflict, and retry.
For safe concurrent edits, send If-Match with the ETag you read (a mismatch then gives 412).

Example response

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

{"title":"Username already taken","status":409,"detail":"Choose another username."}

410 Gone The resource was removed on purpose and will not come back; links to it should be removed.

Defined in: RFC 9110 §15.5.11
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Do not retry unchanged: fix the request first.

Typical causes

Deleted content, expired offers, retired API versions.

How to fix it

Use 410 instead of 404 when the removal is permanent and deliberate.
If there is a replacement, redirect to it with 301 instead.

Example response

HTTP/1.1 410 Gone
Content-Type: application/problem+json

{"title":"Gone","status":410,"detail":"The resource was removed on purpose and will not come back; links to it should be removed."}

411 Length Required The server requires a Content-Length header for this request.

Defined in: RFC 9110 §15.5.12
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry with a Content-Length header.
Headers: Content-Length

Typical causes

A POST or PUT sent with chunked transfer encoding, or with no length, to a server that needs the length.

How to fix it

Send a Content-Length header (buffer the body first if necessary).

Example response

HTTP/1.1 411 Length Required
Content-Type: application/problem+json

{"title":"Length Required","status":411,"detail":"The server requires a Content-Length header for this request."}

412 Precondition Failed A condition in the request headers (If-Match, If-Unmodified-Since, If-None-Match) was false, so nothing was changed.

Defined in: RFC 9110 §15.5.13
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Re-read the resource, then retry with the current ETag.
Headers: If-MatchIf-None-MatchIf-Unmodified-SinceETag

Typical causes

Optimistic locking: the resource changed after you read its ETag.
If-None-Match: * on a create, when the resource already exists.

How to fix it

GET the resource again to get the current ETag, re-apply your change, and retry.

Example response

HTTP/1.1 412 Precondition Failed
Content-Type: application/problem+json

{"title":"Precondition Failed","status":412,"detail":"A condition in the request headers (If-Match, If-Unmodified-Since, If-None-Match) was false, so nothing was changed."}

413 Content Too Large The request body is larger than the server is willing or able to accept.

Defined in: RFC 9110 §15.5.14
Also called: Payload Too Large, Request Entity Too Large
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry only with a smaller body — or later, if the server sent Retry-After (then the limit is temporary).
Headers: Retry-After

Typical causes

An upload above the server’s limit: nginx allows 1 MB by default (client_max_body_size); Apache uses LimitRequestBody.
A load balancer’s or API gateway’s limit, or a framework check such as Laravel’s against PHP’s post_max_size.

How to fix it

Raise the limit on the server (nginx: client_max_body_size 50m;), or upload in smaller parts.
Compress or split the payload.

Example response

HTTP/1.1 413 Content Too Large
Content-Type: application/problem+json

{"title":"Content Too Large","status":413,"detail":"The request body is larger than the server is willing or able to accept."}

414 URI Too Long The URL is longer than the server is willing to interpret.

Defined in: RFC 9110 §15.5.15
Also called: Request-URI Too Long
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Do not retry unchanged: fix the request first.

Typical causes

Too much data in the query string — a GET that should be a POST.
A redirect loop that keeps adding to the URL.

How to fix it

Send large data in a POST body instead.
Check for redirect loops; servers can raise the limit (nginx large_client_header_buffers).

Example response

HTTP/1.1 414 URI Too Long
Content-Type: application/problem+json

{"title":"URI Too Long","status":414,"detail":"The URL is longer than the server is willing to interpret."}

415 Unsupported Media Type The server does not accept the format of the request body (its Content-Type or Content-Encoding).

Defined in: RFC 9110 §15.5.16
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.
Headers: Content-TypeContent-EncodingAcceptAccept-Encoding

Typical causes

JSON sent without Content-Type: application/json, or as text/plain or form data.
A file type or compression the endpoint does not accept.

How to fix it

Send the right Content-Type (look it up with the MIME Type Lookup).
Servers can list what they accept in an Accept or Accept-Encoding response header.

Example response

HTTP/1.1 415 Unsupported Media Type
Accept: application/json
Content-Type: application/problem+json

{"title":"Unsupported media type","status":415,"detail":"Send the body as application/json."}

416 Range Not Satisfiable The requested byte range is outside the file, or the client asked for too many small ranges.

Defined in: RFC 9110 §15.5.17
Also called: Requested Range Not Satisfiable
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry without Range (or with a valid one).
Headers: RangeContent-Range

Typical causes

Resuming a download of a file that has since changed or shrunk.
A range that starts beyond the end of the file.

How to fix it

Request the file without Range, or from byte 0. Content-Range: bytes */47022 in the response gives the real size.

Example response

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

417 Expectation Failed A server on the way cannot meet the request’s Expect header — in practice, Expect: 100-continue.

Defined in: RFC 9110 §15.5.18
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry without the Expect header.
Headers: Expect

Typical causes

An old proxy or server that does not support Expect: 100-continue.

How to fix it

Send the request without Expect (curl: -H "Expect:").

Example response

HTTP/1.1 417 Expectation Failed
Content-Type: application/problem+json

{"title":"Expectation Failed","status":417,"detail":"A server on the way cannot meet the request’s Expect header — in practice, Expect: 100-continue."}

418 (Unused) Reserved Reserved because of “I’m a teapot”, from an April Fools’ RFC (RFC 2324). It has no meaning in HTTP and will not be assigned to anything else.

RFC 9110 reserves it because the joke has been deployed often enough to make the code unusable for anything real.

Defined in: RFC 9110 §15.5.19
Also called: I’m a teapot, I'm a teapot
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Not meaningful.

Typical causes

Easter eggs and joke endpoints.

How to fix it

Do not use it in real APIs; choose a real 4xx code.

Example response

HTTP/1.1 418 (Unused)
Content-Type: application/problem+json

{"title":"","status":418,"detail":"Reserved because of “I’m a teapot”, from an April Fools’ RFC (RFC 2324)."}

421 Misdirected Request The request reached a server that cannot answer for this host — often a reused HTTP/2 or HTTP/3 connection whose certificate covers several names.

Defined in: RFC 9110 §15.5.20
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: May be retried on a new connection, even for POST (RFC 9110).

Typical causes

Connection reuse (coalescing): the browser sent a request for another host over an existing connection.
A Host header or SNI that does not match the server’s configuration.

How to fix it

Clients can retry on a fresh connection.
Servers: configure every name on the certificate, or use separate certificates or IP addresses.

Example response

HTTP/1.1 421 Misdirected Request
Content-Type: application/problem+json

{"title":"Misdirected Request","status":421,"detail":"The request reached a server that cannot answer for this host — often a reused HTTP/2 or HTTP/3 connection whose certificate covers several names."}

422 Unprocessable Content The request is well-formed and in a supported format, but its content is invalid — the usual code for validation errors.

Defined in: RFC 9110 §15.5.21
Also called: Unprocessable Entity
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

Validation failed: an invalid email address, an end date before the start date, an unknown option.

How to fix it

Read the error details and fix the data.
Servers: name each invalid field, for example in a problem+json errors list (RFC 9457).

Example response

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

{"title":"Your request is not valid","status":422,"errors":[{"detail":"must be a valid email address","pointer":"#/email"},{"detail":"must be after start_date","pointer":"#/end_date"}]}

423 Locked WebDAV: the resource is locked.

Defined in: RFC 4918 §11.3
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry after the lock is released.

Typical causes

Another user or program holds a WebDAV lock, for example on an open document.

How to fix it

Wait for the lock to be released, or send the lock token in an If header if the lock is yours.

Example response

HTTP/1.1 423 Locked
Content-Type: application/problem+json

{"title":"Locked","status":423,"detail":"WebDAV: the resource is locked."}

424 Failed Dependency WebDAV: the action failed because another action it depended on failed.

Defined in: RFC 4918 §11.4
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Fix the failed action first, then retry.

Typical causes

One command in a PROPPATCH failed, so the others fail with 424.

How to fix it

Find and fix the action that failed first.

Example response

HTTP/1.1 424 Failed Dependency
Content-Type: application/problem+json

{"title":"Failed Dependency","status":424,"detail":"WebDAV: the action failed because another action it depended on failed."}

425 Too Early The server will not risk processing a request sent in TLS 1.3 early data (0-RTT), because early data can be replayed.

Defined in: RFC 8470 §5.2
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry once the TLS handshake has finished (not in early data); clients should do this automatically.

Typical causes

A request sent as 0-RTT early data that is not safe to replay.

How to fix it

Clients and proxies retry automatically after the handshake; nothing to do in most cases.

Example response

HTTP/1.1 425 Too Early
Content-Type: application/problem+json

{"title":"Too Early","status":425,"detail":"The server will not risk processing a request sent in TLS 1.3 early data (0-RTT), because early data can be replayed."}

426 Upgrade Required The server refuses the request over the current protocol and names the protocol to use in the Upgrade header.

Defined in: RFC 9110 §15.5.22
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry with the protocol named in Upgrade.
Headers: Upgrade

Typical causes

A plain request to an endpoint that requires another protocol, such as WebSocket or a newer HTTP version.

How to fix it

Switch to the protocol named in the Upgrade header.

Example response

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.

428 Precondition Required The server requires the request to be conditional (usually with If-Match), to prevent lost updates.

Defined in: RFC 6585 §3
Caching: Never cached. Must not be stored by a cache (RFC 6585).
Retry: Retry with a precondition such as If-Match.
Headers: If-Match

Typical causes

An update without If-Match on an API that uses optimistic concurrency.

How to fix it

GET the resource, then send the update with If-Match: <ETag>.

Example response

HTTP/1.1 428 Precondition Required
Content-Type: text/plain

This request is required to be conditional; try using If-Match.

429 Too Many Requests Rate limited: the client sent too many requests in a given amount of time.

Defined in: RFC 6585 §4
Caching: Never cached. Must not be stored by a cache (RFC 6585).
Retry: Wait for the time in Retry-After (seconds or a date) if present; otherwise back off exponentially with some randomness.
Headers: Retry-After

Typical causes

Going over an API’s rate limit or quota.
Scraping, retries without backoff, or a burst of parallel requests.

How to fix it

Honour Retry-After before retrying.
Cache responses, batch requests and spread them out; many APIs announce limits in X-RateLimit-… headers.

Example response

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
Content-Type: application/problem+json

{"title":"Too many requests","status":429,"detail":"The limit is 50 requests per hour. Try again in an hour."}

431 Request Header Fields Too Large The request headers are too large — most often too many or too big cookies.

Defined in: RFC 6585 §5
Caching: Never cached. Must not be stored by a cache (RFC 6585).
Retry: Retry after making the headers smaller.

Typical causes

Cookies piling up for a domain, a very large Authorization token, a long Referer.

How to fix it

Clear the site’s cookies; keep cookies and tokens small.
Servers can raise their limits (Node.js: --max-http-header-size). nginx answers 400 “Request Header Or Cookie Too Large” instead.

Example response

HTTP/1.1 431 Request Header Fields Too Large
Content-Type: application/problem+json

{"title":"Request Header Fields Too Large","status":431,"detail":"The request headers are too large — most often too many or too big cookies."}

444 No Response nginx nginx closes the connection without sending any response. The client sees an empty reply or a reset connection; the access log shows 444.

Defined in: nginx return directive
Caching: Not sent to clients. Does not apply: clients never receive this code as such (see the meaning above).
Retry: Pointless: the server chose to drop the request.

Typical causes

return 444; in the nginx configuration, typically to drop requests for unknown host names, bots or exploit scanners.

How to fix it

If it is unexpected, look for return 444 in the server blocks that match the request’s Host header.

Example response

(no response: nginx closes the connection)

451 Unavailable For Legal Reasons Access is denied because of a legal demand, such as a court order or a government block.

Defined in: RFC 7725 §3
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Not while the legal demand applies.
Headers: Link

Typical causes

Takedown orders, legal geo-blocking, blocks by an ISP or a search engine.

How to fix it

The response should explain the demand and who made it; a Link header with rel="blocked-by" can name the blocking party.

Example response

HTTP/1.1 451 Unavailable For Legal Reasons
Link: <https://spqr.example.org/legislatione>; rel="blocked-by"
Content-Type: text/html

<h1>Unavailable For Legal Reasons</h1>

460 Client Closed Connection AWS load balancer The client closed its connection to the load balancer before the idle timeout elapsed. It appears in ALB logs and metrics.

Defined in: AWS Application Load Balancer troubleshooting: HTTP 460
Caching: Not sent to clients. Does not apply: clients never receive this code as such (see the meaning above).
Retry: The client gave up; check its timeout.

Typical causes

A client timeout shorter than the time the target needs to respond.

How to fix it

Make the target respond sooner, or raise the client timeout to match the load balancer’s idle timeout.

Example response

(nothing is sent: the client had already closed the connection)

463 Too Many X-Forwarded-For Addresses AWS load balancer The X-Forwarded-For header has more than 30 IP addresses, the limit of an Application Load Balancer.

Defined in: AWS Application Load Balancer troubleshooting: HTTP 463
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

A chain of proxies that keeps appending to X-Forwarded-For, or a forwarding loop.

How to fix it

Find the proxy loop, or stop proxies from appending addresses they do not need to.

Example response

HTTP/1.1 463 Too Many X-Forwarded-For Addresses
Server: awselb/2.0
Content-Type: text/html

(an HTML error page generated by the load balancer)

464 Incompatible Protocol AWS load balancer The request’s protocol does not match the target group’s protocol version (for example HTTP/1.1 to a gRPC or HTTP/2 target group).

Defined in: AWS Application Load Balancer troubleshooting: HTTP 464
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

HTTP/1.1 requests to a gRPC or HTTP/2 target group, gRPC to an HTTP/1.1 one, or a non-POST HTTP/2 request to a gRPC target group.

How to fix it

Make the client protocol and the target group protocol version match.

Example response

HTTP/1.1 464 Incompatible Protocol
Server: awselb/2.0
Content-Type: text/html

(an HTML error page generated by the load balancer)

494 Request Header Too Large nginx nginx’s internal code for oversized request headers or cookies. The client receives 400 “Request Header Or Cookie Too Large”; 494 exists only inside nginx, for error_page.

Defined in: nginx source (ngx_http_request.h)
Caching: Not sent to clients. Does not apply: clients never receive this code as such (see the meaning above).
Retry: Retry after reducing the headers (clear cookies).

Typical causes

Large cookies or tokens that exceed large_client_header_buffers.

How to fix it

Clear the site’s cookies; on the server, raise large_client_header_buffers if large headers are expected.

Example response

HTTP/1.1 400 Bad Request
Content-Type: text/html

<title>400 Request Header Or Cookie Too Large</title>

495 SSL Certificate Error nginx nginx could not verify the client certificate (mutual TLS). The client receives 400 “The SSL certificate error”.

Defined in: nginx ssl module: error processing
Caching: Not sent to clients. Does not apply: clients never receive this code as such (see the meaning above).
Retry: Do not retry unchanged: fix the request first.

Typical causes

An expired, untrusted or wrongly signed client certificate when ssl_verify_client is on.

How to fix it

Check the client certificate and the CA configured in ssl_client_certificate; error_page 495 can show a friendlier page.

Example response

HTTP/1.1 400 Bad Request
Content-Type: text/html

<title>400 The SSL certificate error</title>

496 SSL Certificate Required nginx nginx requires a client certificate and none was sent. The client receives 400 “No required SSL certificate was sent”.

Defined in: nginx ssl module: error processing
Caching: Not sent to clients. Does not apply: clients never receive this code as such (see the meaning above).
Retry: Retry with a client certificate.

Typical causes

ssl_verify_client on; and a client without a certificate.

How to fix it

Configure the client to present its certificate (curl: --cert and --key).

Example response

HTTP/1.1 400 Bad Request
Content-Type: text/html

<title>400 No required SSL certificate was sent</title>

497 HTTP Request Sent to HTTPS Port nginx A plain HTTP request arrived on nginx’s HTTPS port. The client receives 400 “The plain HTTP request was sent to HTTPS port”.

Defined in: nginx ssl module: error processing
Caching: Not sent to clients. Does not apply: clients never receive this code as such (see the meaning above).
Retry: Retry with https://.

Typical causes

Typing http:// with an explicit HTTPS port, or a proxy forwarding plain HTTP to port 443.

How to fix it

Use https://. To redirect such requests automatically, add error_page 497 https://$host$request_uri; to the HTTPS server block.

Example response

HTTP/1.1 400 Bad Request
Content-Type: text/html

<title>400 The plain HTTP request was sent to HTTPS port</title>

499 Client Closed Request nginx The client closed the connection before nginx sent the response. It only appears in nginx logs — the client never receives it.

Defined in: nginx source (ngx_http_request.h)
Caching: Not sent to clients. Does not apply: clients never receive this code as such (see the meaning above).
Retry: The client gave up; check whether it timed out.

Typical causes

Users navigating away, client or load-balancer timeouts shorter than the request takes, impatient health checks.

How to fix it

Find slow requests (log $request_time) and speed them up, or raise the client or load-balancer timeout.
With proxy_ignore_client_abort on; nginx keeps waiting for the upstream response anyway.

Example response

(nothing is sent: the client had already closed the connection)

5xx Server error

21 codes

The server failed to fulfil an apparently valid request (RFC 9110 §15.6).

500 Internal Server Error The server hit an unexpected condition — the generic “something broke on our side”.

Defined in: RFC 9110 §15.6.1
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

An unhandled exception or crash in the application.
Configuration problems: a broken .htaccess, script permissions, missing environment variables, a database that cannot be reached.

How to fix it

Check the application and server error logs for the time of the request.
Developers: catch errors and return a specific code (400, 404, 409, 503…) where one fits.

Example response

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

{"title":"Internal server error","status":500,"detail":"Something went wrong. Reference: req_7f3a2b"}

501 Not Implemented The server does not support the functionality required — typically an HTTP method it does not recognise at all.

Defined in: RFC 9110 §15.6.2
Caching: Cacheable by default. Cacheable by default: a cache may reuse it for a heuristic period unless Cache-Control or the method says otherwise (RFC 9110 §15.1, RFC 9111 §4.2.2).
Retry: Do not retry unchanged: fix the request first.

Typical causes

An unknown or unsupported method, such as a WebDAV method sent to an ordinary web server.

How to fix it

Use a supported method. When the method is known but not allowed at this URL, servers should answer 405.

Example response

HTTP/1.1 501 Not Implemented
Content-Type: application/problem+json

{"title":"Not Implemented","status":501,"detail":"The server does not support the functionality required — typically an HTTP method it does not recognise at all."}

502 Bad Gateway A gateway or proxy (nginx, a load balancer, a CDN) received an invalid response — or none — from the server behind it.

Defined in: RFC 9110 §15.6.3
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

The application behind the proxy crashed, is restarting, or closed the connection.
A wrong upstream address or port, a TLS mismatch between proxy and upstream, or response headers too large for the proxy’s buffers.

How to fix it

Check that the upstream service is running and reachable from the proxy host (curl it from there).
Read the proxy’s error log — nginx logs messages such as “connect() failed … while connecting to upstream” or “upstream prematurely closed connection”.

Example response

HTTP/1.1 502 Bad Gateway
Content-Type: application/problem+json

{"title":"Bad Gateway","status":502,"detail":"A gateway or proxy (nginx, a load balancer, a CDN) received an invalid response — or none — from the server behind it."}

503 Service Unavailable The server is temporarily unable to handle the request — overloaded or down for maintenance.

Defined in: RFC 9110 §15.6.4
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry later; wait for the time in Retry-After if the server sent one.
Headers: Retry-After

Typical causes

Maintenance mode, a deploy in progress, overload, exhausted workers, a load balancer with no healthy servers.

How to fix it

Send Retry-After during planned maintenance. For websites, 503 also tells search engines the outage is temporary.
Scale out, add capacity or shed load.

Example response

HTTP/1.1 503 Service Unavailable
Retry-After: 120
Content-Type: text/html; charset=utf-8

<h1>Down for maintenance — back in a few minutes</h1>

504 Gateway Timeout A gateway or proxy did not get a response from the server behind it in time.

Defined in: RFC 9110 §15.6.5
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

A slow database query or API call, an overloaded upstream, long work done inside the request.

How to fix it

Make the upstream faster, or move long work to a background job (answer 202 and let the client poll).
If the work is legitimately long, raise the proxy timeout (nginx proxy_read_timeout, 60 seconds by default).

Example response

HTTP/1.1 504 Gateway Timeout
Content-Type: application/problem+json

{"title":"Gateway Timeout","status":504,"detail":"A gateway or proxy did not get a response from the server behind it in time."}

505 HTTP Version Not Supported The server does not support the major HTTP version used in the request.

Defined in: RFC 9110 §15.6.6
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

A client using a version the server does not implement, or a malformed request line.

How to fix it

Use HTTP/1.1, and check proxies or scripts that build the request line by hand.

Example response

HTTP/1.1 505 HTTP Version Not Supported
Content-Type: application/problem+json

{"title":"HTTP Version Not Supported","status":505,"detail":"The server does not support the major HTTP version used in the request."}

506 Variant Also Negotiates A server configuration error in transparent content negotiation: the chosen variant is itself set up to negotiate.

Defined in: RFC 2295 §8.1
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Not until the server configuration is fixed.

Typical causes

A misconfigured content-negotiation setup (very rare).

How to fix it

Fix the negotiation configuration on the server.

Example response

HTTP/1.1 506 Variant Also Negotiates
Content-Type: application/problem+json

{"title":"Variant Also Negotiates","status":506,"detail":"A server configuration error in transparent content negotiation: the chosen variant is itself set up to negotiate."}

507 Insufficient Storage WebDAV: the server cannot store what the request needs — the disk or quota is full.

Defined in: RFC 4918 §11.5
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: RFC 4918: do not repeat the request until the user asks again.

Typical causes

A full disk or an exhausted storage quota on a WebDAV or file server.

How to fix it

Free space or raise the quota, then try again.

Example response

HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json

{"title":"Insufficient Storage","status":507,"detail":"WebDAV: the server cannot store what the request needs — the disk or quota is full."}

508 Loop Detected WebDAV: the server found an infinite loop of bindings while processing a Depth: infinity request.

Defined in: RFC 5842 §7.2
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

Collections bound inside each other in a loop.

How to fix it

Remove the binding loop, or avoid Depth: infinity.

Example response

HTTP/1.1 508 Loop Detected
Content-Type: application/problem+json

{"title":"Loop Detected","status":508,"detail":"WebDAV: the server found an infinite loop of bindings while processing a Depth: infinity request."}

510 Not Extended (OBSOLETED) Obsolete Obsolete: the request lacked an extension the server required, under the HTTP Extension Framework (RFC 2774), which is now Historic.

Defined in: RFC 2774 §7
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Not meaningful today.

Typical causes

Software built on the abandoned HTTP Extension Framework.

How to fix it

Do not use it.

Example response

HTTP/1.1 510 Not Extended (OBSOLETED)
Content-Type: application/problem+json

{"title":"Not Extended","status":510,"detail":"Obsolete: the request lacked an extension the server required, under the HTTP Extension Framework (RFC 2774), which is now Historic."}

511 Network Authentication Required You need to sign in to the network itself — a captive portal on hotel, airport or café Wi-Fi — not to the website.

Defined in: RFC 6585 §6
Caching: Never cached. Must not be stored by a cache (RFC 6585).
Retry: Retry after signing in to the network.

Typical causes

A captive portal intercepts traffic until you log in or accept its terms.

How to fix it

Open any web page in a browser to reach the portal’s login page. Websites themselves should never send 511.

Example response

HTTP/1.1 511 Network Authentication Required
Content-Type: application/problem+json

{"title":"Network Authentication Required","status":511,"detail":"You need to sign in to the network itself — a captive portal on hotel, airport or café Wi-Fi — not to the website."}

520 Web Server Returns an Unknown Error Cloudflare The origin server returned an empty, unknown or unexpected response to Cloudflare.

Defined in: Cloudflare 5xx errors: 520
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

The origin crashed or is misconfigured, or a firewall at the origin blocks Cloudflare’s IP addresses.
Response headers over 128 KB (often too many cookies), or an empty or malformed response.
An HTTP/2 set-up at the origin that does not really work.

How to fix it

Check the origin’s error logs for crashes at that time; allow Cloudflare’s IP ranges.
Make headers smaller; disable HTTP/2 to Origin in Cloudflare to test.

Example response

HTTP/1.1 520 Web Server Returns an Unknown Error
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 520, with the Ray ID)

521 Web Server Is Down Cloudflare The origin server refused the connection from Cloudflare.

Defined in: Cloudflare 5xx errors: 521
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

The web server is offline, or security software at the origin blocks Cloudflare’s IP addresses.
Nothing is listening on the port the SSL/TLS mode needs (80 for Flexible, 443 for Full and Full strict).

How to fix it

Start the web server and check its logs.
Allow all Cloudflare IP ranges in the firewall, and make sure the right port is open.

Example response

HTTP/1.1 521 Web Server Is Down
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 521, with the Ray ID)

522 Connection Timed Out Cloudflare Cloudflare timed out connecting to the origin: no TCP answer within 19 seconds, or no acknowledgement of the request within 90 seconds.

Defined in: Cloudflare 5xx errors: 522
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

Cloudflare’s IP addresses are blocked or rate-limited at the origin (the most common cause).
An overloaded or offline origin, or a wrong origin IP in Cloudflare DNS.

How to fix it

Allow all Cloudflare IP ranges; check that the DNS record points at the current origin IP.
Check the origin’s load and network.

Example response

HTTP/1.1 522 Connection Timed Out
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 522, with the Ray ID)

523 Origin Is Unreachable Cloudflare Cloudflare cannot reach the origin server — usually there is no network route to its IP address.

Defined in: Cloudflare 5xx errors: 523
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

A wrong A or AAAA record in Cloudflare DNS, or a routing problem between Cloudflare and the origin.

How to fix it

Check the origin IP in Cloudflare DNS; check routing (traceroute) from the origin to Cloudflare.

Example response

HTTP/1.1 523 Origin Is Unreachable
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 523, with the Ray ID)

524 A Timeout Occurred Cloudflare Cloudflare connected to the origin, but the origin did not send an HTTP response before the Proxy Read Timeout (125 seconds by default).

Defined in: Cloudflare 5xx errors: 524
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Often temporary. Retry idempotent requests (GET, HEAD, PUT, DELETE) with exponential backoff; retry POST only if the API makes it safe (idempotency keys).

Typical causes

A long-running request (large export, heavy query) or an overloaded origin.

How to fix it

Speed up the request, or run long jobs in the background and poll for the result.
Serve long requests from a hostname that is not proxied (DNS only); Enterprise plans can raise the timeout.

Example response

HTTP/1.1 524 A Timeout Occurred
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 524, with the Ray ID)

525 SSL Handshake Failed Cloudflare The TLS handshake between Cloudflare and the origin failed (with SSL/TLS mode Full or Full strict).

Defined in: Cloudflare 5xx errors: 525
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

No valid certificate on the origin, port 443 closed, no SNI support, or no cipher suite in common with Cloudflare.

How to fix it

Install a certificate on the origin (a free Cloudflare Origin CA certificate works) and open port 443.

Example response

HTTP/1.1 525 SSL Handshake Failed
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 525, with the Ray ID)

526 Invalid SSL Certificate Cloudflare Cloudflare could not validate the origin’s certificate (with SSL/TLS mode Full strict).

Defined in: Cloudflare 5xx errors: 526
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

An expired, revoked or self-signed certificate, a host name missing from it, or an incomplete certificate chain.

How to fix it

Fix or renew the origin certificate and serve the full chain, or use a Cloudflare Origin CA certificate. Check it with the SSL Certificate Checker.

Example response

HTTP/1.1 526 Invalid SSL Certificate
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 526, with the Ray ID)

530 Origin DNS Error Cloudflare Cloudflare cannot resolve the origin’s host name. The page shows a Cloudflare 1xxx error code with the details.

Defined in: Cloudflare 5xx errors: 530
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

A problem resolving the origin host name; the 1xxx code in the response says which.

How to fix it

Look up the 1xxx error shown on the page in Cloudflare’s documentation.

Example response

HTTP/1.1 530 Origin DNS Error
Server: cloudflare
CF-RAY: 8a1b2c3d4e5f6a7b-BOM
Content-Type: text/html; charset=UTF-8

(Cloudflare’s HTML error page for error 530, with the Ray ID)

561 Unauthorized AWS load balancer A listener rule authenticates users, and the identity provider returned an error.

Defined in: AWS Application Load Balancer troubleshooting: HTTP 561
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Do not retry unchanged: fix the request first.

Typical causes

An identity provider (OIDC or Cognito) error during sign-in.

How to fix it

Check the ALB access logs for the error reason code, and the identity provider configuration.

Example response

HTTP/1.1 561 Unauthorized
Server: awselb/2.0
Content-Type: text/html

(an HTML error page generated by the load balancer)

562 JWKS Request Failed AWS load balancer The load balancer could not get a valid answer from the JWKS (JSON Web Key Set) endpoint it uses to verify tokens.

Defined in: AWS Application Load Balancer troubleshooting: HTTP 562
Caching: Cached only if told. Not cacheable by default: caches store it only with explicit freshness information, such as Cache-Control: max-age or Expires (RFC 9111 §3).
Retry: Retry after the JWKS endpoint is fixed.

Typical causes

The JWKS endpoint returned an error status, invalid JSON or keys it cannot use.

How to fix it

Check that the JWKS URL answers with 2xx and a valid key set.

Example response

HTTP/1.1 562 JWKS Request Failed
Server: awselb/2.0
Content-Type: text/html

(an HTML error page generated by the load balancer)

Registered codes: IANA HTTP Status Code Registry. Vendor codes from the nginx, Cloudflare and AWS documentation.

Next steps

About the HTTP Status Codes Reference

Search all 64 status codes in the IANA registry — from 100 Continue to 511 Network Authentication Required — plus the non-standard codes you meet in logs and error pages: nginx 444 and 499, Cloudflare 520–526 and 530, and AWS load balancer codes such as 460 and 463.

Every entry gives the meaning in plain words, the RFC section that defines it, whether caches may store it, whether and when to retry, the typical causes, how to fix it and an example response you can copy. Search by number, by status line, by an old name such as “Payload Too Large”, or by the problem you have — “rate limit”, “timeout”, “cookie”.

How to use it

Type a code (404, error 520), a class (5xx), a status line (HTTP/1.1 503 Service Unavailable), part of a name (too large) or a problem (rate limit, timeout, cookie).
Narrow the list to one class (1xx–5xx), or untick the nginx, Cloudflare and AWS codes to see only registered ones; Reset shows every code again.
Open a code to see its meaning, defining RFC section, caching and retry rules, typical causes and fixes.
Copy the example response, or copy a link that opens that code directly (for example /tools/http-status-codes/#code-404).

Examples

Search by problem

Input

rate limit

Result

429 Too Many Requests — Retry after the time in Retry-After; responses must not be cached (RFC 6585 §4).

Search by an old name

Input

payload too large

Result

413 Content Too Large (formerly Payload Too Large / Request Entity Too Large) — RFC 9110 §15.5.14

A code from an nginx log

Input

Result

499 Client Closed Request (nginx) — the client closed the connection before nginx answered; the client never receives this code.

Common uses

Choosing the right status code for an API response or a redirect.
Understanding a code from a browser, a log file, curl or an error page — including nginx and Cloudflare codes that are not in the RFCs.
Deciding whether a client should retry and whether a CDN may cache a response.
Writing error handling and alerts that treat each class correctly.

The five classes

The first digit is the class: 1xx informational (interim), 2xx success, 3xx redirection, 4xx client error and 5xx server error. Valid codes run from 100 to 599. A client that meets a code it does not know must treat it like the x00 code of its class — an unknown 471 is handled as 400 (RFC 9110 §15).

The reason phrase (“Not Found”) is only a recommendation and can be anything. HTTP/2 and HTTP/3 send just the number, in the :status pseudo-header (RFC 9113 §8.3.2).

Commonly confused codes

301 vs 302 vs 303 vs 307 vs 308: 301 and 308 are permanent, 302 and 307 temporary. 307 and 308 keep the method and body; with 301 and 302 browsers may turn a POST into a GET; 303 always means “GET this other URL”. Google Search treats 301 and 308 as permanent and 302, 303 and 307 as temporary.
401 vs 403: 401 means you are not authenticated — send credentials. 403 means the server knows the request and refuses it; logging in again with the same account will not help.
400 vs 422: 400 for requests the server cannot parse or that are malformed; 422 for well-formed requests whose content fails validation.
404 vs 410: 410 says the resource was removed on purpose and is not coming back.
500 vs 502 vs 503 vs 504: 500 is the application failing; 502 is a proxy getting a bad answer from the application; 503 is “temporarily unavailable, try later”; 504 is a proxy giving up waiting for the application.
429 vs 503: 429 limits one client that sent too much; 503 means the whole service is unavailable.

Caching and retries

Only some codes are cacheable by default: 200, 203, 204, 206, 300, 301, 308, 404, 405, 410, 414 and 501 (RFC 9110 §15.1) and 451 (RFC 7725). Other codes are stored only when the response says so with Cache-Control or Expires, and 428, 429, 431 and 511 must never be stored (RFC 6585).

Retrying is safe for idempotent methods — GET, HEAD, OPTIONS, TRACE, PUT and DELETE (RFC 9110 §9.2.2) — after errors such as 408, 502, 503 and 504, with exponential backoff. When a response carries Retry-After (seconds or a date), wait at least that long. Do not retry other 4xx errors unchanged: fix the request first.

Limitations

Vendor codes are limited to those documented by nginx, Cloudflare and AWS. Other products have their own (IIS, for example, uses sub-status codes such as 404.3), which are not listed.
The registry copy is bundled with the page, so codes IANA registers later are missing. The 104 registration is temporary and lapses unless it is renewed.
Causes and fixes are practical starting points. The server, proxy or application logs show the actual reason for a specific error.

Privacy

Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.

Frequently asked questions

What is the difference between 401 and 403?

401 Unauthorized means the request has no valid credentials — log in or send a token and try again. 403 Forbidden means the server understood who you are (or does not care) and refuses: you lack permission, a firewall blocked you, or the file is not readable.

Which redirect code should I use?

For a permanent move use 301 — or 308 if POST requests must stay POST. For a temporary one use 302 or 307 (which keeps the method), and 303 to send the browser to a result page after a form POST. Google treats 301 and 308 as permanent and 302, 303 and 307 as temporary.

What does status 499 mean?

It is nginx’s code for “client closed request”: the client disconnected before nginx sent a response, often because of a client or load-balancer timeout. It only appears in nginx logs — no client ever receives it.

What are Cloudflare errors 520 to 530?

They are generated by Cloudflare when it cannot get a good response from your origin server: 520 unknown error, 521 server down, 522 connection timed out, 523 unreachable, 524 no response before the timeout, 525 TLS handshake failed, 526 invalid certificate and 530 a DNS problem shown with a 1xxx error. Open each one for the documented causes and fixes.

Which status code should an API use for validation errors?

Most APIs use 422 Unprocessable Content when the JSON is valid but a field fails validation, and 400 Bad Request when the request cannot be parsed at all. Either way, return details — the Problem Details format (application/problem+json, RFC 9457) is a good standard.

Should an API return 200 with an error message in the body?

No. Clients, caches, monitoring and retries all decide based on the status code, so an error answered with 200 looks like a success. Use the matching 4xx or 5xx code and put the details in the body.

Does this page send anything to a server?

No. The whole reference is part of the page and searching happens in your browser, so it works offline once loaded.

Find a status code

1xx Informational

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

2xx Success

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

3xx Redirection

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

Typical causes

How to fix it

Example response

4xx Client error

Typical causes

How to fix it

Example response