# How to Fix “400 Bad Request: Request Header or Cookie Too Large” in xCloud

> Fix the Nginx “400 Bad Request: Request Header or Cookie Too Large” error in xCloud step by step using Nginx Customization — no SSH required.

If your website displays **400 Bad Request: Request Header or Cookie Too Large**, Nginx is rejecting the request because its headers — usually the browser's `Cookie` header — are larger than the configured buffer can accept.

For a quick test, open the affected page in a private or incognito window. If it works there, clear the cookies for that website. To prevent the error from returning for other users, you can safely increase the request-header buffers from the xCloud dashboard with the **Nginx Customization** feature.

This guide shows the complete xCloud workflow without editing server files over SSH.

## Quick answer

In xCloud, open the affected site and go to **Tools → Nginx Customization → Add a New Config**. Choose **Use My Own Config** and **Inside Server Block**, then add:

```nginx
client_header_buffer_size 4k;
large_client_header_buffers 4 16k;
```

Select **Run & Debug**. If the Nginx test succeeds, select **Save Config**, clear the affected site's cookies, and test again.

## What causes “Request Header or Cookie Too Large”?

Every browser request includes HTTP headers. One of them, `Cookie`, can contain session IDs, login tokens, shopping-cart data, preferences, consent values, and analytics identifiers.

Nginx initially reads request headers using `client_header_buffer_size`. If a request does not fit, it uses the larger buffers configured by `large_client_header_buffers`. Nginx returns a 400 response when the request line or a header field still cannot fit.

Common causes include:

- too many cookies for the same domain;
- a plugin or application repeatedly creating cookies;
- oversized authentication or session tokens;
- large analytics, advertising, or consent cookies;
- stale or corrupted browser cookies;
- a proxy, CDN, or SSO service adding large request headers.

> **Important:** `large_client_header_buffers 4 16k;` does not allow one 64 KB cookie header. A single request-header field must fit inside one 16 KB buffer. The first value is the number of buffers; the second is the size of each buffer.

## Before changing Nginx: confirm cookies are the cause

### 1. Test in a private window

Open the same URL in an incognito or private window.

- If it works privately but fails in the normal browser session, stored cookies are the likely cause.
- If it fails in both sessions, the response may be coming from a CDN, proxy, firewall, application, or another type of malformed request.

### 2. Clear cookies for only the affected site

Remove cookies and site data for the affected domain, then reload the page. You usually do not need to clear cookies for every website.

Clearing cookies may sign the user out. It is a useful immediate fix, but it does not solve an application that keeps creating oversized cookies.

### 3. Check the browser request when needed

In Chrome or another Chromium-based browser:

1. Open **Developer Tools**.
2. Select **Network**.
3. Reload the affected page.
4. Select the failed request.
5. Under **Request Headers**, inspect the `Cookie` header.

If the Cookie header is unusually long, continue with the xCloud configuration below.

## Fix the error with xCloud Nginx Customization

The steps below use the same **Custom NGINX Config** feature described in [How To Configure Custom NGINX In xCloud](/docs/configure-custom-nginx-xcloud/). If the error affects several sites on the same server, see [how to apply bulk Nginx customization](/docs/how-to-apply-bulk-nginx-customization/) after you have confirmed the fix on one site.

### Step 1: Open the affected site in xCloud

