431 Error Code | Headers Too Large Fix Steps

Guide / By

The 431 error code means the server refused your request because your HTTP request headers were too large.

A 431 can feel random. One tab loads fine, the next one fails. You refresh, you switch networks, you try again, and it still won’t budge. The pattern is easy to miss because the page that breaks is not always the page that caused it.

This error is about request headers, not the page content. Headers include cookies, authentication tokens, tracking data, and some proxy headers. When those headers grow past a server limit, the server stops the request before it reaches the page logic.

If you just want the fastest fix, start with clearing cookies for the site that fails. If you run the site, jump to the server and proxy section to raise limits safely and stop headers from ballooning again.

What The 431 Error Means In Plain Terms

Every time your browser asks for a page, it sends a small bundle of metadata along with the URL. That bundle is the header set. It can include your browser details, language, accepted file types, and a cookie string that can be longer than you’d guess.

The status code 431 is an HTTP response that signals “Request Header Fields Too Large.” In other words, the server saw your header block and decided it could not accept it. Some stacks use a strict size limit for each header line. Others enforce a cap on the total header bytes.

You might see the message as “431 Request Header Fields Too Large,” “Bad Request,” or a short error page from a proxy. The label changes with the server and the gateway, while the root issue stays the same.

If you want the formal definition, RFC 6585 documents status code 431 and the intent behind it, and MDN has a plain-language reference page that many developers use.

Where Those Oversized Headers Come From

Most 431 cases trace back to one of a few header sources. The tricky part is that they stack together. A cookie string grows, a token adds more bytes, and a proxy adds its own headers on top. Then one request crosses the line.

Cookies That Grow Without You Noticing

Cookies are the usual culprit. A site can set multiple cookies across subdomains, and browsers send the matching cookies back on each request. A single cookie can also get large if it stores bulky data or keeps app state in plain text.

Marketing tags can add long identifiers. A/B testing can add more. If a site keeps setting new cookies without expiring old ones, the cookie header can turn into a long, messy chain.

Auth Tokens And Single Sign-On Loops

Login systems often store a token in a cookie. When a token refresh fails, some systems keep adding new cookies or extra data on each redirect. That can create a loop where headers expand on every hop until the next request triggers a 431.

Reverse Proxies And Load Balancers Adding Headers

Gateways can add headers like forwarded IP chains, tracing IDs, and request IDs. That is normal. It becomes a problem when a chain grows, like a forwarded header that keeps appending values across multiple hops.

Too Many Custom Headers From Scripts Or Extensions

Browser extensions can inject headers for debugging, privacy tools, or corporate access control. Dev tools can also add headers during testing. If you see 431 only on one machine or one browser profile, add-ons are worth checking.

Common Source What Grows Who Can Fix It
Cookies Cookie header length User or site owner
Login tokens Session or auth cookies Site owner
Proxy chain Forwarded and tracing headers Site owner or host
Extensions Injected custom headers User

Fixing The 431 Error Code On Browsers And Devices

If you are a visitor trying to load a site, you can fix most 431 cases in minutes. Start small and move step by step. Each step trims header size or removes a header source.

  1. Clear Site Cookies — Remove cookies only for the site that fails, then reload the page in a new tab.
  2. Open A Private Window — Use an incognito or private session to test with a clean cookie jar.
  3. Disable Extensions — Turn off all add-ons, test again, then re-enable them one at a time.
  4. Try Another Browser Profile — A new profile starts with no stored cookies, no cached auth state, and default settings.
  5. Sign Out Everywhere — If you can reach an account page on a different device, sign out of active sessions, then try the broken page again.
  6. Flush DNS And Restart — Restarting won’t shrink headers, though it can clear odd proxy behavior on some networks.

If you are on a managed work device, a security tool might be adding headers. That can show up as a 431 on only certain networks or only certain sites. Testing on a phone hotspot can help separate local network gear from the browser itself.

When you see the error during login, focus on cookies and redirects. A repeated redirect can keep setting new cookies with each hop. Clearing site cookies usually stops the loop and gives you a clean start.

As a quick reality check, search the page source is not the move here. A 431 happens before the server sends the content. The fix is nearly always in the request path, not the response content.

When you want to mention the issue in a ticket or chat, use the exact label once so others can spot it quickly: 431 error code. Then add what you already tried and the browser you used.

Fixing The 431 Error Code On Servers, Proxies, And CDNs

If you own the site, a 431 can mean lost sign-ins, lost carts, and angry users. The goal is twofold: raise limits where it makes sense, and stop headers from growing out of control.

Start By Measuring Real Header Size

