Nginx "upstream sent too big header while reading response header": raise the right buffer

1. Find the error

sudo tail -n 20 /var/log/nginx/error.log | grep 'too big header'

The upstream: part tells you which backend, and request: which page. It’s often only some pages, like the login callback, that set the big cookies.

2. Measure the headers

Ask the backend directly, bypassing Nginx, and count:

curl -s -D - -o /dev/null http://127.0.0.1:3000/login | wc -c
curl -s -D - -o /dev/null http://127.0.0.1:3000/login | grep -i '^set-cookie' | awk '{ print length }'

The first number is the total size of the headers in bytes. Choose a buffer comfortably above it: 16k for headers up to about 12 KB, 32k beyond that. The HTTP Headers Analyzer shows what’s in them, if you paste the output of curl -I.

3. Raise the buffer for a proxy

location / {
    proxy_pass http://127.0.0.1:3000;

    proxy_buffer_size 16k;
    proxy_buffers 8 16k;
    proxy_busy_buffers_size 32k;
}

• proxy_buffer_size holds the headers. It’s the one that fixes this error.
• proxy_buffers holds the body. They’re raised alongside, as Nginx checks that the sizes fit together.
• proxy_busy_buffers_size must be at least as large as one buffer, and smaller than all of them together minus one. Otherwise nginx -t refuses the config, and says which limit is broken.

Test and reload:

sudo nginx -t && sudo systemctl reload nginx

4. PHP-FPM uses its own settings

With fastcgi_pass, the proxy_* lines do nothing. Use the FastCGI ones:

location ~ \.php$ {
    include fastcgi_params;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;

    fastcgi_buffer_size 32k;
    fastcgi_buffers 16 16k;
}

The same goes for uwsgi_buffer_size with uWSGI, and grpc_buffer_size with gRPC. Laravel and WordPress sites, with many cookies from plugins, hit this often: see Nginx with Laravel and Nginx with WordPress.

5. Then shrink the headers

A bigger buffer fixes Nginx, and big headers have other costs. They travel with every response, and browsers send cookies back with every request. Browsers and other proxies have their own limits, so a CDN or load balancer in front may fail next. So also look at what’s being set:

• Session data in a cookie. Store the session on the server, and keep only an ID in the cookie.
• Several large tokens from an identity provider: keep only what the app needs.
• Duplicated Set-Cookie headers, from a bug that sets the same cookie many times.

6. The other direction: big request headers

If the browser sends too much, the error is different, and comes earlier:

400 Bad Request
Request Header Or Cookie Too Large

That’s governed by large_client_header_buffers, for example large_client_header_buffers 4 16k;. Clearing cookies for the site fixes it for one user, and shrinking them fixes it for all.