If a status code is not in your reference table, it is almost certainly vendor-specific. HTTP 430 is Shopify rejecting a request at its security layer. HTTP 440 is Microsoft IIS telling you the login session expired. HTTP 423 is genuinely standard — RFC 4918, WebDAV — but so rarely used that people assume it is invented. None of these come from your application unless you wrote them yourself, which is the single most useful fact when debugging one.
HTTP 430: two meanings, and the internet gets it wrong
Search for 430 and half the results say "Request Header Fields Too Large". That definition is a historical artefact. An early IETF draft did reserve 430 for oversized headers, but the final specification assigned that meaning to 431, and 430 was left unallocated.
Into that gap stepped Shopify, which uses 430 for something entirely different: a request rejected by its security layer. Suspicious traffic patterns, WAF rules, bot detection. If you are getting 430 from a Shopify storefront or the Shopify API, nothing is wrong with your headers — something decided your request looked hostile.
The most reported cause is shared hosting IPs. Your app runs on a platform where hundreds of other applications share the same outbound address; one of them behaves badly, the address earns a reputation, and your perfectly ordinary API call gets rejected. The symptom is characteristic and maddening: intermittent, unreproducible, and it clears up on its own.
What actually helps, in order:
- Confirm the source. A 430 from Shopify's edge and a 430 from something in your own stack are different problems, and the response headers usually name the responder.
- Move to a dedicated outbound IP if your platform allows it. This resolves the shared-reputation case outright.
- Send a proper, identifiable
User-Agent. Requests with a default library agent — the barepython-requestsoraxiosstring — sit in the same bucket as scrapers. - Back off and retry with a delay. If the rejection is rate-shaped, hammering it makes the reputation worse.
And if you are the one emitting 430 from your own WAF because you saw it somewhere: do not. Use 403 for a refusal you want the client to understand as final, or 429 if it is rate-related. A code no client library recognises will be treated as an unknown 4xx, and most retry logic gives up on it.
HTTP 440: your session died, and only IIS says it this way
440 Login Time-out is Microsoft's. It appears on IIS with forms authentication, and it is the code most people meet through Exchange's Outlook Web Access, where it shows up after a browser tab has been sitting open too long.
It means what it says: the session expired, authenticate again. The reason it deserves a mention at all is that it breaks automated clients in a very specific way. A script that treats 4xx as "my request was wrong" will retry the same request, get 440 again, and loop, when the correct response is to re-authenticate and then retry.
Two related Microsoft codes turn up in the same logs. 449 Retry With asks the client to repeat the request after supplying additional information. 450 indicates a request blocked by Windows Parental Controls. Neither has any meaning outside a Microsoft stack, and if you see them coming from something that is not IIS, you are looking at a proxy in between that decided to invent a code.
HTTP 423: real, standard, and almost never used
423 Locked is defined by RFC 4918 — the WebDAV extensions. The resource exists and you may be entitled to it, but it is currently locked by another process and the request cannot proceed.
It is legitimate, and it is also the one code in this article you might reasonably emit yourself. If your application has a genuine locking model — a document being edited, a record held by a long transaction, a deployment in progress — 423 communicates that far better than a generic 409 Conflict or, worse, a 500. Pair it with Retry-After and a well-behaved client will simply wait.
In practice you will meet it coming from WebDAV servers, from Nextcloud and ONLYOFFICE when a file is open elsewhere, and from a handful of APIs that model locking properly.
The other codes people mistake for invented
| Code | Status | What it means | Who sends it |
|---|---|---|---|
| 421 | Standard | Misdirected Request — this server cannot answer for that hostname | HTTP/2 servers with connection reuse |
| 423 | Standard (RFC 4918) | Locked | WebDAV, collaborative editors |
| 429 | Standard | Too Many Requests | APIs, rate limiters, WAFs |
| 430 | Vendor | Security rejection | Shopify |
| 431 | Standard | Request Header Fields Too Large | Any server with a header size limit |
| 440 | Vendor | Login Time-out | Microsoft IIS, Exchange OWA |
| 449 | Vendor | Retry With | Microsoft IIS |
| 450 | Vendor | Blocked by Windows Parental Controls | Microsoft |
| 451 | Standard (RFC 7725) | Unavailable For Legal Reasons | Anyone complying with a takedown |
421 is worth a second look because it produces one of the strangest bugs in shared hosting. Under HTTP/2 a browser may reuse an existing connection for a second hostname that resolves to the same IP and is covered by the same certificate. If that server is not configured to serve the second hostname, the correct answer is 421 — and the visitor sees a site that works in one tab and fails in another, seemingly at random.
Finding out which layer answered
An unusual status code is usually not from your application, and the fastest way to prove it is to walk inward through the stack.
# 1. What the client sees, headers and all
curl -sSI https://example.com/path
# 2. Skip the CDN, go straight to the origin
curl -sSI https://example.com/path --resolve example.com:443:ORIGIN_IP
# 3. Skip the web server, ask the application directly
curl -sSI http://127.0.0.1:3000/pathWhere the code disappears is where it was born. If step 1 shows 430 and step 2 shows 200, something at the edge rejected you. If it survives all three, it is your application — and now you know to grep your own code rather than your provider's documentation.
The response headers are the other half. A Server header naming a specific product, a CF-Ray, an X-Powered-By, or a vendor-branded error body all tell you who is speaking. Codes in the 4xx range that no RFC defines are, essentially without exception, somebody's security layer explaining itself in a private dialect.
For the codes that are standard and that you will meet daily, our reference on what 301, 403, 404, 500, 502 and 503 mean covers them, and the Cloudflare-specific numbers have their own page on errors 521 and 522.
Frequently asked questions
What does HTTP 430 mean?
On Shopify it means the request was rejected by their security layer — bot detection, a WAF rule or a reputation problem with the calling IP address. It is not a standard code. An early IETF draft reserved 430 for "Request Header Fields Too Large", but the final specification gave that meaning to 431 instead, which is why older references disagree.
How do I fix a 430 error?
Move to a dedicated outbound IP address if your requests originate from shared hosting, send an identifiable User-Agent instead of a default library string, and back off rather than retrying immediately. If the 430 comes from a browser rather than an API client, clearing cookies for the domain resolves the cases caused by an oversized or malformed session cookie.
What is HTTP 440?
A Microsoft IIS code meaning Login Time-out: the session expired and the client must authenticate again. It is most commonly seen in Exchange Outlook Web Access. Automated clients should re-authenticate rather than retry the original request.
Is HTTP 423 a real status code?
Yes. 423 Locked is defined in RFC 4918 as part of the WebDAV extensions and means the resource is locked by another process. It is legitimate to use in your own application when you have a genuine locking model, ideally with a Retry-After header.
How do I find out which server sent an unusual status code?
Request the same path three times: through the public URL, directly against the origin IP with --resolve, and against the application's local port. The layer where the code stops appearing is the layer that produced it. Response headers such as Server and CF-Ray identify the responder.