4xx Status Codes Explained: What Client Errors Really Mean

2026-09-04 Updated: 2026-09-05

A 4xx status code means the server understood the request but will not fulfill it because something about the request itself is wrong. By definition the fault sits on the client side. On a site you own, though, a 4xx is far more often a broken link, a stale rewrite rule or an over-eager firewall than a genuine mistake by the visitor.

What the 4xx class says

RFC 9110 defines the 4xx class as "Client Error": the server believes the client has erred. That covers a request for something that does not exist, a request without the credentials it needs, a request the server refuses on policy grounds, and a request that is malformed or too large.

Three properties of the class matter while you are debugging one:

A 4xx is a final answer for that request as sent. Repeating the identical request will normally produce the identical code.
The response body is meant to be a human-readable explanation. That is why custom error pages exist, and why an empty 404 page is a wasted opportunity.
Some 4xx responses are cacheable by default. RFC 9111 lists 404, 405, 410 and 414 among the codes a cache may store heuristically, so a wrong 404 can outlive the bug that caused it.

The 4xx codes you will meet

400 Bad Request: the request is malformed and the server cannot parse it. Frequently a bad query string, an oversized cookie header or a broken proxy in front of the app.
401 Unauthorized: authentication is required and either missing or invalid. The server must send a WWW-Authenticate header telling the client how to authenticate.
403 Forbidden: the server understood the request and refuses it. Credentials will not help, because the refusal is a policy decision rather than an authentication failure.
404 Not Found: no current representation exists at that URL, or the server will not admit that one does. Covered in detail in the 404 guide.
405 Method Not Allowed: the URL exists but not for that method. The server must list the methods it does accept in an Allow header.
408 Request Timeout: the client took too long to send the request. Different from a 504, where the delay is behind the server.
410 Gone: the resource existed and was deliberately removed, and that is expected to be permanent.
413 Content Too Large and 414 URI Too Long: the request exceeded a configured limit, usually an upload cap or a header-size limit.
429 Too Many Requests: a rate limit was hit. This one bites monitoring setups in particular.

When a 4xx is really a server misconfiguration

The "client error" label is about protocol roles, not about blame. Most 4xx codes that show up on a healthy production site are caused by something on your side. A rewrite or routing rule that no longer matches turns valid URLs into 404s across a whole directory, and the tell is a 404 on many URLs at once rather than on one. A build that stops emitting a hashed asset does the same thing at file level: every page requests a file that returns 404, so the page renders but looks broken.

Security layers account for much of the rest. A WAF rule, a bot filter or a geo-block can return 403 to real traffic, and these are easy to miss because they usually pass for the office IP address. An auth change that leaves a page answering 401 when it should be public is a 4xx caused entirely by the server. So is a 400 or 413 from a reverse proxy whose header or body limit is smaller than the application's, for a request the app would have accepted.

How to diagnose a 4xx on your own site

Read the exact code and headers first. Do not judge by the error page, which may be generic:
```
curl -sS -o /dev/null -D - https://example.com/broken-page
```
This shows the status line plus Allow, WWW-Authenticate, Retry-After and any server or CDN identification header.
Decide whether it is one URL or a pattern. One URL points at a link or a deleted page. A whole path prefix points at routing, permissions or a deploy.
Check who answered. Compare the response from the CDN edge with the response from the origin. A 403 that exists only at the edge is a WAF or bot rule, not your application.
Try a different client identity. A different user agent, an unauthenticated session or a different network can turn the code from 403 to 200, which localizes the block immediately.
Read the server log line for that request. Web server and application logs record which rule or handler produced the code. This is the step that usually ends the investigation.
Fix, then purge caches. Because several 4xx codes are cacheable, a corrected page can keep serving the old error from a CDN or browser cache until the entry is invalidated.

Finding the 4xx pages you never visit

A 4xx does not take a server down, which is why it goes unnoticed. The site loads, the homepage is fine, and one section returns 404 or 403 for everyone but you. A scheduled HTTP check compares the code it receives against the code you expect, so a page that starts answering 403 instead of 200 raises an alert rather than waiting for a support ticket. Where the check runs from matters too. HostTracker checks from 300+ checkpoints in 158 cities, so a geo-block or a regional WAF rule shows up as a real difference between locations instead of a mystery. If the failing code is 500, 502 or 503 instead, the cause is on the server side and the 5xx family guide is the place to start.