Sign in to the [xCloud dashboard](https://app.xcloud.host/), open the server that hosts the website, and select the affected site.

### Step 2: Open Nginx Customization

From the site sidebar, go to:

**Tools → Nginx Customization**

This feature is available for sites running an Nginx-based stack and requires permission to manage the site's settings.

### Step 3: Add a custom configuration

Select **Add a New Config** and complete the fields as follows:

- **Select Template:** `Use My Own Config`
- **Select Config Type:** `Inside Server Block`
- **Config File Name:** `request-header-buffers`

Enter the filename without spaces or a file extension. xCloud adds the `.conf` extension automatically.

![The Create Custom Nginx Configuration form in xCloud with Inside Server Block selected and the config content filled in](/_landing/docs/configure-custom-nginx-xcloud-image-76.png)

### Step 4: Add the buffer directives

Paste this into **Config Content**:

```nginx
client_header_buffer_size 4k;
large_client_header_buffers 4 16k;
```

Why these values?

- `client_header_buffer_size 4k;` increases the initial buffer used for ordinary request headers.
- `large_client_header_buffers 4 16k;` allows Nginx to allocate four larger buffers of 16 KB when required.

These are practical starting values for legitimate requests with larger cookies. Avoid setting very large buffers without first identifying the actual header size and source.

The **Inside Server Block** placement matters. These directives are valid in Nginx's `http` or `server` context, but not inside a `location` block.

### Step 5: Run the Nginx validation

Select **Run & Debug** before saving.

xCloud generates the configuration and runs an Nginx configuration test. Continue only when the result reports that the configuration test is successful.

![A successful Run & Debug result in xCloud showing the Nginx configuration test passed](/_landing/docs/configure-custom-nginx-xcloud-image-77.png)

If validation fails:

1. Confirm that both lines end with semicolons.
2. Confirm **Inside Server Block** is selected.
3. Check for another custom configuration that defines the same directives in the same context.
4. Correct the reported line and run the test again.

Do not save a configuration that fails validation. If xCloud reports that it cannot regenerate the site's Nginx configuration at all, follow [how to troubleshoot Nginx configuration regeneration failures](/docs/how-to-troubleshoot-nginx-configuration-regeneration-failures-with-xcloud/) first.

### Step 6: Save and activate the configuration

Select **Save Config**. The new entry should appear in the Custom Nginx Config list as active.

xCloud validates the generated Nginx configuration before saving it. You do not need to edit `/etc/nginx/nginx.conf` manually or restart Nginx over SSH for this workflow.

### Step 7: Test the website

Test all of the following:

1. Open the affected page in a private window.
2. Clear the site's cookies in the previously affected browser, sign in again if needed, and retry the same page.
3. Test important authenticated flows such as login, checkout, account pages, or the WordPress dashboard.
4. Confirm that ordinary visitors can still load the homepage and key pages.

The expected result is that the page loads without the Nginx 400 error.

## What to do if the error remains

### Confirm which layer returns the 400

A CDN, web application firewall, load balancer, or reverse proxy can reject a large header before the request reaches your xCloud server. If the xCloud change is active but the error remains, review every proxy layer in front of the site, including Cloudflare or another CDN. See [troubleshooting Cloudflare issues for WordPress](/docs/troubleshooting-cloudflare-issues-for-wordpress/) for the Cloudflare-specific checks.

### Find the cookie that keeps growing

Increasing the Nginx buffers treats the immediate symptom. If the error returns after cookies are cleared, inspect the site's cookies in browser developer tools and look for:

- duplicate cookies with similar names;
- cookies set on both the root domain and subdomains;
- large JWT or authentication values;
- plugins storing serialized data in cookies;
- abandoned analytics or advertising cookies;
- cart, session, or consent cookies that continually grow.

For a durable fix, remove unused cookies, reduce token size, set appropriate expiration times, and store large session data server-side instead of in the browser.

### Increase the 16 KB size only as a diagnostic step

If a known legitimate header is larger than 16 KB, you can temporarily test:

```nginx
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
```

Use this as a diagnostic increase, not the default first choice. Larger buffers increase per-connection memory use and can hide uncontrolled cookie growth. Identify and reduce the source of the oversized header whenever possible.

### Distinguish similar errors

- **400 Bad Request: Request Header or Cookie Too Large** points to request headers, commonly cookies.
- **414 Request-URI Too Large** points to an oversized request URI or query string; `large_client_header_buffers` also affects the maximum request-line size.
- Upload-size errors concern the request body and require different settings, such as `client_max_body_size`.

## How to roll back the change in xCloud

If the custom configuration causes an unexpected result:

1. Return to **Tools → Nginx Customization**.
2. Find `request-header-buffers.conf`.
3. Switch it from **Active** to **Inactive** for a reversible rollback, or delete it if it is no longer needed.
4. Test the website again.

Deactivating the entry keeps the saved configuration available for later use without applying it to the generated Nginx configuration.

## Recommended values and safety notes

| Directive | Starting value | Purpose |
|---|---|---|
| `client_header_buffer_size` | `4k` | Initial buffer for the request line and headers |
| `large_client_header_buffers` | `4 16k` | Four fallback buffers, each 16 KB |

Keep these points in mind:

- One oversized header field must fit into one large buffer.
- Increasing the number of buffers does not increase the maximum size of one Cookie header.
- Use the smallest values that accommodate legitimate traffic.
- If many users encounter the error, investigate the application or plugin that creates the cookies.
- Check upstream CDN or proxy limits when the origin configuration is correct.
- Always use **Run & Debug** before saving a custom Nginx change.

## Frequently asked questions

### Can I fix “Request Header or Cookie Too Large” without SSH?

Yes. For an xCloud-managed Nginx site, use **Tools → Nginx Customization** to add, validate, save, deactivate, or delete the custom configuration from the dashboard.

### Where should I add the directives in xCloud?

Choose **Inside Server Block**. Both `client_header_buffer_size` and `large_client_header_buffers` are valid in Nginx's `server` context. Do not add them inside a PHP, proxy, or main `location` block.

### Will clearing browser cookies fix the error?

It often fixes the problem immediately for one browser because it removes the oversized Cookie header. However, the error can return if the application, plugin, or third-party service recreates the same cookie bloat.

### Does `4 16k` mean one request header can be 64 KB?

No. It creates four 16 KB buffers. A single request line or header field, such as the complete Cookie header, must fit inside one 16 KB buffer.

### Should I use `4 32k` instead?

Start with `4 16k`. Consider `4 32k` only when you have measured a legitimate header that needs more room and have checked why it is that large. Oversized settings consume more memory and may conceal an application problem.

### Why does the site work in incognito mode?

Private windows begin without the site's existing cookies. If the site works privately, the normal browser profile is probably sending a stale or oversized Cookie header.

### Why does the error remain after changing Nginx?

The custom configuration may be inactive, placed in the wrong context, or blocked by another proxy layer. Confirm the xCloud entry is active, run the built-in validation, clear the site's cookies, and check any CDN or reverse proxy in front of the xCloud server.

## Final checklist

- Confirm the page works in a private window.
- Clear cookies for the affected domain.
- Open **Tools → Nginx Customization** in xCloud.
- Create `request-header-buffers` as **Inside Server Block**.
- Add the `4k` and `4 16k` directives.
- Select **Run & Debug** and require a successful result.
- Select **Save Config** and confirm the entry is active.
- Retest the affected browser and important logged-in flows.
- Investigate the cookie source if the issue returns.

## References

- Nginx: [client_header_buffer_size](https://nginx.org/en/docs/http/ngx_http_core_module.html#client_header_buffer_size)
- Nginx: [large_client_header_buffers](https://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers)
- MDN: [400 Bad Request](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/400)

If you run into any issues with this fix, feel free to reach out to our [support team](/docs/access-built-in-support-portal-in-xcloud/) for help.