How to Fix 400 Bad Request in Nginx

A 400 Bad Request error means Nginx received a request it could not or would not process because something about the request itself was malformed or invalid. Unlike a 404 (resource not found) or a 500 (server error), a 400 is a client-side error – the problem is in the request being sent, not in the server or the application.

The most common causes are oversized request headers, oversized cookies, and malformed request syntax. If your browser shows the specific message “Request Header Or Cookie Too Large”, the cause is already identified – go straight to the dedicated 400 Bad Request: Request Header Or Cookie Too Large in Nginx guide, which walks through the cookie-specific diagnosis and fix end-to-end. This guide covers the broader set of causes when the message is just “400 Bad Request” without that hint.

How Nginx validates requests#

Before passing a request to PHP or serving a file, Nginx performs basic validation on the incoming request. If the request fails validation, Nginx returns a 400 without involving PHP at all. This is intentional – Nginx rejects clearly invalid requests early to protect the application layer.

The checks Nginx performs include:

• Request header size limits
• Cookie size limits
• URI length limits
• Basic HTTP syntax validation

Most legitimate browser requests pass all of these without issue. The 400 typically appears when something has grown beyond normal bounds – usually headers or cookies.

Oversized request headers#

HTTP headers carry metadata about the request – the browser type, accepted content types, authorization tokens, cookies, and more. Nginx enforces limits on how large these headers can be.

The relevant directives are:

• large_client_header_buffers – controls the number and size of buffers used to read large client request headers. The default is 4 buffers of 8KB each.
• client_header_buffer_size – the size of the buffer used for reading the first part of the request header. Default is 1KB.

If the combined size of all request headers exceeds the configured buffer limits, Nginx returns a 400.

This most commonly happens with:

Authorization headers: Applications that use JWT tokens or OAuth tokens in Authorization headers can generate very long header values, particularly if the token payload is large. Some servers return a 431 Request Header Fields Too Large instead of a 400 when a specific header like Authorization exceeds the limit.

Custom application headers: Some applications add multiple custom headers to every request. If these accumulate over time – through middleware, proxies, or application logic – the total header size can grow beyond Nginx’s defaults.

Referrer headers: Long referrer URLs can occasionally push header sizes over the limit, though this is less common.

On managed hosting, header buffer sizes are configured at the server level. If you are consistently hitting this limit due to large authorization tokens or custom headers, contact your hosting provider to request an adjustment.

Oversized cookies#

Cookies are sent as request headers, so a site that accumulates many cookies – or cookies with large serialized values – can push the total header size past Nginx’s buffer limits and trigger a 400. This is one of the more common causes of unexpected 400 errors on WordPress sites, because WordPress authentication, WooCommerce sessions, caching plugins, security plugins, and third-party analytics scripts all add to the cookie payload over time.

When this happens, Nginx usually surfaces the error to the browser as the more specific message “400 Bad Request – Request Header Or Cookie Too Large” rather than a plain 400. If that is what you are seeing, the cookie-specific guide covers diagnosis (developer tools, incognito test, error log entries), the temporary fix (clear cookies for the domain), and the permanent fix (audit cookie-setting plugins, move WooCommerce sessions server-side, scope cookies tightly, raise large_client_header_buffers if needed) in full detail: 400 Bad Request: Request Header Or Cookie Too Large in Nginx.

If your 400 does not mention cookies, the cause is more likely one of the URI or HTTP-syntax issues below.

Malformed request URI#

Nginx returns a 400 if the request URI contains invalid characters or formatting. This is less common with browser-generated requests but can appear with:

• Automated scripts or bots sending malformed requests
• Applications constructing URLs incorrectly
• Double-encoded URLs where the encoding itself contains invalid characters

If the 400 is appearing for specific URLs rather than broadly, check whether the URL contains characters that need to be properly encoded.

Invalid HTTP syntax#

A 400 can also result from an HTTP request that does not conform to the HTTP specification – missing required headers, invalid HTTP version, or malformed request line. This almost never happens with real browsers but can appear with:

• Poorly written API clients
• Automated tools or bots
• Load testing scripts with misconfigured request templates

If you control the client making the request, validate that it is sending properly formed HTTP requests with all required headers.

How to diagnose a 400 in Nginx#

Check the Nginx error log

The error log shows the specific reason Nginx rejected the request. Common entries for 400 errors include:

client sent invalid header line while reading client request headers

client sent too large request or too many headers while reading client request headers

request line is too large (XXXX bytes)

The message tells you exactly what Nginx found invalid. “Too large request or too many headers” points to header or cookie size. “Invalid header line” points to malformed header syntax.

On Hostney, error logs are available under Logs & Statistics > Error Log in the control panel.

Use browser developer tools

Open developer tools, go to the Network tab, and find the failing request. Check the Response tab to confirm it is a 400 and the Request Headers tab to inspect what was sent. Pay particular attention to the Cookie header size and any unusually long header values.

Test with a clean browser profile

Open an incognito or private browsing window, which starts with no cookies. If the 400 does not appear in a clean session but does appear in your regular session, cookies from your regular session are the cause.

400 errors from bots#

A significant portion of 400 errors in Nginx logs are from bots and automated scanners sending malformed requests. These are not your site visitors experiencing problems – they are automated tools probing the server with invalid requests.

You can identify bot-generated 400s by looking at the User-Agent and IP address in the access log alongside the error log entries. If the 400s are coming from a small number of IPs with automated user agents, they are likely bot traffic rather than a configuration problem affecting real users.

On Hostney, the bot detection system handles a large portion of this traffic before it reaches the application layer. Bot-generated 400s in your error log are typically noise rather than a problem requiring action.

Summary#

A 400 Bad Request in Nginx means the request was malformed or exceeded configured limits. Use the error log to identify which rule fired:

• “too large request or too many headers” – oversized authorization tokens, custom headers, or accumulated cookies. If the browser shows “Request Header Or Cookie Too Large”, follow the dedicated cookie/header guide.
• “invalid header line” – malformed header syntax, almost always from a misbehaving client or bot.
• “request line is too large” – the URI itself is too long; usually a broken client or a double-encoded URL.

If the 400s are concentrated on a small number of automated user agents, treat them as bot noise rather than a configuration problem.

If you are seeing a different Nginx error, it may be a 404 Not Found (resource does not exist or permalink misconfiguration), a 405 Method Not Allowed (HTTP method not supported for the endpoint), a 406 Not Acceptable (the server cannot produce a response matching the request’s Accept headers), a 413 Request Entity Too Large (upload exceeds size limit), a 422 Unprocessable Entity (request syntax is valid but the data fails validation), a 431 Request Header Fields Too Large (a header or cookie exceeded the server’s per-field size limit), a 503 Service Unavailable (PHP-FPM is down or overloaded), or a 504 Gateway Timeout (PHP-FPM did not respond in time). For a complete list, see how to fix the most common WordPress errors.