Fixing “400 Bad Request – Request Header Or Cookie Too Large” on WordPress Sites (Plesk + Nginx)

If you’re running a WordPress site on a Plesk server with Nginx in front, you may occasionally see this scary message:

400 Bad Request – Request Header Or Cookie Too Large

From the visitor’s perspective, the site is “down.”
From the server’s perspective, it’s just refusing a request that’s gotten… a bit out of control.

The good news: this error is usually easy to diagnose and fix once you understand what’s going on.

What this error actually means

Every time your browser talks to a website, it sends:

• Headers – information about the request (user agent, referrer, cookies, etc.).
• Cookies – small bits of data the site asked your browser to store.

Nginx (the web server in front of Apache/PHP on Plesk) has limits on how big those headers can be. If a request has too much header data – usually because one or more cookies became huge – Nginx returns:

400 Bad Request
Request Header Or Cookie Too Large

So, in plain language:

The browser is sending too much stuff in the request headers, and Nginx is refusing it.

On WordPress sites, this almost always traces back to oversized cookies created by a plugin or theme.

Typical real-world causes

Some common patterns we see:

• A plugin stores shopping cart contents, recently viewed products, or tracking data directly in a cookie.
• An A/B testing or personalization plugin appends more and more data to the same cookie over time.
• Debugging or “toolbar” plugins storing large state blobs in cookies.
• Multiple plugins each adding their own cookies, and together they exceed the header size limit.

Often, the problem only affects specific users—usually staff members who are logged in all day, or power users who have accumulated a big cookie over time.

Step 1: Quick fix for the affected user

If just one or a few users are seeing the error, the fastest fix is:

1. Open the site in the affected browser.
2. Clear cookies for this site only (not all cookies).
   • In Chrome-based browsers:
     • Click the lock icon (or shield) in the address bar.
     • Go to Cookies and site data / Site settings → Clear data / Remove.
3. Reload the page.

If the site starts working again for that person, you’ve confirmed:

✅ The 400 error was caused by oversized cookies for this domain.

However, this doesn’t fix the root cause. If a plugin continues to generate huge cookies, the error will come back as cookies “grow” again.

Step 2: Confirm the issue on the server (Plesk + Nginx)

On a Plesk server, Nginx sits in front as a reverse proxy. To see what it’s complaining about, check the Nginx proxy error log for the domain:

You’re looking for entries like:

or:

If you see those for this vhost, that confirms:

✅ Nginx is rejecting requests because the header (usually cookies) is too large.

Step 3: Identify which cookie is too big

To properly fix the problem, you want to know which cookie is out of control.

The easiest way is in the browser’s dev tools:

1. Open the site in Chrome/Edge.
2. Press F12 to open Developer Tools.
3. Go to the Network tab.
4. Reload the page and click on the main request (usually /).
5. Look under Headers → Request Headers → Cookie.

You’ll probably see one or more cookies with:

• Very long names, or
• Values that are thousands of characters long.

Match that cookie name back to:

• A plugin setting,
• A theme feature, or
• Custom code that calls setcookie().

Common WordPress offenders

• E-commerce / cart or “recently viewed” plugins.
• A/B testing and personalization tools.
• Analytics or tracking plugins that store a “session log” in a cookie.
• Debug/toolbox plugins used on staging but left active on production.

Once you know the name of the cookie and which plugin generates it, you can fix the real problem.

Step 4: Fix the root cause in WordPress

Depending on what you find, your options are:

1. Reconfigure the plugin

If the plugin is otherwise useful:

• Check if it has a setting to:
  • Use server-side sessions (database/Redis) instead of cookies.
  • Reduce what it stores in cookies.
  • Disable specific features like “track every action in a cookie.”

2. Disable or replace the plugin

If the plugin isn’t essential or has no configuration options:

• Temporarily disable it and test if the error disappears.
• Replace it with a more cookie-friendly alternative.

3. Remove custom cookie logic

For custom code in a theme or custom plugin:

• Search for setcookie( in:
  • functions.php
  • mu-plugins/
  • Any custom plugin code
• Make sure you’re not:
  • Storing large JSON data blobs in cookies.
  • Appending to the same cookie indefinitely.
• Prefer storing larger data structures in:
  • The database (user meta, options, custom tables), or
  • A server-side session store.

Step 5 (Optional): Increase Nginx header limits in Plesk

While you should always fix oversized cookies, it’s sometimes reasonable to give Nginx a bit more headroom.

In Plesk, you can increase the large_client_header_buffers directive for a single domain:

1. Log into Plesk as admin.
2. Go to Domains → yourdomain.com → Apache & nginx Settings.
3. In Additional Nginx directives, add something like:
   
   large_client_header_buffers 4 16k;

   1 2	large_client_header_buffers 4 16k;

4. Click OK or Apply to rebuild the configuration and reload Nginx.

What this does:

• Allows Nginx to accept slightly larger request headers before throwing 400 errors.
• Limits the change to this vhost, not the entire server.

⚠️ Important: This is a safety margin, not a substitute for fixing the oversized cookies. Extremely large headers can still be a performance and security concern.

Step 6: Monitor after the fix

After changes, keep an eye on the logs:

You want to see:

• No new “too large header” errors for typical traffic.
• Occasional single entries might still show up for users with very old cookies; those should disappear when they clear cookies or when cookie names/values change after your fixes.

If errors persist, revisit:

• Browser’s Cookie header to ensure no new oversized cookie is being generated.
• Plugin configuration or recently installed plugins.

When to call in help

If you’re a site owner and not comfortable digging into:

• Plesk logs,
• Nginx directives, or
• WordPress code/plugins,

this is a great time to hand things off to a hosting partner or sysadmin who works with Nginx and WordPress regularly.

At Reliable Penguin, we typically:

1. Confirm the issue in the Nginx logs.
2. Identify and tame the offending cookie or plugin.
3. Adjust Nginx header limits where appropriate.
4. Implement monitoring so it doesn’t sneak back later.

Summary

• Symptom: “400 Bad Request – Request Header Or Cookie Too Large” on a WordPress site behind Nginx.
• Cause: Request headers—usually cookies—are too big for Nginx’s configured limits.
• Quick fix: Clear cookies for the site in the affected browser.
• Proper fix: Identify and fix the plugin/theme/custom code generating huge cookies, and optionally increase Nginx’s header size limits per domain via Plesk.