New visitors can open the site, but returning users receive 431 or 400. A private window works, then the problem reappears after a period of signed-in use. That pattern makes request headers—especially automatically attached cookies—a useful place to start. Adding a CDN introduces another request-processing boundary, where a request that previously passed may now be rejected.
HTTP 431 means the server is unwilling to process oversized request headers. Either one field or the combined set can be responsible. Products do not necessarily return the same status: Nginx documents 400 for an individual header field that exceeds its configured buffer and 414 for an oversized request line.[1][2] A status code alone does not identify the rejecting layer.
This guide covers websites and APIs. Its commands are diagnostic examples, not tests performed against your production environment. Oversized uploads, long URLs, and large request headers are separate problems with potentially different limits.
Identify the first layer that refuses the request
Record the failure time, hostname, path, status, and available request ID. Correlate CDN, load balancer, reverse proxy, and application logs. Error-page styling and response headers offer clues, but intermediaries can rewrite them.
If the CDN records the request but the origin access log has no matching entry, check edge rejection reasons, WAF events, and any load balancer in front of the origin. A missing origin access-log entry is not conclusive: a parser may reject malformed or oversized input before the normal access log is written. Inspect error logs too.
Compare controlled cases: a normal window versus a private window with the same account; the same path before and after login; and a request with essential authentication only versus the full cookie set. Private browsing working is a clue, not proof. Extensions, proxies, and account state may also differ.
Do not ask users to post complete HAR files or unredacted “Copy as curl” output in public tickets. These can expose cookies, Authorization values, personal data, and signed URLs. Prefer header names, lengths, and redacted structure in diagnostic records.
Separate individual-field limits from total request size
Check the current documentation for every hop: aggregate header size, individual-field size, field count, URL or request-line length, and whether each limit is adjustable. HTTP/2 and HTTP/3 header compression is not a way around these restrictions. Services may count decoded fields or apply their own request-size definitions.
CloudFront lists request-size and URL-length quotas separately, for example. An Nginx buffer setting does not change an edge-service quota.[3] The request must pass every boundary; increasing origin capacity cannot repair a request already rejected by the CDN.
Inspect cookies, bearer tokens, tracing metadata, and forwarding chains. Applications that serialize large user profiles into cookies, or growing permission lists into JWTs, add that overhead to repeated requests. If one field is oversized, increasing the number of buffers may not help.
Find out why the cookie set keeps growing
Check whether a broad cookie Domain causes several subdomain applications to send their cookies together. Review Path scope as well: static resources may be receiving session data they do not need. Cookies with the same name but different Domain or Path scopes can coexist and be sent in the same request.
Browsers attach applicable cookies automatically. Omitting an explicit Cookie field from JavaScript does not mean the browser will omit cookies. Changing cross-origin credential settings can break login flows and is not a general-purpose fix.
Long-term changes may include storing session state on the server and keeping only a necessary identifier in the browser, reducing token claims, removing redundant experiment or tracking state, and choosing appropriate cookie scopes and resource hostnames.
To remove an old cookie, its name, Domain, and Path must match the original scope. Otherwise an obsolete copy may remain. Inventory existing scopes before changing them, and assess sign-outs, cross-subdomain single sign-on, staged rollout, and rollback behavior. Do not remove HttpOnly, Secure, or SameSite protections just to save bytes.
Establish a baseline without credentials
In an authorized environment, send a GET to a small, read-only test resource. This Bash example does not attach browser cookies and does not automatically follow redirects:
curl -sS --max-time 20 \ -D response-headers.txt \ -o response-body.bin \ 'https://example.com/health-check'
Replace the address with one you are authorized to test. Verify that the response comes from the intended service rather than a login redirect, WAF page, or application-generated error. GET avoids assuming that HEAD follows identical routing. Do not repeatedly replay requests against production write endpoints.
Next, compare successful and failing requests in browser developer tools. If authentication is necessary, use a dedicated test account and short-lived credentials handled through controlled tooling. Keep real tokens out of command history, repositories, and shared logs. Diagnostic response files can also contain sensitive information; restrict access and remove them when no longer needed.
Do not repeatedly inflate production request headers to discover the exact boundary. If boundary testing is required, use a staging environment, small increments, and limited concurrency. Record both individual-field lengths and aggregate size. Invalid requests can consume resources before authentication occurs.
Adjust Nginx request-header buffers only when justified
Nginx uses client_header_buffer_size and large_client_header_buffers when reading client request headers. client_max_body_size limits the request body and generally will not fix a large Cookie field. proxy_buffer_size concerns reading the upstream response; it is not the browser request-header limit.[2]
If the application genuinely requires larger headers, evaluate a configuration such as this in staging:
# Illustrative values, not a recommendation for every site. # Use the relevant http or server configuration context. client_header_buffer_size 2k; large_client_header_buffers 4 16k;
The Nginx documentation states that a request line must fit within one large buffer, and a single header field must also fit within one large buffer. 4 16k does not mean one field can occupy the combined capacity of four buffers.[2] Nor does this example guarantee identical behavior across protocols, versions, and services placed in front of Nginx.
Back up the configuration before editing. Confirm the effective virtual host, Nginx version, and upstream infrastructure. Check configuration syntax, then reload through your deployment's controlled procedure. Containers, managed platforms, and system services use different operational commands; do not copy a restart command without checking the environment.
If the CDN limit cannot be changed, reduce the browser request rather than repeatedly expanding origin buffers. Larger limits can increase the resource cost of abnormal requests, so assess concurrency, connection controls, and monitoring alongside the change.
Check forwarding chains when cookies look normal
Inspect X-Forwarded-For, Forwarded, tracing fields, and custom debugging headers. Proxy loops or repeated appending can make them grow. Clearing forwarding fields indiscriminately may break client-IP attribution, audit trails, or access control.
Define behavior at trusted proxy boundaries. Never unconditionally trust a public client's version of a forwarding header, and ensure each hop follows the agreed handling rules. If routing loops are responsible, fix the routing instead of concealing the problem with a higher size limit.
Validate with returning users, not just clean sessions
Test existing cookie sets, new sessions, cross-subdomain login, larger but legitimate tokens, and intentionally oversized requests in a controlled environment. Legitimate requests should recover while abnormal requests remain safely rejected. Confirm that sessions are not mixed between users and that static resources no longer carry unnecessary cookies.
Clearing cookies can restore access for affected users, but it does not fix recurring writes that recreate the problem. During rollout, monitor 400, 431, and 414 responses, the rejecting layer, session failure rates, and ingress resource use. Do not collect raw credentials in monitoring.
If compatibility problems appear, restore the backed-up proxy configuration and cookie policy. Deleting a client's cookies is not automatically reversible by rolling back server configuration; users may need to sign in again. Include that consequence in the change plan before clearing cookies.
The investigation should establish which hop rejects the request, whether one field or the total size is excessive, and which data should not be sent at all. Those answers determine whether larger buffers are actually necessary.
References
Source review date: November 2, 2026. Verify product limits and behavior against the deployed version and current documentation.
