431 - Request Header Fields Too Large
HTTP 431 Request Header Fields Too Large means one header field or the overall header section is larger than a server or intermediary is willing to process.
Last reviewed: April 18, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Request Header Fields Too Large Mean?
The request never reaches normal application handling because the metadata around it is too large. The failure can come from one field, such as Cookie or Authorization, or from the aggregate header set after proxies add forwarding and tracing data.
Common Causes
- -Cookie accumulation from analytics, feature flags, and session state pushes the Cookie header beyond gateway or origin limits.
- -JWTs, debug blobs, or custom metadata headers exceed per-field size limits on one proxy hop.
- -Proxy chains duplicate
X-Forwarded-*, tracing, or identity headers on every hop and exhaust the total header budget. - -One environment has lower header limits than another, so only a specific CDN, ingress, or origin path returns 431.
- -SSO or identity systems attach large group or claim payloads that overflow request header capacity.
How to Fix Request Header Fields Too Large
- 1Capture the full header set and identify whether one field or total header size is triggering the rejection.
- 2Trim oversized cookies, auth headers, or optional client metadata immediately.
- 3Remove duplicated forwarding or tracing headers in the proxy chain before increasing any buffer limits.
- 4Align header-size limits across CDN, proxy, gateway, and origin so behavior is consistent end to end.
Step-by-Step Diagnosis for Request Header Fields Too Large
- 1Capture the raw request headers at the rejecting hop and compute both aggregate bytes and top individual offenders.
- 2Differentiate single-field overflow from total-header overflow using server and proxy logs.
- 3Compare header-size limits across browser/client, CDN, ingress proxy, application proxy, and origin server.
- 4Check whether cookies or auth claims have grown over time rather than changed suddenly in one deploy.
- 5Retest with minimized headers, then add optional headers back incrementally until the real threshold is clear.
Seen in Production
- -A SPA accumulates feature-flag and analytics cookies over months until the Cookie header alone exceeds ingress limits.
- -An identity provider adds large group claims to a token, and the Authorization header starts failing only on one stricter proxy tier.
- -A service mesh duplicates forwarding headers across each hop, so aggregate header bytes grow even though the client request looked normal.
- -A debug or correlation header meant for staging leaks into production clients and silently consumes most of the header budget.
Header Budget Attribution
- -Identify top contributors to header size (example: cookie blob grows past 12 KB due to accumulated feature flags).
- -Distinguish single-field overflow vs total-header overflow (example: one JWT header is too large even when the aggregate is otherwise acceptable).
Limit Alignment and Hop Ownership
- -Audit limit mismatches across hops (example: CDN accepts 16 KB headers while origin proxy enforces 8 KB).
- -Assign ownership of forwarding and tracing headers so only one layer appends each field (example: repeated
X-Forwarded-Forinflation across mesh hops).
Decision Shortcut: Cookie Bloat vs Auth/Header Inflation
- -If browser-only requests fail while server-side calls succeed, inspect Cookie growth before changing infrastructure buffers.
- -If only authenticated calls fail, inspect token size, claim growth, and identity headers before touching general proxy limits.
- -If only one path or environment fails, compare hop-specific limits before redesigning every client.
Wrong Fix to Avoid
- -Do not raise one proxy buffer in isolation if another hop still enforces a smaller header budget.
- -Do not keep large user-state blobs in cookies just because the browser sends them automatically.
- -Do not debug 431 like a backend latency problem; the request is being rejected before application code runs.
Implementation Examples
2026-04-21T11:14:52Z ingress=request-gateway requestId=req_4f29a8
cookieBytes=14312 totalHeaderBytes=16780 limitBytes=8192 status=431
message="request header too large before upstream routing"curl -sv https://api.example.com/profile \
-H "Cookie: session=$(python3 - <<'PY'
print('a'*12000)
PY
)" 2>&1 | rg '< HTTP/|> Cookie:|431'large_client_header_buffers 4 8k;Incident Timeline
11:12 UTC
Header growth crosses a hidden budget
Signal: Cookies, auth claims, or forwarding metadata grow gradually until one hop can no longer accept the request.
Why it matters: The first useful question is which header budget was crossed, not whether the backend route is healthy.
11:14 UTC
One hop begins returning 431
Signal: CDN, ingress, or origin rejects the header section before the app can inspect the request.
Why it matters: This is a request-framing problem at the edge or transport layer, not an application validation error.
11:16 UTC
Retries reproduce the same oversized metadata
Signal: Clients replay identical cookies or auth headers and every retry fails at the same hop.
Why it matters: Retrying does not help until the header set is smaller or the real enforcing limit is changed deliberately.
11:24 UTC
Header budget is reduced or aligned and requests recover
Signal: Cookies are pruned, duplicated headers are removed, or limits are aligned across hops so the request passes normally again.
Why it matters: That confirms the root cause was metadata bloat or path-specific header-limit mismatch.
Seen in Production
Cookie bloat from repeated feature flags and tracking state
Frequency: common
Example: Browser sends oversized Cookie header after several releases, and API gateway starts returning 431.
Fix: Prune cookie payload, move large state server-side, and cap cookie count/size in frontend standards.
Security middleware duplicates forwarding headers
Frequency: common
Example: Proxy chain appends repeated X-Forwarded-* values, pushing aggregate header size beyond origin limit.
Fix: Normalize forwarding headers at edge and enforce single-source header ownership rules.
Identity token or group claims inflate auth headers
Frequency: medium
Example: SSO integration adds large claim sets and only authenticated requests begin failing with 431 on one stricter proxy hop.
Fix: Trim claim payloads, move bulky identity context out of headers, and align auth header budgets across the path.
Wrong Fix vs Better Fix
Raise one limit vs identify the real offender
Wrong fix: Increase one server buffer and assume the problem is solved.
Better fix: Find the largest header or aggregate overrun first, then either shrink it or align limits across every hop.
Why this is better: A single larger buffer does not help if another intermediary still rejects the same header set earlier.
Keep state in cookies vs move state elsewhere
Wrong fix: Keep adding feature flags, user state, or debug data into cookies because the browser will carry them automatically.
Better fix: Move bulky state server-side or into compact identifiers and keep cookies deliberately small.
Why this is better: Cookie bloat is one of the fastest ways to create persistent 431 incidents across browsers and gateways.
Assume auth is broken vs inspect auth header size
Wrong fix: Treat failures as generic authentication issues without checking token or claim size.
Better fix: Measure the Authorization header and identity-related fields before changing auth logic.
Why this is better: Large tokens and duplicated identity headers often trigger 431 even when auth semantics are otherwise correct.
Debugging Tools
- -curl --trace-ascii for raw header capture
- -Ingress proxy limit logs
- -Browser devtools request headers view
- -Gateway or CDN header-size diagnostics
- -Cookie and auth-token size telemetry
How to Verify the Fix
- -Resubmit requests with the corrected header set and confirm 431 is cleared on every environment path.
- -Run boundary tests at documented per-field and aggregate header limits.
- -Validate browser, mobile, and server-side clients remain within the intended header budget.
- -Confirm one hop no longer accepts headers that a later hop rejects with a smaller hidden limit.
How to Prevent Recurrence
- -Set explicit header budgets per client, route, and proxy tier.
- -Enforce cookie hygiene standards with count and byte-size caps in frontend code reviews.
- -Add automated tests for per-header and aggregate header-size thresholds.
- -Monitor header-size percentiles and top offending fields by route and client type.
Pro Tip
- -treat total cookie size as a tracked performance and reliability budget so header bloat is visible before it becomes a 431 incident.
Official References
Provider Context
This guidance is specific to HTTP services. Always validate implementation details against official provider documentation before deploying to production.