How to Fix the Nginx “413 Request Entity Too Large” Error

You try to upload a file through nginx, such as a WordPress media item, a plugin or theme zip, or an API payload, and the server answers with 413 Request Entity Too Large. The request body is bigger than the limit nginx is configured to accept. This DevAnswers guide raises that limit in the right place, matches your PHP upload settings, and rules out a reverse proxy or CDN when the change appears to do nothing.

The Fix: Raise client_max_body_size #

The directive that controls this is client_max_body_size. Its default is 1m (1 MB), and any request body larger than the configured value is rejected with the 413 error. You need shell access and sudo privileges. Open the main nginx configuration file and raise the limit inside the http block:

sudo nano /etc/nginx/nginx.conf

http {
    # DevAnswers.net: allow uploads up to 128 MB
    client_max_body_size 128M;
    # ... your other http directives ...
}

Save and exit (press CTRL + X, press Y, then press ENTER)

Before reloading, test the configuration so a typo cannot take the site down. nginx -t checks the configuration for correct syntax and confirms it can open the files it references:

sudo nginx -t

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

Now reload nginx. A reload re-reads the configuration by signalling the master process, which starts new worker processes and lets the old ones finish their in-flight requests, so active connections are not dropped:

sudo systemctl reload nginx

Retry the upload. If nginx was the only limit in the way, the 413 is gone.

http, server, or location: Where to Put the Directive #

client_max_body_size is valid in the http, server, and location contexts, and the more specific context wins. Put it in http for a server-wide policy, in a server block to apply it to one site, or in a location block to allow large bodies only on a specific path such as an upload endpoint:

server {
    server_name devanswers.test;

    location /upload {
        client_max_body_size 128M;
    }
}

On Debian and Ubuntu, nginx enables each site by symlinking its config from /etc/nginx/sites-available/ into /etc/nginx/sites-enabled/, which the main /etc/nginx/nginx.conf includes (alongside /etc/nginx/conf.d/*.conf). If your site defines its own server block there, set the directive in that block to override the http-wide default, and remember a location block can still override the server-level value. Setting the size to 0 disables body-size checking entirely, which removes the safeguard and is not recommended in production.

Match Your PHP Upload Limits #

If the backend is a PHP application such as WordPress, raising the nginx limit is only half the job. PHP enforces its own caps, so nginx can accept a large upload and PHP can still reject it. Edit php.ini for your version and SAPI (the FPM path looks like /etc/php/8.3/fpm/php.ini; see how to find and edit php.ini if you are unsure which file is loaded):

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

upload_max_filesize = 100M
post_max_size = 128M

Save and exit (press CTRL + X, press Y, then press ENTER)

upload_max_filesize caps a single file, while post_max_size caps the entire POST body. To upload large files, post_max_size must be larger than upload_max_filesize (allow headroom for multiple files and form fields in one request). If the POST data exceeds post_max_size, PHP empties the $_POST and $_FILES superglobals, so the upload silently arrives as nothing. Save the file and restart PHP-FPM so the new values take effect:

# Find your PHP-FPM service name (the version is in the unit name)
systemctl list-units 'php*-fpm.service'

# Restart it: substitute your version (php8.2-fpm, php8.4-fpm, etc.)
sudo systemctl restart php8.3-fpm

Still Getting 413? Check the Proxy or CDN Layer #

The most common reason client_max_body_size appears to have no effect is that something in front of your application server is returning the 413 first. When nginx runs as a reverse proxy, it can reject an oversized request before it ever reaches the backend, so the limit has to be raised on the proxy layer too, not only on the upstream service it forwards to. Mismatched limits across the two layers are the source of most lingering 413 confusion. Set client_max_body_size in the server block that terminates the public connection, then reload and test there as well.

A CDN can impose its own cap that your origin configuration cannot override:

Why Nginx Limits Request Size #

The 1 MB default is a deliberate safeguard, not an oversight. nginx imposes it to limit resource use and help mitigate some denial-of-service attacks that send excessively large request bodies. When a body is larger than nginx can hold in its in-memory buffer, nginx writes the overflow to a temporary file on disk, so unbounded uploads translate directly into disk and memory pressure. Raise the limit to what your application genuinely needs rather than removing it, which is why client_max_body_size 0 is discouraged in production.

Conclusion #

To clear a 413, raise client_max_body_size in the correct nginx context, match upload_max_filesize and post_max_size in PHP, and confirm no reverse proxy or CDN in front is capping the request first. Validate every change with nginx -t before reloading, then retry the upload to confirm the limit now matches what your application needs.