SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
HTTP New Added 28 August 2026

431 Request Header Fields Too Large

The combined size of the request headers exceeded the server's limit. In practice this is nearly always cookies: an accumulation of analytics, session and feature-flag cookies on one domain.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# See how big the headers actually are
curl -sv https://example.com 2>&1 | awk '/^> /{n+=length($0)} END{print n" bytes"}'

# Server limits
# nginx:  large_client_header_buffers 4 16k;
# Node:   node --max-http-header-size=32768
# Apache: LimitRequestFieldSize 16384

# Real fix: stop storing state in cookies. Keep a session id and
# move the payload server-side.

How to diagnose HTTP errors

HTTP status codes are a first classification, not a diagnosis. The essential split: 4xx means the request was wrong (fix the client), 5xx means the server failed to fulfil a valid request (fix the server). The subtlety is that reverse proxies and CDNs generate their own 5xx responses. A 502 or 504 from nginx tells you about nginx's relationship with the upstream, not about your application code.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Capture the full exchange with curl -v or curl -sD - -o /dev/null. Response headers frequently name the component that generated the error (Server:, Via:, X-Cache:).
  2. Determine whether the response came from your application or from something in front of it. Add a unique header in your app and check whether it survives; if it is missing, a proxy answered.
  3. For 502/504, check the upstream directly, bypassing the proxy. If the upstream is healthy, the problem is proxy timeouts, buffer sizes, or DNS re-resolution.
  4. Follow redirects explicitly with curl -IL to catch loops. A redirect loop is usually an HTTPS-terminating proxy that does not forward X-Forwarded-Proto.
  5. Correlate the request with server logs using a request ID. Guessing from the status code alone is the slowest way to debug HTTP.

Tools worth reaching for

  • curl -v / -IL
  • browser devtools Network tab
  • access logs
  • tcpdump / Wireshark
  • httpstat

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

developer.mozilla.org

Related HTTP errors

See all 49 HTTP errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.