Fix Nginx "Upstream Sent Too Big Header" Errors

You log into wp-admin and instead of the dashboard, you get a blank page, a 502, or a connection reset — but only after logging in. The front end of the site loads fine. If you check the Nginx error log and see a line like upstream sent too big header while reading response header from upstream, you've found the culprit, and it has nothing to do with your theme or plugin code being broken. It's a buffer size mismatch between Nginx and PHP-FPM.

Symptom: wp-admin Breaks, the Front End Doesn't

This one has a fairly specific fingerprint. You'll usually see one or more of these:

• The public site loads normally, but /wp-admin/ returns a 502 Bad Gateway, an empty white response, or the connection just drops.
• It started right after logging in — the login form itself works, but the redirect to the dashboard fails.
• It got worse after installing a new security plugin, a page builder, or an analytics/consent tool.
• Logging out and back in with an incognito window sometimes "fixes" it temporarily, then it comes back.

Check /var/log/nginx/error.log (or the vhost-specific log under /usr/local/apache/logs/ if you're on cPanel with EA-Nginx in front of Apache) and look for:

upstream sent too big header while reading response header from upstream, client: 203.0.113.4, server: example.com, request: "GET /wp-admin/ HTTP/1.1", upstream: "fastcgi://unix:/var/run/php-fpm/example.com.sock:", host: "example.com"

If that line is there, you're in the right place.

Cause: PHP-FPM's Response Headers Are Bigger Than Nginx's Buffer

Nginx reads the response headers coming back from PHP-FPM into a fixed-size buffer before it does anything else with the response. By default that buffer is tiny — usually 4k or 8k, depending on your OS's page size. Most pages never come close to that limit. WordPress admin pages do, for one specific reason: cookies.

Every time WordPress sets a cookie — the auth cookie, the logged-in cookie, the test cookie — that's a Set-Cookie header. Now stack on top of that:

• A security plugin setting its own session or nonce cookies
• A caching plugin adding cache-status headers
• WooCommerce setting cart/session cookies
• A consent/cookie-banner plugin adding its own tracking cookie
• Custom headers from a firewall or CDN sitting in front (X-Forwarded-*, CF-*, security headers like CSP which can get long with multiple directives)

Individually these are small. Added up across five or six active plugins, the total header block for a single wp-admin response can easily blow past 8k. Nginx has nowhere to put the overflow, so it gives up and throws the "too big header" error instead of passing anything back to the browser.

This is also common right after moving to a new server or a fresh Nginx install, because the default buffer sizes in a stock nginx.conf were never tuned for a cookie-heavy CMS admin panel — they were fine for the static front end, which is usually all anyone tests before going live.

Fix: Increase the FastCGI Buffer Size

The fix is a config change, not a plugin fix. If you're on a VPS running Nginx directly (either standalone, or as a reverse proxy in front of PHP-FPM), edit your site's server block or the relevant fastcgi_params include:

server {
    ...
    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php-fpm/example.com.sock;
        fastcgi_buffer_size 32k;
        fastcgi_buffers 4 32k;
        fastcgi_busy_buffers_size 64k;
        include fastcgi_params;
    }
}

What each line does:

Then test and reload:

nginx -t
systemctl reload nginx

32k is a comfortable ceiling for most WordPress sites, even fairly plugin-heavy ones. If you're still seeing the error after this, double it to 64k rather than guessing randomly — it almost always means one plugin is generating an unusually large cookie (some page builders and A/B testing tools are the worst offenders).

If You're Behind a Reverse Proxy or CDN

If Nginx is acting as a reverse proxy in front of another web server (Apache, or a separate app server) rather than talking to PHP-FPM directly, the relevant directives are the proxy_* versions instead:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_buffer_size 32k;
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

This setup is common if you're running Cloudflare in front of the site, or if you've got Nginx handling static assets and SSL termination while Apache or a container handles PHP. The same header-bloat problem shows up either way; you're just tuning a different set of buffers depending on which upstream is throwing the error.

On Shared cPanel Hosting (EA-Nginx)

If you're on shared hosting with cPanel's Nginx reverse proxy (EA-Nginx) sitting in front of Apache, you won't have direct access to nginx.conf. In that case:

• Open a support ticket with your host and reference the exact error line from the log — most hosts can bump the buffer size for your account specifically.
• In the meantime, deactivate plugins one at a time (security plugin first, then any A/B testing or heatmap tool) and check if wp-admin comes back after each one — this narrows down which plugin's cookies are pushing you over the limit while you wait on support.

Prevention

• If you're setting up a new VPS for WordPress hosting, bump fastcgi_buffer_size to at least 16k as part of your first-hour Nginx config, before you even install WordPress — it costs nothing and saves this exact fire drill later.
• Run only one caching plugin and one security plugin at a time. Overlapping plugins in the same category tend to duplicate cookies and headers for no benefit.
• After installing any plugin that touches sessions, consent banners, or A/B testing, log into wp-admin in a fresh incognito window immediately to catch header bloat before it becomes "the site's been broken since yesterday."
• Keep an eye on error.log after migrations — a site moved from Apache-only hosting to an Nginx-fronted VPS is the single most common place this error appears, because it was never triggered on the old stack.

Frequently Asked Questions

Why does only wp-admin break and not the rest of the site?

Logged-out visitors on the public pages don't get the auth/session cookies that trigger this. The header bloat only happens once WordPress starts setting login-related cookies, which is why the error shows up specifically after authentication.

Is this the same issue as a 413 "Request Entity Too Large" error?

No. 413 is about the size of data you're uploading to the server (client_max_body_size). This is about the size of the response headers coming back from PHP-FPM to Nginx — a completely different buffer, controlled by different directives.

I increased fastcgi_buffer_size but the error is still there. What now?

Double it again (32k to 64k, or 64k to 128k) and reload. If it still fails at 128k, something is generating an unusually large single header rather than many small ones — check for a plugin embedding a large token or JSON blob directly into a cookie or a custom header, which is unusual but does happen with some page builders.

Can I just set the buffer size extremely high to avoid ever hitting this again?

You can, but there's a small memory cost per connection since Nginx allocates these buffers per request. 32-64k is plenty for essentially any WordPress site; going much higher "just in case" mostly just wastes memory under load without fixing anything.

Does this affect other CMSs, or is it WordPress-specific?

It's not WordPress-specific — it's about cookie and header volume in general. WordPress admin panels just happen to be the most common trigger because of how many plugins stack cookies on the same login flow. Any PHP app with heavy session data or a lot of middleware-added headers can hit the same limit.