431 Request Header Fields Too Large — HTTP Status Code

What 431 means

431 Request Header Fields Too Large means "your headers are too big for me to process." It is defined in RFC 6585, Section 5. The server may use it when the request headers are too large in total, or when a single header field is too long; in the second case the response should say which header was at fault. The client may try again after making the headers smaller.

Like the other RFC 6585 codes, a 431 response must not be cached.

When you see it

431 shows up when a browser, script or proxy sends a request whose headers exceed a limit set by the server. Which software sends it varies:

• Node.js HTTP servers return 431 when headers exceed the built-in maximum header size (16 KB by default in current versions, adjustable with --max-http-header-size).
• nginx rejects oversized headers with 400 and the message "Request Header Or Cookie Too Large", controlled by large_client_header_buffers (default 4 8k).
• Apache also uses 400 by default, governed by LimitRequestFieldSize.
• CDNs and load balancers have their own header limits and may reject a request before your server sees it.

Because the limit is checked on whatever the client sends, the error is often specific to one browser profile on one machine.

Common causes

• Cookie buildup. Many cookies scoped to the parent domain (.example.com) are sent to every subdomain. Marketing tags, consent tools and session data add up.
• Large single cookies, such as a session framework storing serialized state in a cookie instead of on the server.
• Big authentication tokens. JWTs with many claims or group memberships, sent in an Authorization header, can exceed limits on their own.
• Proxy chains adding headers. Each hop may append to X-Forwarded-For, tracing headers or similar, growing the request on the way in.
• A redirect loop that sets a cookie on each hop, making the cookie header grow until requests fail.

How to fix it

For a single user: clear cookies and site data for the domain, or test in a private window to confirm cookies are the cause.

For the site:

1. Audit cookies. In browser developer tools, list cookies for your domain and their sizes. Remove what you no longer use and scope cookies to the subdomain that needs them instead of the whole domain.
2. Move state server-side. Store sessions on the server and keep only an ID in the cookie.
3. Trim tokens. Keep JWT claims minimal, or exchange a large token for a short reference.
4. Raise limits carefully, only after you understand what is growing. In nginx:

http {
    large_client_header_buffers 4 16k;
}

Every proxy in the chain needs a matching limit, or the smallest one still wins. For Node.js, start the process with node --max-http-header-size=32768 server.js.

How to check it

Reproduce the error by sending a deliberately large cookie:

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Cookie: test=$(head -c 20000 /dev/zero | tr '\0' 'a')" \
  https://www.example.com/

Lower the size until the response changes from 431 (or 400) to 200 to find the effective limit. Compare with the size of the Cookie header a real affected browser sends, visible in the network panel of developer tools.

What it means for uptime monitoring

PingRobot's checker sends a GET with the user agent PingRobot/1.0 (+https://pingrobot.io/bot), sends no cookies, and follows redirects. The final response counts as up only if its status is 200–399, and a failure is re-checked from a second region before alerting.

A monitor will therefore rarely trigger 431 itself. If it does, look at what sits in front of your site: a proxy, load balancer or edge rule that adds large headers on the way in, or a header limit that has been set unusually low. The more common situation is the opposite: the monitor stays green while real users with heavy cookies get errors. That is a reminder that a passing uptime check proves the server can answer a clean request, not that every visitor's browser can. If customers report the problem, ask for the exact error page and check cookie sizes.

Related codes

• 400 Bad Request – what nginx and Apache send for the same problem.
• 414 URI Too Long – the URL, rather than the headers, is too long.
• 413 Content Too Large – the request body is too big.
• 429 Too Many Requests – another RFC 6585 code.
• 421 Misdirected Request – a different header-related rejection, about the Host.

Start monitoring free — 10 monitors, no credit card.