If you’ve recently seen an error like:<pre><code class="language-plaintext">431 Request Header Fields Too Large 
Apache/2.4.52 (Ubuntu) Server</code></pre>Don’t worry — it’s a known issue, and here’s what it means (plus how to resolve it).<figure class="image"><img src="https://images.unsplash.com/photo-1576717585968-8ea8166b89b8?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHw1Mnx8Y29va2llfGVufDB8fHx8MTc0Nzc5MjQ5MXww&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@norevisions?utm_source=DNX&amp;utm_medium=referral">No Revisions</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure>⸻🧠 What is a 431 Error?This error occurs when your browser sends too much data in the request headers — usually due to large or excessive cookies stored for the site. Web servers like Apache and Nginx have limits on how much header data they can process. If those limits are exceeded, access is denied, and the 431 error is triggered.⸻🔍 What Caused It in My Case?In my case, the error was caused by a cookie named <code>acv</code>, which had grown to over 3.4KB in size. Combined with other tracking and consent cookies (from ad partners and CMPs), the total header size pushed Apache beyond its default threshold — leading to a sitewide access issue for users.Worse, once it happened, visitors had to manually clear cookies just to get back in.⸻🛠️ How I Fixed It (as a Site Owner)I implemented three changes:Increased the Apache header limits by adding this to the server config:<pre><code class="language-plaintext">LimitRequestFieldSize 16384
LimitRequestLine 8190</code></pre>Created a custom 431 error page (<code>/431.html</code>) that now explains the issue and offers:A “Clear Cookies” button to quickly resetA contact link to report issuesMonitored cookie size and behavior, especially from 3rd-party ad/CMP scripts, to catch anything unusually large or persistent.⸻👩‍💻 If You’re a Visitor and See This ErrorTry clearing cookies for the siteRefresh the pageOr use the contact form on the error page to get help⸻📌 Final NoteIf you run a site with ad tech integrations or a CMP, it’s a good idea to monitor cookie sizes and server limits. A single cookie update from a vendor can break access for users without warning.Adding a custom error page and a way for users to recover quickly goes a long way in preserving trust and usability.

A quick explanation of the “431 Request Header Fields Too Large” error, what causes it (often oversized cookies), how users can fix it by clearing site data, and what we’re doing to prevent it in the future. This guide is especially useful if you encountered the issue on SwimStandards or any site using modern ad consent scripts.

⚠️ “431 Request Header Fields Too Large” Error – What It Is and How to Fix It

Today I went down a rabbit hole chasing an error that only happened in one very specific setup:Desktop browsers → no issuesFirefox / Edge on mobile → no issuesChrome on mobile → constant 520 errors through CloudflareOn the surface, this looked random. Nginx logs weren’t showing the usual <code>request header too large</code> message, so it was easy to assume something else was broken (TLS key share, proxy headers, buffer settings, etc.). I tried changing proxy headers, adjusting Cloudflare rules, even toggling TLS quirks. Nothing fixed it.<figure class="image"><img src="https://images.unsplash.com/photo-1604307410297-081e0677d3fb?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxkZWJ1Z3xlbnwwfHx8fDE3NTU3MTQ3MzZ8MA&amp;ixlib=rb-4.1.0&amp;q=80&amp;w=1080"><figcaption>Photo by <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/@nublson?utm_source=DNX&amp;utm_medium=referral">Nubelson Fernandes</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>What Was Really Happening</h2>It turned out to be huge HTTP request headers.Chrome mobile sends very fat headers after login redirects — especially with cookies + <code>sec-ch-ua</code> client hints. This combination was blowing past nginx’s default request header size.Why didn’t nginx log it? Because:With HTTP/1.1, nginx can return a 431 Request Header Fields Too Large and log it.With HTTP/2 (used by Cloudflare → origin), nginx sometimes drops the connection during header frame parsing, before it can even send a 431 or log an error. From my perspective it just showed up as <code>"-" 000</code> in access.log and a Cloudflare 520.That’s why I never saw a “too large header” error line, and why disabling the Cloudflare proxy (H1 direct) seemed to magically “fix” things.<h2>The Fix</h2>I raised the nginx header size limits:<pre><code class="language-plaintext">client_header_buffer_size 64k;
large_client_header_buffers 16 64k;
http2_max_field_size 32k;
http2_max_header_size 128k;
</code></pre>Once I did that, Chrome mobile + Cloudflare stopped failing.<h2>Key Lessons</h2>Modern web headers are big. Between tracking cookies, Auth0 state, and Chrome’s UA-Hints, it’s normal for requests to carry 10KB+ of headers.HTTP/2 hides the evidence. Oversized headers don’t always produce friendly nginx log messages. You may just see 000 status in access.log + Cloudflare 520.Incognito can behave differently. With fewer cookies, headers shrink, which explains why Chrome incognito “worked fine.”Cloudflare proxy can amplify issues. Direct-to-origin H1 requests might succeed, but Cloudflare’s H2 pipeline forces stricter frame parsing.Default limits are too small. Both nginx and Apache ship with conservative header limits that don’t always match the reality of modern apps.<h2>Takeaway</h2>If you ever run into Cloudflare 520s that happen only on Chrome mobile (but not desktop or other browsers), check your header sizes first. It might just be a “too big to log” header issue.

Ran into a weird issue where only Chrome on mobile (not desktop, Firefox, or Edge) kept throwing Cloudflare 520 errors after login redirects, with nginx logs showing nothing helpful. The root cause turned out to be oversized request headers (cookies + Chrome UA-Hints) that blew past nginx’s default limits; under HTTP/2 these just closed the connection silently, showing up as 000 in access.log. Fix was simply raising nginx’s header buffer limits, which solved it immediately. Lesson: modern apps produce very large headers, and if you see random 520s on Chrome mobile, check header sizes before chasing TLS or proxy ghosts.

All Posts In Cookie