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, corrupted or oversized cookies, and malformed request syntax.
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.
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. A site with many cookies, or cookies with large values, can push the total header size over Nginx’s limits and trigger a 400.
This is one of the more common causes of unexpected 400 errors on WordPress sites because:
WordPress sets multiple cookies: WordPress authentication sets several cookies for logged-in users. WooCommerce adds session cookies. Caching plugins sometimes set their own cookies. Security plugins may add cookies for bot detection or session tracking. Over time, the total cookie payload grows.
Plugin cookies with large values: Some plugins store serialized data in cookies. If the serialized value is large, a single cookie can approach or exceed Nginx’s per-header buffer size.
Third-party cookies: Analytics tools, advertising platforms, and social media integrations set cookies through JavaScript. These are sent back to your server on every request. On a site with many third-party integrations, the cookie header alone can be substantial.
Diagnosing cookie-related 400 errors
If you suspect cookies are the cause, test by clearing all cookies for the domain in your browser and attempting the request again. If the 400 disappears after clearing cookies, the cookie size is the issue.
In your browser’s developer tools, go to the Network tab, find the failing request, and look at the Request Headers section. Check the Cookie header value and its size. If it is approaching or exceeding 8KB, that is your problem.
Fixing cookie-related 400 errors
Clear the problematic cookies: For end users experiencing the issue, clearing cookies for your domain resolves it immediately. This is a temporary fix if the underlying cause is not addressed.
Identify and remove unnecessary cookies: Review which plugins and integrations are setting cookies. Deactivate plugins that set large or unnecessary cookies. Check whether third-party scripts can be configured to use fewer or smaller cookies.
Move session data server-side: If a plugin stores large values in cookies, check whether it supports storing session data in the database instead. WooCommerce, for example, can store session data in the database rather than cookies, which keeps cookie sizes small.
Reduce third-party integrations: Each analytics tool, advertising platform, and social widget that sets cookies adds to the total. Audit which third-party scripts are active and remove ones that are not providing value.
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 headersclient sent too large request or too many headers while reading client request headersrequest 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. The most common causes on WordPress sites are oversized cookies from accumulated plugin and third-party cookies, and oversized request headers from large authorization tokens or custom application headers. Diagnose by checking the Nginx error log for the specific rejection reason and using browser developer tools to inspect the size of cookies and headers being sent. Fix cookie-related 400s by clearing cookies, removing unnecessary cookie-setting plugins, and moving session data server-side where possible.