Is 400 a client or a server problem?

A client problem, by definition. RFC 9110 §15.5.1 says the server cannot or will not process the request because it perceives a client error — malformed syntax, bad framing, or deceptive routing. Repeating the same request unchanged will fail the same way.

Why do I get '400 Bad Request: Request Header Or Cookie Too Large'?

That's nginx's message for headers that overflow its buffer. nginx predates RFC 6585's 431 code, so it returns 400 instead. The default large_client_header_buffers is 8KB per header line; a bloated Cookie or a large JWT blows past it. Clear cookies or shrink the token.

Is 400 the same as 431 or 422?

No. 431 (RFC 6585) means the headers are well-formed but too large. 422 means the request is syntactically valid but semantically wrong. 400 means the request itself is malformed at the syntax or framing level.

Views: 16

400 Bad Request Checklist

400 Bad Request? Separate malformed syntax from oversized headers or cookies, then see which layer rejected it. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

The final response code for the request is 400 Bad Request.

Symptoms

HTTP Check shows a final status code of 400.
The browser shows a plain “Bad Request” page, sometimes with “Request Header Or Cookie Too Large.”
It may hit one client and not another, or clear after you delete cookies for the site.

What 400 Actually Means

RFC 9110 (§15.5.1) defines 400 as the server being unable or unwilling to process the request “due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).” The key word is perceived: the server has decided the request is broken before it even tries to fulfill it, so it never reaches your application logic.

That makes 400 different from a 500. A 500 is the application failing on a request it accepted. A 400 is the request being rejected at the door. The spec also notes a client “SHOULD NOT repeat the request without modifications” — sending the identical bytes again will earn the identical 400.

Top 3 Causes

Oversized headers or cookies - The most common 400 people actually hit. Accumulated cookies, a large JWT, or a flood of proxy-added headers overflow the server’s buffer. nginx reports this as 400 Request Header Or Cookie Too Large because its large_client_header_buffers default (8KB per line) is exceeded.
Malformed request syntax or framing - A buggy client, broken proxy, or hand-crafted request sends an illegal character in the URL, a bad Content-Length, or invalid HTTP framing. The server can’t parse it, so it refuses.
Host or routing mismatch - A Host header that matches no server block, an SNI/Host mismatch behind TLS, or a proxy that rewrites the request into a shape the origin treats as deceptive routing.

Diagnose with DechoNet

HTTP Check to confirm the final code is 400 and inspect the response — including whether the body names an oversized header or cookie.
DNS Lookup to confirm the request is reaching the intended host, ruling out a Host/routing mismatch sending you to the wrong server block.

Resolution Checklist

Clear cookies for the affected site, then retry — this fixes the “Header Or Cookie Too Large” variant immediately.
If you control the server, raise large_client_header_buffers (nginx) or the equivalent header limit, and find what is inflating the headers.
Reproduce with a clean client (incognito, a fresh curl) to separate a client-side problem from a server-side one.
Inspect the exact request bytes for illegal characters, a wrong Content-Length, or bad framing — often introduced by a proxy in the path.
Confirm the Host header matches a configured virtual host and isn’t being rewritten upstream.
Re-run HTTP Check and confirm the response is no longer 400.

When to Escalate

Escalate to whoever runs the reverse proxy or CDN if the 400 originates at the edge and you can’t change the header limits.
If the malformed request comes from a third-party client or SDK you don’t control, take the captured request bytes to its maintainer.