400 Bad Request: Request Header or Cookie Too Large (and HTTP 431)

02Default header and cookie limits by server and CDN

Limits differ by a factor of more than a hundred between products, which is why a request can pass the CDN and fail at the origin, or pass nginx and fail at the Node.js application behind it.

03How cookies add up: a worked example

Consider a site that stores a single sign-on session as two cookies of 3,900 bytes each, while analytics and A/B testing tools add twelve cookies of about 150 bytes. Over HTTP/1.1 all of them travel in one Cookie header line: 2 × 3,900 + 12 × 150 = 9,600 bytes, before separators. That is more than the 8,192 bytes of one nginx buffer, so nginx rejects every request, even though each cookie is below the 4,096 bytes per cookie that RFC 6265 asks browsers to support.

The browser is not at fault: RFC 6265 asks it to store at least 50 cookies of 4,096 bytes for one domain, about 200 KB, far more than any server default accepts. The same RFC says servers should use as few and as small cookies as possible, which puts the fix on the site's side.

04How to fix it as a visitor

Delete the cookies for the affected site only, then reload. You will be signed out of that site, and nothing else changes.

• Chrome: click View site information to the left of the address, then Cookies and site data, then Manage on-device site data, and delete the site's entries; or go to Settings, Privacy and security, Third-party cookies, See all site data and permissions, search for the site and choose Delete
• Other browsers have the same per-site option in their privacy settings or in the panel behind the icon next to the address
• Open a private window to confirm the diagnosis: if the site loads there, cookies were the cause
• If the error returns within days, the site keeps adding cookies; tell its operator, because only they can fix it

05How to find the cookie that is too big

In Chrome, open developer tools, go to Application, then Storage, then Cookies, and select the site. The Size column shows each cookie in bytes, and sorting by it puts the culprit at the top. Check the Domain column as well: a cookie set for .example.com is sent to every subdomain, so a tool on the blog can break the shop or the API. The console's document.cookie misses HttpOnly cookies, which are often the large session ones, so use the Cookies panel or the Request Headers section in the Network panel instead.

To learn the limit of your own site, send cookies of growing size and watch for the first failure. Run it only against servers you operate.

for kb in 4 8 12 16 24 32; do
  printf '%3s KB: ' "$kb"
  curl -s -o /dev/null -w '%{http_code} (request %{size_request} bytes)\n' \
    -H "Cookie: test=$(head -c $((kb * 1024)) /dev/zero | tr '\0' a)" https://example.com/
done

06How to raise the limit in nginx, and where to put it

Raise the buffer size only once you know which header grew and that it is legitimate. Buffers are allocated on demand and released when the connection goes idle, so 16 KB costs nothing for ordinary requests, but every extra kilobyte is memory that a slow-header attack such as Slowloris can make each connection hold. The nginx DDoS hardening guide pairs these buffers with short header timeouts.

Placement matters. nginx documents that a value set in a server block may be overridden by the default server's value, and a test on nginx 1.22.1 showed what that means: a larger buffer in a name-based server worked when the Host header came before the Cookie header and failed when the Cookie came first, because nginx had not yet chosen the server. Set it in the http block, or in the default server of that address and port.

Optionally, replace the bare error page with one that tells visitors what to do. Mapping nginx's internal code 494 to 431 also gives monitoring the standard status. In the test, nginx 1.22.1 sent this 431 with an empty reason phrase, which HTTP permits.

Check every hop. If nginx forwards to a Node.js application, Node's 16 KB limit still applies, and the visitor gets a 431 from the upstream instead. Oversized response headers are a separate limit, proxy_buffer_size, which produces a 502 Bad Gateway instead.

# in the http block, or in the default_server for this address and port
large_client_header_buffers 4 16k;

server {
    listen 80 default_server;
    server_name _;

    # 494 is nginx's internal code for "Request Header Or Cookie Too Large"
    error_page 494 =431 @header_too_large;

    location @header_too_large {
        default_type text/html;
        return 431 "<h1>Your browser sent too many or too large cookies</h1><p>Delete the cookies for this site and reload the page.</p>\n";
    }
}

07Apache, Node.js and IIS: where the limits live

• Apache httpd: LimitRequestFieldSize sets the bytes allowed per header (default 8,190) and LimitRequestFields the number of headers (default 100). With name-based virtual hosts the value is taken from the first virtual host for that address and port, and the log line AH00561 Request header exceeds LimitRequestFieldSize appears only at LogLevel info. Example, illustrative and not run here: LimitRequestFieldSize 16380
• Node.js: start the process with node --max-http-header-size=32768 server.js, or pass maxHeaderSize: 32768 to http.createServer; both raised the limit in a test on Node.js 22
• IIS: MaxFieldLength and MaxRequestBytes live under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters and take effect after the HTTP service restarts. Kerberos tokens grow with the number of Active Directory groups a user belongs to, and Microsoft suggests 4/3 of the token size plus 200 bytes for both values
• Behind a CDN, the edge limit must be at least as large as the origin's, or the edge rejects requests that the origin would accept

08How to stop cookies from growing back

• Scope cookies to the host that needs them: omit the Domain attribute instead of setting the parent domain, so they are not sent to every subdomain
• Keep session state on the server and send only an identifier, rather than a large signed token with many claims
• Give analytics and experiment cookies an expiry, and remove tags that nobody reads
• Watch for chunked authentication cookies, numbered parts of one large session, that multiply after each sign-in
• Large Negotiate (Kerberos) tokens in the Authorization header cause the same error on intranet sites; see 401 and authentication schemes