HTTP 400 Bad Request: Causes and Fixes

Beginner

The HTTP 400 Bad Request error means the server received a request it cannot understand or process. Unlike 500-series server errors, a 400 response indicates the problem lies with the client — the request itself is malformed, missing required data, or violates server-imposed limits. For CDN and web server administrators, understanding the specific causes of 400 errors is essential for distinguishing between legitimate client problems and misconfigured server limits that block valid requests.

The 400 status code is defined in RFC 7231 as a catch-all for client errors that do not fit a more specific 4xx code. When a server returns 400, it should include a response body explaining what was wrong with the request — though many servers return generic error pages that provide no diagnostic information.

What Are the Most Common Causes of 400 Errors?

Oversized cookies are the single most frequent cause of 400 errors in production environments. Browsers accumulate cookies over time from tracking scripts, analytics platforms, A/B testing tools, and session management. When the total cookie header exceeds the server's header buffer size, the server rejects the entire request with a 400 error. Nginx's default large_client_header_buffers is 4 buffers of 8KB each — if the Cookie header exceeds 8KB (common on sites with many third-party scripts), Nginx returns 400.

Malformed URLs containing unencoded special characters, double-encoded characters, or invalid UTF-8 sequences cause 400 errors. For example, a URL containing a raw space character (/search?q=hello world instead of /search?q=hello%20world) is technically malformed. While most modern servers handle this gracefully, strict HTTP parsers reject such URLs.

Invalid request body — sending a malformed JSON payload to an API endpoint that expects valid JSON, or sending a request body with a Content-Type header that does not match the actual content format. A common example: sending URL-encoded form data with a Content-Type: application/json header.

Oversized request headers beyond what the server is configured to accept. This can happen with very long Authorization tokens (JWTs can exceed 4KB), custom headers carrying large payloads, or HTTP/2 header compression issues.

How Do You Diagnose 400 Errors?

Diagnosing 400 errors requires examining the actual request being sent, not just the error response. The most reliable diagnostic tools are:

Browser DevTools Network tab — open DevTools (F12), switch to the Network tab, reproduce the error, and click on the failed request. Examine the Request Headers section to see exactly what the browser sent. Pay special attention to the Cookie header size and any custom headers.

curl with verbose output gives the most detailed view of the HTTP transaction:

# Show full request and response headers
curl -v https://example.com/api/endpoint

# Include request body for POST requests
curl -v -X POST -H "Content-Type: application/json"   -d '{"key":"value"}' https://example.com/api/endpoint

Server error logs provide the server's perspective on why the request was rejected. In Nginx, 400 errors are logged to the error log:

# Nginx error log location
/var/log/nginx/error.log

# Common 400 error messages:
# "client sent too long header line"
# "client sent invalid request"
# "upstream sent too big header"

How Do You Fix 400 Errors on the Server Side?

Server-side fixes focus on adjusting buffer sizes and validation settings to handle legitimate requests that exceed default limits.

Nginx configuration fixes:

# Increase header buffer size (default: 4 8k)
large_client_header_buffers 4 32k;

# Increase initial header buffer (default: 1k)
client_header_buffer_size 4k;

# Increase request body size limit (default: 1m)
client_max_body_size 10m;

# Increase request header timeout (default: 60s)
client_header_timeout 60s;

Apache configuration fixes:

# Increase maximum request line length (default: 8190)
LimitRequestLine 16384

# Increase maximum header field size (default: 8190)
LimitRequestFieldSize 16384

# Increase maximum number of header fields (default: 100)
LimitRequestFields 200

# Increase request body limit
LimitRequestBody 10485760

How Do CDN WAFs Cause False 400 Errors?

CDN Web Application Firewalls inspect incoming requests against rule sets designed to block SQL injection, cross-site scripting (XSS), and other attacks. Overly aggressive rules can flag legitimate requests as malicious and return 400 or 403 errors.

Common false positive triggers include:

• URLs containing SQL-like keywords (SELECT, DROP, UNION) in legitimate content
• Request bodies containing HTML or code snippets (common in CMS admin panels and code editors)
• Unusual User-Agent strings from legitimate bots, API clients, or automated testing tools
• Large request bodies that exceed WAF inspection limits

To diagnose WAF-related 400 errors, check the CDN provider's WAF event logs. These logs show which specific rule triggered and the offending part of the request. Create exception rules (whitelists) for known legitimate traffic patterns while keeping the WAF active for genuine threats.

What Is the Difference Between 400 and Related Error Codes?

Several 4xx status codes are sometimes confused with 400. Understanding the differences helps you return the correct code and provide better error messages:

The distinction between 400 and 422 is particularly important for APIs. Use 400 when the request cannot be parsed at all (syntax error). Use 422 when the request parses correctly but contains data that violates business rules (semantic error). This distinction helps API consumers debug issues faster — a 400 means "fix your request format," while a 422 means "fix your data."