Before changing limits, capture a failing request. Tools like browser dev tools, cURL, and gateway logs can show the headers. Look for a cookie header that is hundreds or thousands of characters long. Look for forwarded chains that keep appending values.

  1. Reproduce With One URL — Use one page that fails reliably so you can compare before and after changes.
  2. Record The Request Headers — Save the request headers from the failing client, with sensitive values masked.
  3. Compare A Working Client — A clean browser session gives you a “small header” baseline.

Adjust Limits In The Layer That Rejects The Request

A common trap is changing the app server while the reverse proxy still blocks the request. Identify where the 431 comes from. The error page branding can hint at the layer, and response headers can also show it.

If you use Nginx, check header buffer and client header settings. If you use Apache, look at request header size directives. If you are behind a CDN or a managed load balancer, check their documented header limits and any configurable caps.

  1. Raise Proxy Header Buffers — Increase header buffer capacity in the edge proxy when the proxy emits the error.
  2. Raise App Server Limits — Increase max header size in the app server only after the proxy accepts the request.
  3. Limit Header Explosion — Cap forwarded chains and strip unused tracing headers at the edge when you can.

Fix Cookie Bloat At The Source

Raising limits can mask the symptom while the header keeps growing. Cleaning up cookies pays off fast. Store only what you truly need in cookies. Put large state server-side and keep the cookie as a short session pointer.

  1. Audit Cookie Count — List every cookie your site sets, where it is set, and why it exists.
  2. Reduce Cookie Size — Remove bulky payloads, shorten names, and drop values that can be recomputed.
  3. Expire Old Cookies — Retire legacy cookie names with a clear expiry strategy so old values stop riding along.
  4. Scope Cookies Tightly — Set Domain and Path so cookies only go where they are needed.

Watch out for cookie duplication across subdomains. If a cookie is set on a parent domain, it will be sent to every subdomain that matches. That can be fine for sign-in, while wasteful for static assets on a separate host.

Preventing Header Growth So This Doesn’t Return

Once the site loads again, it’s tempting to move on. Still, a 431 tends to come back when the root cause remains. Preventing it is mostly about discipline around headers and cookies.

Keep Cookies Lean And Purposeful

Cookies are not a storage box. Treat them like a short ID card. If you need a lot of state, store it server-side, then reference it with a small token.

  1. Store Sessions Server-Side — Keep the user state on the server and send a compact session ID cookie.
  2. Use Short Token Formats — Keep auth tokens compact and rotate them without stacking extra cookies.
  3. Retire Experiments Cleanly — Remove A/B test cookies after tests end, not months later.

Trim Headers Added By Gateways

Tracing and forwarding headers can grow when requests bounce between services. A clean gateway policy helps. Keep a single client IP header chain and drop duplicates. Standardize request IDs so you do not end up with several parallel tracing systems.

  1. Normalize Forwarded IP — Choose one forwarded header scheme and keep the chain from repeating itself.
  2. Drop Unused Debug Headers — Remove verbose debug headers from production traffic at the edge.
  3. Set Safe Caps — Put size caps in place for headers you control so they fail early in testing, not in user sessions.

Test With Real Browsers Over Time

Header bloat often appears after weeks of logins, sign-outs, and marketing tag changes. A clean staging test won’t always catch it. Add a test that simulates a returning user with a realistic cookie jar.

  1. Run Regression Requests — Keep a saved cookie jar in a test harness and run it on each release.
  2. Monitor Header Sizes — Log header byte counts at the edge so you can spot growth before it hits the limit.
  3. Alert On Spikes — Trigger alerts when cookie headers jump suddenly after a deploy or tag change.

When It Still Won’t Clear

If you cleared cookies and the error still shows up, the request may be failing in a layer you do not control, like a corporate proxy, a strict CDN setting, or a shared hosting gateway with tight limits. You can still narrow it down with a few clean tests.

  1. Test From Another Network — Try mobile data or a different Wi-Fi to rule out local gateway injection.
  2. Test A Clean Device — A phone with no extensions and a fresh browser install is a strong baseline.
  3. Capture Response Headers — Identify the server layer sending the error by checking headers like Server or Via.
  4. Reduce Redirect Loops — If sign-in redirects repeat, fix the loop first since each hop can add cookies.
  5. Contact Your Host — Ask where header limits are enforced and what the current caps are in the edge stack.

When you reach out for help, include the URL, the time it happened, your browser version, and whether it fails in a private window. That short set of details can save hours of back and forth.

One more practical tip: if only one page fails, check if that page hits a different subdomain or a different gateway. Mixed stacks are common, and one edge rule can be stricter than the rest.

Once you clear it, take a moment to prevent the same pattern. A 431 error code is a loud hint that headers are carrying more than they should. Keep them lean, and the error tends to stay gone.