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.

Debugging a Chrome Mobile + Cloudflare 520 Mystery

When you start adding SSO providers, JWTs, or large cookies to your web stack, you’ll eventually hit a frustrating error:<pre><code class="language-plaintext">400 Bad Request – Request Header Or Cookie Too Large
431 Request Header Fields Too Large
502 Bad Gateway – upstream sent too big header</code></pre>These errors are not random—they happen because web servers like Apache and Nginx enforce limits on HTTP header size. Let’s break down the defaults, how to tune them, and why you should resist the temptation to set them “infinitely large.”<figure class="image"><img src="https://images.unsplash.com/photo-1472289065668-ce650ac443d2?crop=entropy&amp;cs=tinysrgb&amp;fit=max&amp;fm=jpg&amp;ixid=M3wxNTQwMTB8MHwxfHNlYXJjaHwxfHxoZWFkZXJ8ZW58MHx8fHwxNzU3NzczODc5fDA&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/@joannakosinska?utm_source=DNX&amp;utm_medium=referral">Joanna Kosinska</a> on <a target="_blank" rel="noopener noreferrer" href="https://unsplash.com/?utm_source=DNX&amp;utm_medium=referral">Unsplash</a></figcaption></figure><h2>Why header size matters</h2>Cookies: Each cookie can be up to ~4 KB. Multiply that by multiple cookies and you can easily exceed 8 KB.JWTs / OAuth tokens: A single token can be &gt;10 KB.Reverse proxies: You not only care about incoming request headers (from browsers) but also response headers (from your app), especially if your app sets big <code>Set-Cookie</code> values.If the server’s buffer is too small, it rejects the request/response with 400/431/502 errors.<h2>Nginx defaults vs tuning</h2>Defaults (64-bit builds):<pre><code class="language-plaintext">client_header_buffer_size 1k;
large_client_header_buffers 4 16k;
proxy_buffer_size 8k;
proxy_buffers 8 8k;
proxy_busy_buffers_size 16k;
http2_max_field_size 16k;
http2_max_header_size 64k;</code></pre>Request side: A single header line can only be 1k, and the total request headers 64 KB.Response side: A single upstream response header can’t exceed 8 KB.Common tuning (for Auth0, SSO, large cookies):<pre><code class="language-plaintext"># Requests (client → Nginx)
client_header_buffer_size 64k;
large_client_header_buffers 16 64k;

# Responses (upstream → Nginx)
proxy_buffer_size 16k;
proxy_buffers 8 16k;
proxy_busy_buffers_size 32k;

# HTTP/2 (mod_http2 in Nginx)
http2_max_field_size 32k;
http2_max_header_size 128k;
</code></pre>This raises both sides to handle bigger cookies and longer auth headers.<h2>Apache 2.4 defaults vs tuning</h2>HTTP/1.x defaults:<pre><code class="language-plaintext">LimitRequestFieldSize 8190 # ≈ 8 KB per header
LimitRequestLine 8190 # ≈ 8 KB for entire request line
LimitRequestFields 100 # max number of headers
</code></pre>HTTP/2 defaults (mod_http2):<pre><code class="language-plaintext">H2MaxHeaderListSize 65536 # 64 KB total headers</code></pre>Safe tuning for larger headers:<pre><code class="language-plaintext"># HTTP/1.x
LimitRequestFieldSize 16384
LimitRequestLine 16384

# HTTP/2
H2MaxHeaderListSize 131072 # 128 KB
</code></pre><h2>Why not set these “too large”?</h2>It might be tempting to set everything to 512 KB or 1 MB “just in case.” But that creates problems:Memory pressure: Apache and Nginx allocate buffers per connection. Large settings × many concurrent connections = wasted RAM.DoS surface: Attackers can exploit large headers to tie up server resources.Real-world limits: Browsers themselves rarely send &gt;16 KB per cookie header. Most apps don’t need more than ~128 KB total.The sweet spot is 16 KB per header and 128 KB total for HTTP/2—large enough for SSO tokens, but not so large that you waste memory.<h2>Troubleshooting checklist</h2>Seeing 400 Bad Request? → Raise <code>client_header_buffer_size</code> / <code>large_client_header_buffers</code> (Nginx) or <code>LimitRequestFieldSize</code> (Apache).Seeing 431 Request Header Fields Too Large (HTTP/2)? → Raise <code>http2_max_header_size</code> (Nginx) or <code>H2MaxHeaderListSize</code> (Apache).Seeing 502 upstream sent too big header? → Raise <code>proxy_buffer_size</code> (Nginx). Apache rarely needs this because it streams headers.<h2>TL;DR</h2>Nginx defaults are strict (1k per header line, 8k per response header). Tune both request and proxy buffers.Apache defaults are looser for HTTP/2 (64 KB), but still only 8 KB per header for HTTP/1.Don’t overshoot—large buffers eat memory and open DoS risks.Recommended safe values:16 KB per header128 KB total for HTTP/2That’s enough for real-world cookies, JWTs, and SSO without bloating your servers.

Both Apache and Nginx enforce limits on HTTP header sizes to prevent abuse, which can trigger confusing 400/431/502 errors when apps use large cookies or JWTs; by default, Apache allows ~8 KB per header in HTTP/1.x and 64 KB total in HTTP/2, while Nginx defaults are even tighter (1 KB per header line, 8 KB response headers), so tuning directives like LimitRequestFieldSize, H2MaxHeaderListSize, client_header_buffer_size, and proxy_buffer_size is often necessary—but keep values reasonable (≈16 KB per header, 128 KB total) to balance real-world needs with memory efficiency and DoS protection.

All Posts In Header