Fix Nginx Client Intended to Send Too-Large Body (2026)

Nginx rejected a client request because the request body was larger than the client_max_body_size limit.

The most common reason this happens is that a client (like a web browser uploading a file, or an API client sending a large JSON payload) sent data exceeding the configured maximum allowed body size for the Nginx server. Nginx, by default, has a fairly small limit (1MB) to prevent denial-of-service attacks where an attacker floods a server with massive requests.

Here are the common causes and how to fix them:

client_max_body_size is too low for legitimate requests.
- Diagnosis: Check your Nginx configuration files (e.g., /etc/nginx/nginx.conf, /etc/nginx/conf.d/*.conf, or site-specific conf files in /etc/nginx/sites-available/). Look for the client_max_body_size directive. If it’s set to 1M or a similarly small value, this is likely your culprit.
- Fix: Increase the client_max_body_size directive. For example, to allow up to 50MB:
```
http {
    client_max_body_size 50m;
    # ... other http settings
}
```
  Or, if you need it for a specific server block:
```
server {
    listen 80;
    server_name example.com;
    client_max_body_size 50m;
    # ... other server settings
}
```
  - Why it works: This directive tells Nginx the maximum size of the client request body it will accept. By increasing it, you’re allowing larger payloads. Remember to reload Nginx after changing the configuration: sudo systemctl reload nginx.
The client_max_body_size directive is in the wrong context.
- Diagnosis: You might have set client_max_body_size inside a location block, but it needs to be in the http, server, or if in location context to be effective for the entire request. Nginx processes directives hierarchically.
- Fix: Move the client_max_body_size directive to the http or server block. If you need different limits for different locations, ensure the directive is correctly placed within the server block, and then potentially overridden within a specific location if Nginx’s parsing rules allow (though it’s generally best practice to keep it at the server level for consistency).
```
server {
    listen 80;
    server_name example.com;
    client_max_body_size 50m; # Correctly placed in server block

    location /upload {
        # This might not work as expected if client_max_body_size is only here
        # client_max_body_size 50m; # Better to have it in server block
    }
}
```
  - Why it works: Directives like client_max_body_size are designed to be applied at higher levels of the configuration hierarchy (http or server) to set a global limit for that scope. Placing it in a location block can sometimes lead to unexpected behavior or be ignored if not handled carefully.
The client is sending a request body larger than the limit_req_zone or limit_conn_zone configurations.
- Diagnosis: While client_max_body_size is the primary control for body size, other rate-limiting modules could indirectly cause issues if they involve buffering or inspecting request bodies. However, this is less common for the "too-large body" error itself. More likely, this is a misunderstanding of how these modules work. limit_req_zone and limit_conn_zone are for request rate and connection limits, not body size.
- Fix: If you suspect rate limiting is somehow interfering, review your limit_req_zone and limit_conn_zone directives and their associated limit_req and limit_conn directives. Ensure they are not set to excessively low values that might cause Nginx to prematurely close connections or reject requests. However, for the specific error "Client intended to send too large body," this is unlikely to be the direct cause.
```
http {
    # Example of rate limiting - ensure these are sensible
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=5r/s;
    limit_conn_zone $binary_remote_addr zone=perip:10m;

    server {
        # ...
        location / {
            limit_req zone=mylimit burst=10 nodelay;
            limit_conn perip 10;
        }
    }
}
```
  - Why it works: Properly configured rate and connection limits prevent abuse but shouldn’t directly cause a "too-large body" error unless they’re misconfigured to proxy or buffer requests in a way that exceeds other limits.
The proxy_request_buffering or client_body_buffer_size is too small when proxying.
- Diagnosis: If Nginx is acting as a reverse proxy (proxy_pass), it might buffer the client’s request body before sending it to the backend. If proxy_request_buffering is enabled (which is the default for non-GET/HEAD requests) and client_body_buffer_size is too small, Nginx might fail to buffer the entire body, leading to errors. The client_max_body_size still applies, but intermediary buffering can also cause issues.
- Fix: Increase client_body_buffer_size. It should generally be at least as large as the largest expected body size, or at least sufficiently large to handle chunks of data. A common setting is 128k or 256k.
```
http {
    client_body_buffer_size 256k;
    # ...
}
```
  If proxy_request_buffering is causing issues (rarely), you could disable it, but this means Nginx will stream the request directly to the backend, which can be inefficient and might not be supported by all backends.
```
location /api/ {
    proxy_pass http://backend;
    proxy_request_buffering off; # Use with caution
}
```
  - Why it works: client_body_buffer_size determines the size of the buffer Nginx uses to read the client’s request body. Increasing this allows Nginx to hold more data in memory before writing to disk or passing it to the backend. Disabling proxy_request_buffering forces Nginx to stream data, bypassing local buffering.
The request is being split across multiple TCP packets, and Nginx is misinterpreting the total size.
- Diagnosis: This is a very rare edge case. If network intermediaries (like load balancers, firewalls) are fragmenting packets in an unusual way, or if there are issues with TCP window scaling, Nginx might not correctly assemble the full request body before checking its size. This is almost always a network configuration problem outside of Nginx.
- Fix: Ensure your network path is not aggressively fragmenting or reassembling packets in a way that interferes with Nginx’s stream processing. Check MTU sizes along the path. This is more of a network troubleshooting task than an Nginx one.
  - Why it works: By ensuring packets are handled correctly by network devices, Nginx receives a contiguous stream of data that it can accurately measure against client_max_body_size.
The large_client_header_buffers directive is too small.
- Diagnosis: This directive controls the number and size of buffers used for reading large client request headers. While not directly for the body, very large headers can sometimes be misinterpreted or lead to issues in how Nginx parses the start of a request, potentially affecting how it handles the subsequent body. This is an unusual cause for this specific error, but it’s worth checking if other common causes are ruled out.
- Fix: Increase the buffer size for client headers.
```
http {
    large_client_header_buffers 4 16k; # Increase buffer size from default (e.g., 4 8k)
    # ...
}
```
  - Why it works: This provides more memory for Nginx to parse potentially large HTTP headers, ensuring the request is parsed correctly before the body size is evaluated.

After applying any changes, remember to test your configuration (sudo nginx -t) and reload Nginx (sudo systemctl reload nginx).

The next error you might hit if you increase client_max_body_size too much or if the backend application has its own limits is a "502 Bad Gateway" or a "504 Gateway Timeout" if the backend application cannot handle the large request.