Fix Nginx "Request Header or Cookie Too Large" Error

You open a website and get 400 Bad Request with the message Request Header Or Cookie Too Large. The same page may work in a private window because that session does not send the cookies stored in your normal browser session. Nginx rejects the oversized request headers before the application can process them.

This guide explains how to recover by clearing site cookies and how to adjust Nginx when your application needs to accept larger headers.

What Causes the Error #

Nginx starts reading request headers with client_header_buffer_size, which defaults to 1k. If that buffer is too small, it allocates larger buffers as needed, controlled by large_client_header_buffers . The default is 4 8k.

Each header field must fit in a single large buffer. Four 8 KiB buffers do not allow one 32 KiB Cookie or Authorization field. Increasing the number of buffers alone will not fix an oversized field.

Common triggers include a large authentication token, an application storing too much session data in cookies, or several cookies sent together in the Cookie header. The total request headers can also exhaust the available buffers even when individual fields fit.

An oversized request line, such as a very long URL, is a separate case: Nginx returns 414 Request-URI Too Large. An oversized upload body produces a 413 Request Entity Too Large error , which uses a different limit.

Clear Cookies for the Affected Site #

If you are visiting someone else’s website, start by trying the page in a new private or incognito session. If it works there, the stored cookies or another difference in your normal browser session may explain the failure. This is a useful clue, but it does not prove that a cookie is the cause.

Use your browser’s site-data settings to remove cookies for the affected domain, then reload the page. You do not need to delete cookies for every website. Clearing them usually signs you out of that site, so be ready to log in again.

If the error returns after signing in, the application may be issuing an oversized cookie or authentication token. Report that behavior to the site administrator. Application owners should reduce the cookie contents or move session data to server-side storage; repeatedly asking users to clear cookies is only a workaround.

Increase the Nginx Header Buffers #

On a server you administer, raise the limit when the larger headers are expected. First, print the configuration and its included files to find any existing header-buffer settings:

sudo nginx -T

Look for large_client_header_buffers, the relevant server blocks, and the filenames shown above each configuration section. The output contains configuration values, so avoid sharing it publicly without checking it for secrets.

For a consistent limit across sites, open the main configuration file, commonly /etc/nginx/nginx.conf:

sudo nano /etc/nginx/nginx.conf

Add the following directive inside the existing http block, or change its existing value there:

http {
    large_client_header_buffers 4 16k;
    # Keep the rest of your existing configuration here.
}

This allows up to four large buffers of 16 KiB each. The example shows where the setting belongs; do not replace your entire http block or create a second one. You usually do not need to raise client_header_buffer_size, since Nginx can switch to the larger buffers when required.

The directive is also valid in a server block, but not in location. A server-level value overrides the inherited http value. There is an early-processing detail, however: Nginx may use the default server’s buffer settings before it has selected the named virtual server (on HTTPS, SNI usually selects it first). As the virtual server selection documentation explains, selection happens in stages as Nginx reads the connection and request.

If a site-specific change has no effect, check the default server for that listening address and port as well. Setting a suitable shared value in http, and checking for server-level overrides, avoids inconsistent limits between sites.

Keep the increase modest. Buffers are allocated on demand and released when a connection enters the keep-alive state, but larger limits still allow active requests to consume more memory. Choose a value that fits your application’s expected headers.

Test and Reload Nginx #

Check the configuration before applying it:

sudo nginx -t

A successful check produces output similar to this:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Both lines confirm that the test passed. If Nginx reports an error, correct the indicated file and line before continuing.

On a systemd installation, reload the service to apply the new limit:

sudo systemctl reload nginx

Retry the failing request from the same browser session. A private window alone will not test whether the original oversized headers now fit.

Troubleshooting #

The error persists after reloading
Run sudo nginx -T again and check the effective settings, server-level overrides, and the default server for the affected port. Make sure you edited the Nginx instance receiving the request. In a container deployment, the configuration and reload must apply inside the container serving the site.

HTTP/2 requests still fail on an older Nginx
Nginx versions before 1.19.7 apply separate limits to HTTP/2 requests: http2_max_field_size (default 4k) and http2_max_header_size (default 16k). Ubuntu 22.04 and Debian 11 ship Nginx 1.18, so check the version with nginx -v, and if the site uses HTTP/2, raise those directives alongside large_client_header_buffers. Newer releases treat them as obsolete and use large_client_header_buffers instead.

You need to confirm which server rejected the request
Check the site’s configured access and error logs while reproducing the problem. The usual locations are /var/log/nginx/access.log and /var/log/nginx/error.log. A matching access-log entry with status 400 helps identify the responding instance, but does not establish the cause. Header parsing messages may require an info error-log level, so an empty error log does not rule out a header-size failure. Avoid sharing raw cookies or authentication headers from diagnostic logs.

The error returns after login
Inspect the cookies and authentication headers your application creates. Reduce token claims, remove unused cookies, or shorten their domain and path scope where appropriate. A stale cookie is only one possible cause; a valid new token may also exceed the configured limit.

A reverse proxy or application still rejects the request
A CDN, another proxy, or the backend can enforce its own limits. Check that layer’s logs before increasing anything further. Our Nginx reverse proxy guide explains the request path to the application. proxy_buffer_size controls an upstream response buffer, so changing it does not increase the client request-header limit.

Conclusion #

Size the header buffers for the requests your application actually sends. If cookies keep growing, fix how the application stores session data so users do not have to clear their browser state to reach the site.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page