nginx 413 Request Entity Too Large client_max_body_size location
When nginx returns 413 Request Entity Too Large even though client_max_body_size is set in the server block, a location block is often overriding it. Here's how to find and fix that override.
Rao Aadil, India 6 min read
Confirm the 413 and capture the failing request
Reproduce the upload that exceeds 2 MB. The client gets an HTTP 413 Request Entity Too Large response. In a browser this usually appears as a plain error page; with curl you can see the status code directly:
curl -X POST -F "[email protected]" https://example.com/upload -i
On Windows, use curl.exe in PowerShell or cmd the same way. The first line of the response shows HTTP/1.1 413 Request Entity Too Large.
Check the nginx error log to confirm the failure. On Linux:
tail -n 100 /var/log/nginx/error.log
On Windows, from PowerShell:
Get-Content C:\nginx\logs\error.log -Tail 100
Look for a line similar to:
client intended to send too large body: 2097152 bytes
That line usually includes the request URI and the Content-Length. The exact wording may vary slightly between nginx versions, but it identifies the upload that failed. The default client_max_body_size in many nginx builds is 1m, so a 2 MB upload fails unless an explicit directive overrides it at the right level. If you see this in the error log but your server block already has client_max_body_size 20m;, a location block is the likely culprit.
“Uploads fail beyond a certain size and the limit is not where you expect it to be.”
It finds which layer is imposing the cap, since client_max_body_size can be set in the http, server or location block, and shows you the one that is actually applying.
It reads the real state of the server before it says anything, shows you the exact command, and waits for your approval. Windows and Linux, over the SSH access you already have.
Find which server and location block nginx uses for the upload URL
Determine which config file is actually serving the domain. On Linux, inspect sites-available, sites-enabled, and conf.d under /etc/nginx/. On Windows, the main config is often C:\nginx\conf\nginx.conf, with included files possibly in C:\nginx\conf\sites-available or similar, depending on your install. The install path is not standardized, so adapt C:\nginx to your actual nginx directory.
Dump the full effective configuration with nginx -T. This prints the merged config that nginx actually loads, including all includes and the order of directives.
Linux:
sudo nginx -T
Windows, from a PowerShell prompt in the nginx directory:
cd C:\nginx
.\nginx -T
Search the dumped config for server_name matching your domain. On Linux, pipe through grep:
sudo nginx -T | grep -n "server_name example.com"
On Windows, use Select-String:
.\nginx -T | Select-String "server_name example.com"
Once you have the server block, look for location blocks inside it. The upload endpoint—for example location /upload or a regex location like location ~ \.php$—is the layer that can override the server-level client_max_body_size. Search for client_max_body_size within that location block. If present, it takes precedence over the server block setting.
If you manage many sites and need to trace which file serves a domain quickly, a tool that manages nginx and IIS can help locate the exact config file and the log entries for the failing upload. It will not compute the effective inheritance for you, so you still need to read the merged config with nginx -T or inspect the located file to see the client_max_body_size override.
Fix the override in the correct location block
Open the config file that contains the overriding location block. On Linux, this is typically something like /etc/nginx/sites-available/example.com. On Windows, the path might be C:\nginx\conf\sites-available\example.com or a file included directly from nginx.conf.
Inside the location block, either remove the client_max_body_size directive entirely to inherit the server value, or change it to a larger value. For example:
location /upload {
client_max_body_size 20m;
proxy_pass http://backend;
}
If no location-level directive exists but your server-level client_max_body_size is set and the 413 persists, verify that the server block you edited is actually the one serving the domain and not a default server. The default server may be handling requests for a domain that doesn't match any other server_name.
On Windows, the config syntax is identical to Linux. Paths use backslashes, but directives and semicolons are the same. Make sure the directive ends with a semicolon and the unit is m or g (for example, 20m or 1g).
Validate and reload nginx safely
Test the configuration before reloading. nginx -t catches syntax errors before they affect running traffic.
Linux:
sudo nginx -t
Windows, from the nginx directory:
cd C:\nginx
.\nginx -t
If the test reports errors, fix them before applying changes. Once the test passes, reload nginx.
Linux:
sudo systemctl reload nginx
or
sudo nginx -s reload
Windows, from the nginx directory:
.\nginx -s reload
After reloading, confirm nginx is running correctly and then retry the upload that originally failed. If the 413 persists, re-check the effective config with nginx -T and confirm which location block matches the upload path. A common mistake is editing a location block that doesn't actually handle the request.
Prevent recurrence: audit all client_max_body_size directives and use a sane inheritance pattern
Search all nginx config files for client_max_body_size to find conflicting levels.
Linux:
grep -R 'client_max_body_size' /etc/nginx/
Windows, from PowerShell:
Get-ChildItem C:\nginx\conf -Recurse -Filter *.conf | Select-String 'client_max_body_size'
Decide on a global default by setting client_max_body_size in the http block so all sites start from a known limit. Then override only in specific server or location blocks that need a smaller limit—for example, a login form may need only 1m, while an upload endpoint may need 100m. For upload-heavy endpoints, explicitly set client_max_body_size in the location block that handles the upload to the required maximum.
Keep your nginx configs in version control and run nginx -t in a CI pipeline or pre-commit hook before deploying changes. Document the inheritance rule in team runbooks: location overrides server, server overrides http. A small client_max_body_size in a location block can silently reintroduce a 413 even when the rest of the site allows large uploads.
