Nginx 413 Request Entity Too Large: client_max_body_size Fix

When uploading a file to a website, you may get a 413 Request Entity Too Large error. If Nginx is returning the error, the request body is larger than the limit it is configured to accept. The default limit is 1m (1 MiB), so even a small image or document can exceed it.

This guide explains what triggers the 413 error and how to fix it by setting client_max_body_size in the right place, including the extra step PHP applications need.

Quick Reference #

For a printable quick reference, see the Nginx cheatsheet .

What Causes the 413 Error #

Nginx limits the size of a request body with the client_max_body_size directive . When a client sends a body larger than this value, Nginx returns a 413 Request Entity Too Large response. The application does not get to process the upload.

The limit applies to the entire request body, including uploaded files, form fields, and multipart boundaries. If you want to accept a 50 MiB file, leave some room above that size for the rest of the form.

A CDN, another reverse proxy, or the application itself can also return a 413 response. If changing the Nginx limit does not help, check which server is rejecting the request before raising it further.

To confirm that Nginx rejected the upload, check its error log:

sudo tail /var/log/nginx/error.log

A request body over the limit produces an entry like this:

2026/10/19 17:34:29 [error] 7443#7443: *1 client intended to send too large body: 2097459 bytes, client: ::1, server: _, request: "POST /up.php HTTP/1.1", host: "localhost"

The byte count is the size of the rejected body, which tells you how high to set the new limit. If the log has no such entry, another layer returned the 413 response.

Set client_max_body_size #

The fix is to set client_max_body_size to a value large enough for your uploads. The directive is valid in three contexts, and where you put it decides how widely the new limit applies:

• http - applies to every site served by this Nginx instance.
• server - applies to a single site (one server block).
• location - applies only to a specific path, such as an upload endpoint.

Choose the narrowest context that covers your uploads. For a single website, you can add the directive to its existing server block. On Ubuntu and Debian, site configuration files are commonly stored under /etc/nginx/sites-available/. Open the enabled configuration for your site, replacing example.com with its filename:

sudo nano /etc/nginx/sites-available/example.com

Other installations often use /etc/nginx/conf.d/. If you are not sure which file handles the site, run sudo nginx -T to print the configuration and its included files.

Add the following line inside the existing server block to allow request bodies up to 60 MiB:

client_max_body_size 60M;

Keep the other directives in your server block. If only an upload endpoint needs a higher limit, put the directive in the existing location block that handles it instead. For example, an endpoint already proxied to an application on port 8080 could use:

location /upload {
    client_max_body_size 200M;
    proxy_pass http://127.0.0.1:8080;
}

This overrides the server-level limit for requests handled by that location. Keep your existing proxy or PHP handler when adding the directive; you do not need a new location block just to change the limit.

The value accepts k or K, m or M, and g or G suffixes, using powers of 1024. Setting it to 0 disables this size check. Avoid doing that on a public server, because large requests can consume memory, temporary disk space, and application resources.

To raise the limit for every site at once, put the directive in the http block of the main configuration file instead:

http {
    client_max_body_size 60M;
    # Keep the existing configuration here.
}

Test and Reload #

Always test the configuration before applying it:

sudo nginx -t

If the configuration is valid, you will see output similar to this:

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

Both messages confirm that the test passed. If Nginx reports an error, fix the indicated file and line before continuing.

Reload Nginx so the new limit takes effect without dropping active connections:

sudo systemctl reload nginx

Retry the upload that failed. If it still returns a 413 response, work through the checks in the Troubleshooting section below.

Match the PHP Upload Limits #

If your site runs PHP, for example WordPress or Laravel behind PHP-FPM, raising client_max_body_size alone may not be enough. PHP enforces its own upload limits, and a file that clears Nginx can still be rejected by PHP. The default php.ini on Ubuntu 26.04 sets upload_max_filesize = 2M and post_max_size = 8M, so any file over 2 MiB still fails at PHP after you raise the Nginx limit.

Edit the php.ini file used by PHP-FPM. On Ubuntu and Debian with PHP 8.5, the path is:

sudo nano /etc/php/8.5/fpm/php.ini

For uploads of a single file up to 50 MiB, use the following values with the 60M Nginx limit shown earlier:

upload_max_filesize = 50M
post_max_size = 60M

upload_max_filesize limits each file, while post_max_size limits the whole POST body. As the PHP documentation explains, post_max_size must be larger than upload_max_filesize. If your form accepts multiple files, allow room for their combined size and the other form data in both the PHP POST limit and the Nginx request limit.

Restart PHP-FPM to load the new values:

sudo systemctl restart php8.5-fpm

Adjust the path and service name to the PHP version serving your site. Editing the CLI version of php.ini does not change PHP-FPM settings. See our guide on installing PHP on Ubuntu for more on the PHP-FPM service and configuration.

Troubleshooting #

413 error persists after raising the limit
The directive may be in a configuration file or block that does not handle the request. Run sudo nginx -T and check the server name, listening port, and matching location. Make sure you edited the HTTPS server block if the upload uses HTTPS. Test and reload Nginx after correcting the configuration.

PHP reports an upload error or receives no file
Check the PHP-FPM upload limits and the application logs. Exceeding upload_max_filesize produces a PHP upload error; exceeding post_max_size leaves $_POST and $_FILES empty. These conditions do not automatically produce a 413 or 500 HTTP response, so check the cause before changing the limits. When the body exceeds post_max_size, the Nginx error log also shows a POST Content-Length of ... exceeds the limit of ... warning from PHP.

A reverse-proxied app still rejects the file
The upstream application may have its own body-size limit. If Nginx accepts the request, check the application’s configuration and logs for the upload error.

The site is behind a CDN or another proxy
The request may be rejected before it reaches your Nginx server. Check that service’s upload limit as well. For example, Cloudflare enforces its own upload limits , which a change to client_max_body_size cannot override.

Change had no effect on one site only
A location block may set a smaller client_max_body_size that overrides the server-level value. The selected location inherits the enclosing limit unless it defines its own. The Nginx location block guide explains how Nginx picks which block applies.

Conclusion #

Keep the request limit a little above the largest upload your site needs, including the rest of the form data. If your application sits behind several servers, check the limits at each layer; our Nginx reverse proxy guide explains how requests pass from Nginx to an upstream application.

About the authors

Dejan Panovski

Dejan Panovski is the founder of Linuxize, an RHCSA-certified Linux system administrator and DevOps engineer based in Skopje, Macedonia. Author of 1000+ Linux tutorials with 20+ years of experience turning complex Linux tasks into clear, reliable guides.

View author page