Why does 431 hit only some users and not others?

Because 431 is usually about accumulated cookies, and cookies are per-user. A visitor who has been on the site for months, or who has many analytics and marketing cookies set on the domain, sends a much larger Cookie header than a first-time visitor in a fresh browser. The request that trips the limit carries one specific user's oversized header — which is why clearing cookies for the site often fixes it instantly for that person while everyone else is unaffected.

Is 431 a client problem or a server problem?

Both, and that's why it's confusing. The client sent headers larger than the server chose to accept — but the server picked that limit. Neither side is strictly wrong. The durable fix is usually to shrink the headers (fewer or smaller cookies) rather than raise the limit, because a very large limit is itself a denial-of-service risk. RFC 6585 introduced 431 partly so servers had a correct code to return instead of silently dropping the connection.

My server returns 400, not 431, for big headers. Why?

431 was defined in RFC 6585 in 2012, and some servers predate it or never adopted it. nginx, for example, typically returns 400 Bad Request (or 414 for a long URI) when headers overflow its large_client_header_buffers, rather than the newer 431. The underlying cause and fix are the same; only the status code the server chose to emit differs.

Views: 101

431 Request Header Fields Too Large: Fix

431 Request Header Fields Too Large: your headers exceeded the server limit. Fix in 3 checks: cookies, big token, server limit. 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 server rejects the request with 431 Request Header Fields Too Large. The response often includes a short note about which header or the total header size that exceeded the limit.

Symptoms

The page returns 431 Request Header Fields Too Large (or 400 Bad Request on servers that predate the code).
It fails for some users but not others, or fails only after a user has been on the site a while.
Clearing cookies for the domain, or opening the site in a private window, makes it work again.
A specific request with a large Authorization, Cookie, or Referer header fails while others succeed.

What This Error Actually Means

431 was defined in RFC 6585 (2012), the same document that gave us 429 Too Many Requests. It means exactly what it says: the request’s header section was too large for the server to process. The spec allows two flavors — the total size of all header fields exceeded the limit, or a single field was too large — and the server may indicate which in the response body.

The key insight is where that size comes from. Header bloat is almost always the Cookie header. A browser concatenates every cookie set for the domain into one header and sends it on every request. Each analytics script, A/B testing tool, chat widget, and marketing pixel that drops a cookie adds to it. Over months, a single domain can accumulate kilobytes of cookies, and one day a request crosses the server’s threshold. The other usual suspect is a large Authorization header — a fat JWT with lots of claims, or a token that grew as scopes were added.

Server limits are lower than people expect. Node.js caps total header size at 16 KB by default — and between versions 11.6.0 and 13.13.0 it was 8 KB, tightened in response to CVE-2018-12121, a header-based denial-of-service. nginx defaults to four 8 KB buffers via large_client_header_buffers. These limits exist on purpose: unbounded headers are a memory-exhaustion attack, which is exactly why “just raise the limit sky-high” is the wrong first move.

Top 3 Causes

Accumulated cookies - The Cookie header grew past the limit from months of analytics, marketing, and third-party cookies on the domain. This is the top cause and it explains the per-user, “clearing cookies fixes it” pattern.
One oversized single header - A large JWT in Authorization, a very long Referer, or a custom header carrying encoded state. Here the total might be fine but one field alone exceeds the per-field limit.
A server limit set too low for the app - The application legitimately needs larger headers (SSO with big SAML/JWT tokens is common), but the web server or runtime default is smaller than the app requires.

Diagnose with DechoNet

HTTP Check to see the exact status the server returns and the response headers, confirming it’s a 431 (or a 400 standing in for one) and not a different failure upstream.
DNS Lookup to confirm you’re hitting the intended host and not a stale endpoint or wrong environment when the failure is inconsistent across users.

Resolution Checklist

Reproduce in a private/incognito window. If it works there, the cause is client-side header bloat — almost certainly cookies.
Inspect the failing request’s headers in browser DevTools (Network tab). Find the largest one — usually Cookie, sometimes Authorization.
If cookies are the cause, prune them: remove stale or third-party cookies, scope cookies to paths that need them, and audit which scripts set cookies on the domain.
If one header is the cause (large token), shorten it — trim JWT claims, or move bulky state out of the header and into a server-side session reference.
Only if headers are legitimately large by design, raise the server limit deliberately: Node --max-http-header-size, nginx large_client_header_buffers, Apache LimitRequestFieldSize / LimitRequestFields. Set it to what the app needs, not to infinity.
Re-run HTTP Check to confirm the request now succeeds.

When to Escalate

Escalate to your identity/SSO team if the oversized header is a SAML or JWT token you don’t control — the fix may be reducing claims at the identity provider rather than in your app.
If a CDN or reverse proxy sits in front and enforces its own (lower) header limit, the 431 can come from the edge even when your origin would have accepted the request. Check the edge’s header-size settings, not just the origin’s.