Nginx 413 Request Entity Too Large: How to Fix It

Nginx 413 Request Entity Too Large means nginx refused the request because its body is larger than client_max_body_size. The default is 1m. To fix it, set client_max_body_size to a larger value in the http, server or location block, check the configuration with nginx -t, reload nginx, and test with a file one byte under and one byte over the new limit.

The nginx documentation gives the syntax, default and contexts:

Syntax:  client_max_body_size size;
Default: client_max_body_size 1m;
Context: http, server, location

It also says that if the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned to the client, and that setting size to 0 disables checking of the request body size.

Nginx 413 Request Entity Too Large: confirm nginx sent it

Several components return a 413, and the fix depends on which one it was. To confirm it was nginx, look at the response and at nginx’s own error log. Sending a body one byte over the default limit to an nginx 1.30.5 instance returned:

HTTP/1.1 413 Request Entity Too Large
Server: nginx/1.30.5
Content-Type: text/html
Content-Length: 183
Connection: close

<html>
<head><title>413 Request Entity Too Large</title></head>
<body>
<center><h1>413 Request Entity Too Large</h1></center>
<hr><center>nginx/1.30.5</center>
</body>
</html>

The Server header and the body both name nginx. A deployment can change or remove that header, and a page behind another proxy may carry that proxy’s header instead. The definitive evidence is nginx’s error log, the file named by your error_log directive. We got:

[error] 11960#5440: *3 client intended to send too large body: 1048577 bytes, client: 127.0.0.1, server: , request: "POST / HTTP/1.1", host: "127.0.0.1:8080"

The log line states the number of bytes the client announced, which is useful: it is the full request body size, not just the file. If there is no such line, the 413 came from somewhere else (see the traps below).

Set client_max_body_size in the right place

The directive is valid in three contexts and the most specific one wins. We tested this with one server and three limits:

http {
    client_max_body_size 1m;                     # default for everything
    server {
        listen 127.0.0.1:8080;
        location / { return 200 "ok\n"; }
        location /upload/ {
            client_max_body_size 10000000;       # decimal 10 MB for this path
            return 200 "ok\n";
        }
        location /anysize/ {
            client_max_body_size 0;              # no check
            return 200 "ok\n";
        }
    }
}

Raw POST bodies of five sizes, status codes returned:

Path	1,048,576	1,048,577	10,000,000	10,000,001	10,485,760
/ (1m)	200	413	413	413	413
/upload/ (10000000)	200	200	200	413	413
/anysize/ (0)	200	200	200	200	200

Three things to take from it. First, 1m means 1,048,576 bytes: that exact size passed and one byte more failed. Second, a location block overrides the http value for its own requests. Third, 0 accepts everything, which is a way to turn off a protection you may need. Use 0 only if something in front of nginx enforces a limit, and prefer a large explicit number such as 100m.

Put the limit on the narrowest block that needs it, usually the location that handles uploads, so the rest of the site keeps the strict default. Sizes can be written with an m suffix, as in 10m, or as a plain number of bytes, as in the 10000000 above.

Test the configuration, then reload

Check the syntax before you apply it. This is the real output on Windows:

nginx: the configuration file C:\...\conf/nginx.conf syntax is ok
nginx: configuration file C:\...\conf/nginx.conf test is successful

On Linux the command is nginx -t (with sudo if needed). To apply the change, send nginx the reload signal: nginx -s reload, or the reload command of your service manager. The nginx control documentation says the master process checks the new configuration’s syntax first, and that if applying it fails it rolls back and keeps working with the old one. We ran nginx -s reload on Windows and the new limit was active on the next request. We did not run any Linux service commands here.

After the reload, the same files gave:

1048577 bytes  -> 200
10485760 bytes -> 200   (limit 10m)
10485761 bytes -> 413

Test file uploads, not only raw bodies

A browser upload is multipart/form-data, which adds a few hundred bytes around the file. In our capture with curl, the overhead was 213 to 256 bytes depending on the filename. So with the default 1m, a form upload of a file of exactly 1,048,576 bytes returned 413, and so did a 1,048,575-byte file. With a 10m limit, a form upload of a 10,485,760-byte file also returned 413.

When you choose a limit, add headroom for that overhead. If the product promise is “files up to 10 MB”, set the limit above 10 MiB, for example 11m, and enforce the exact file size in the application. The test file upload limits guide explains the method and has a script.

To reproduce it yourself you need files of exact sizes. The generator at Dummy PDF file makes valid PDFs at any byte count (unit B), and the Dummy ZIP file page does the same for archives, which matters if the endpoint checks the file type before it checks the size.

Common traps

• Another layer answers first. The Cloudflare troubleshooting page lists a maximum upload size of 100 MB for the Free and Pro plans, 200 MB for Business, and up to 5 GB for Enterprise, and says it can be adjusted on the zone’s Network page. A CDN 413 has no nginx error log line. Test the origin directly to separate the two.
• Several nginx instances in a chain. A load balancer, an ingress and an application container can each run nginx with its own default 1m. Raising the limit on one leaves the others.
• Kubernetes ingress-nginx. Its documentation says the limit is set by the nginx.ingress.kubernetes.io/proxy-body-size annotation on the Ingress, or globally with proxy-body-size in the ConfigMap, for example 8m. We did not run Kubernetes for this guide.
• The application’s own limit. After nginx accepts the body, the runtime may reject it. PHP, for example, has its own two limits: see PHP upload_max_filesize and post_max_size.
• Browsers hide the error. The nginx documentation warns that browsers cannot correctly display this error. A failing upload in a browser can look like a dropped connection, so read the status in the developer tools network tab or test with curl.
• Units. 10m is 10 MiB. A vendor limit of “10 MB” may mean 10,000,000. See KB vs KiB.

Try it

Reproduce the failure and the fix with byte-exact files: a Dummy CSV file one byte under your limit should pass and one byte over should return 413. The Dummy 10 MB PDF file page has a ready 10 MB PDF. Files are built in your browser and nothing is uploaded.

Sources

Accessed 30 September 2026.

• nginx, client_max_body_size: https://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
• nginx, controlling nginx (reload and signals): https://nginx.org/en/docs/control.html
• Cloudflare, Error 413: https://developers.cloudflare.com/support/troubleshooting/http-status-codes/4xx-client-error/error-413/
• ingress-nginx annotations, custom max body size: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/
• RFC 9110, 413 Content Too Large: https://www.rfc-editor.org/rfc/rfc9110#section-15.5.14
• All request and response output: nginx 1.30.5 and curl 8.21.0 on Windows 11, 29 September 2026.