Increase the upload size limit in Nginx

Set client_max_body_size for the right endpoint, allow multipart overhead, and test Nginx and application limits together.

Best practices
Illustration of server operations and request logs

Set client_max_body_size in the configuration that handles the upload. Nginx's built-in default is 1m (1 MiB). Choose a limit for the complete request body, including multipart overhead, then validate and reload the correct instance.

Locate and edit the loaded configuration

sudo nginx -t
sudo nginx -T

The test reports the main configuration path; the dump includes loaded files. Keep the dump private because it can contain sensitive configuration.

To set a site-wide limit, add this inside the site's existing server block:

client_max_body_size 100m;

Alternatively, set a larger limit only in the existing upload handler:

location /upload {
    client_max_body_size 500m;
    proxy_pass http://127.0.0.1:8080;
}

Keep your actual upstream or application handler. The directive is valid in http, server, and location; a more specific declaration overrides the inherited value. Internal redirects or regex locations can cause a different location to handle the request.

sudo nginx -t && sudo systemctl reload nginx

Use your deployment's reload mechanism if it is not a systemd service.

Distinguish size limits from timeouts

These example settings govern different pauses:

client_body_timeout 120s;
proxy_read_timeout 120s;

The first limits gaps while reading the client body. The second limits gaps while reading the proxied response. For FastCGI, the corresponding upstream setting is fastcgi_read_timeout. None is simply a maximum total upload duration. Change them only if logs identify that timeout as the problem.

Also verify temporary-body disk capacity and concurrent upload behavior. A large body may be buffered to disk before it reaches the application.

Align application and gateway limits

For PHP, upload_max_filesize limits an individual file while post_max_size limits the whole POST body. Allow room above the intended file size for multipart fields. In Express, express.json() controls JSON parsing, not multipart uploads; configure the multipart middleware. In Spring, check both spring.servlet.multipart.max-file-size and spring.servlet.multipart.max-request-size.

Any CDN, load balancer, or API gateway may apply its own limit. The smallest applicable limit determines what reaches the application; a larger Nginx setting cannot override an earlier rejection.

Verify both sides of the boundary

curl -i -F 'file=@bigfile.zip' https://example.com/upload

Use an authorized test endpoint and known files below and above the intended limit. Include multipart overhead in the expectation. A response other than 413 does not by itself prove success: confirm the application stored the expected bytes and check for new timeouts or disk errors.

Match request paths and times in access, error, and application logs. When collecting these with Guance's Nginx integration, validate parsed status and path fields before comparing failures.

FAQ

How large should the limit be?

Base it on the largest supported operation and expected concurrency. 0 removes Nginx's body-size check; use it only with deliberate controls elsewhere.

Why do I still get 413?

Check location overrides, failed reloads, other proxy instances, gateways, and application limits. Response headers alone do not identify the rejecting layer reliably.

What should I do for multi-gigabyte uploads?

Consider resumable uploads or direct object-storage transfers with scoped presigned URLs. Those designs reduce the amount of long-lived upload traffic handled by the web application.

Reference: client body directives.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting