Fixing Nginx 431: Request Header Fields Too Large (JWT & Large Cookies)

beginner Nginx2026-07-06| Nginx on Linux (Ubuntu, CentOS, Debian), Docker Nginx images, OpenResty

Error Message

431 Request Header Fields Too Large
#nginx#431#large-client-header-buffers#headers#jwt#cookie

TL;DR: The Quick Fix

When headers get too bulky for Nginx's default settings, it throws a 431 error. You can fix this by bumping up the header buffer size in your configuration. Open your Nginx config file (usually /etc/nginx/nginx.conf or a site-specific file in /etc/nginx/sites-available/) and add this directive to the http, server, or location block:

http {
    # Increase buffer size to 16k or 32k
    large_client_header_buffers 4 16k;
    
    # ... rest of your config
}

After saving your changes, verify the syntax and reload the service:

sudo nginx -t
sudo systemctl reload nginx

Why This Error Happens

The 431 Request Header Fields Too Large status means the HTTP headers sent by the client—like a browser or a mobile app—are too massive for the server to process. While the HTTP spec doesn't set a hard limit, Nginx uses small default buffers to protect your server from memory exhaustion attacks.

You will likely run into this issue when dealing with:

- **Bloated JWT Tokens:** Tokens containing many custom claims or large metadata objects.
- **Cookie Accumulation:** When your app and third-party tools (like Google Analytics or HubSpot) set dozens of cookies, the total `Cookie` header can easily exceed 8KB.
- **Enterprise Auth:** Complex authentication headers used in corporate SSO environments.

Nginx manages these limits through client_header_buffer_size (for the initial request line) and large_client_header_buffers. The second one is almost always the cause of 431 errors.

Detailed Fix Approaches

1. Global Configuration

Updating the global configuration is the fastest way to fix the issue across all your sites. This is standard practice for dedicated API gateways handling heavy authentication traffic.

# Edit the main config
sudo nano /etc/nginx/nginx.conf

Inside the http block, insert the directive:

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    # The '4' is the number of buffers; '16k' is the size of each
    large_client_header_buffers 4 16k;

    # ...
}

2. Targeted Server Block Fix

If only one specific application—such as a frontend using heavy Auth0 tokens—is triggering the error, apply the fix to that specific virtual host only.

server {
    listen 443 ssl;
    server_name api.example.com;

    # Apply only to this domain
    large_client_header_buffers 4 32k;

    location / {
        proxy_pass http://backend_upstream;
    }
}

3. Choosing the Right Buffer Size

Most Nginx builds default to 4 8k. This means Nginx allocates four 8KB buffers for headers. If a single header—like a JWT packed with user roles—hits 10KB, the request fails because it won't fit into an 8KB slot.

- **16k:** The sweet spot for most apps using large JWTs.
- **32k:** Use this if you have legacy systems or extremely heavy cookie data.
- **64k:** Only use this if absolutely necessary; it's rare to need more than 32KB.

How to Verify the Fix

Once you've reloaded Nginx, confirm the error is gone. You can use curl to simulate a massive header without touching your browser.

Run this command to send a simulated 10KB header to your server:

# Create a 10KB dummy header
LONG_HEADER=$(printf 'X-Custom-Header: %.0sA' {1..10000})
curl -I -H "$LONG_HEADER" http://localhost/

The Result: You should see an HTTP/1.1 200 OK or a redirect instead of the 431 error.

Security and Side Effects

Balancing Memory and Safety

Every buffer you allocate uses memory. While jumping from 8KB to 32KB won't hurt a server with 8GB of RAM, setting it to 1MB could be dangerous. An attacker could theoretically exhaust your memory by opening thousands of simultaneous connections with massive headers. Stick to the smallest size that solves your problem.

Browser Limits

Don't forget the browser. Chrome and Firefox have their own ceilings, often around 8KB to 16KB per single header. If Nginx is clear but users still see errors, it is time to move data out of cookies and into the request body (POST) or localStorage.

Upstream Load Balancers

If your app sits behind an AWS ALB or Cloudflare, ensure those services support your new header size. Cloudflare, for example, has a hard limit of 32KB for all headers combined. If you exceed that, Cloudflare will return its own error before the request even reaches Nginx.

Related Error Notes