HTTP 427 Unassigned

Quick reference

RFC 9110 rules for unrecognized status codes

RFC 9110 §15 defines the fallback behavior for status codes a client does not recognize. The rule is: treat an unrecognized code as the x00 code of the same class. The five classes and their fallback codes:

A client receiving 427 knows: the request failed, the failure is in the client-error category (the server is attributing the problem to the request, not to its own internal state), and there is no specific standard meaning available. The response body is the only source of further information.

This fallback mechanism is intentional. HTTP was designed to allow future extension. Clients are required to be tolerant of unrecognized codes in recognized ranges so that new codes can be deployed without breaking existing clients.

Where unassigned codes appear in practice

Custom application error mappings: Some internal APIs assign non-standard codes to specific internal error types. A team might use 427 as a sentinel for a particular business logic failure. This works within a closed system where all clients are written by the same team and can reference internal documentation, but breaks with any external HTTP tool or client.

Framework defaults and bugs: Some web frameworks handle certain edge cases by generating a status code without verifying it is a standard one. A misconfigured error handler, a missing case in a switch statement, or a default value that was never validated can result in non-standard codes appearing in production logs.

Middleware and proxy injection: Reverse proxies, API gateways, and CDN layers sometimes insert custom status codes for internal signaling that was not intended to reach the client. If 427 appears only when traffic passes through a specific intermediary, the intermediary is the source.

Legacy code from older specifications: Some codebases were written against early drafts of HTTP specifications that proposed codes that were never finalized. These draft codes are not the same as the reserved codes (like 306) but can appear in very old software.

Diagnosing an unexpected 427

When 427 appears in your logs or monitoring:

First, read the response body. If the application is intentionally using 427, the body should contain a machine-readable error object or a human-readable explanation. An empty body or an HTML error page suggests the code is being generated by infrastructure (a proxy, load balancer, or web server) rather than the application layer.

Second, trace the request path. Use curl -v or a network proxy to capture the full response including headers. Check whether the 427 comes from your origin server or from an intermediary (CDN, load balancer, API gateway) by comparing the Server header and any CDN-specific headers like CF-Ray (Cloudflare), X-Cache, or Via.

Third, check your middleware and error handlers. Search your codebase for 427 as an integer or string literal. If it appears in error-handling code, that is the source. If it does not appear, the code is being generated externally.

Fourth, check your infrastructure configuration. Load balancers and API gateways often have error code mapping tables. Verify that no rule is translating an internal error signal to 427 before the response reaches the client.

Standard codes to use instead of 427

There is almost always a standard code that accurately describes the error being signaled. Common replacements:

Standard codes are understood by every HTTP client, monitoring tool, APM platform, and on-call engineer without requiring custom documentation. If none of the standard codes accurately describe your error, use the most generic code in the appropriate category (400 for client errors, 500 for server errors) and encode the specific error type in the response body as a machine-readable error code.

Frequently asked questions

What does HTTP 427 mean?

HTTP 427 has no registered meaning in the IANA HTTP Status Code Registry. It is an unassigned code in the 4xx client error range. Any application returning 427 is using it as a custom, non-standard signal. Consult that application’s documentation for its specific meaning.

How should a client handle HTTP 427?

RFC 9110 says an unrecognized 4xx code should be treated as 400 Bad Request. The client knows the request failed due to a client-side issue but has no further information without reading the response body.

What standard code should I use instead of 427?

For rate limiting: 429 Too Many Requests. For authentication: 401 Unauthorized. For authorization: 403 Forbidden. For a bad request format: 400 Bad Request. For a missing resource: 404 Not Found. There is almost always a standard code that fits the error being signaled.

Is there any legitimate use for HTTP 427?

No standardized use. A future RFC could register 427 with defined semantics, at which point it would have a standard meaning. Until then, any use of 427 is non-standard and non-interoperable with generic HTTP clients.

Related guides

HTTP 429 Too Many Requests · HTTP 400 Bad Request · HTTP 430 Unassigned

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 9110 §15. Human-readable guidance by ErrorLookup. · HTTP 427 quick reference →