How to Fix Nginx 413 ‘Request Entity Too Large’ with PHP-FPM

0 1 9 minutes read

How to Fix Nginx 413 'Request Entity Too Large' with PHP-FPM

By Connect Digital World | Server Fixes Made Easy | Last updated: October 2026

You try to upload a big theme, a video or a PDF. You click upload, wait a bit, and then your browser shows an ugly message:

413 Request Entity Too Large
nginx

You search online and every guide tells you to edit php.ini. You do it, restart PHP, and the error is still there. Why? Because Nginx rejects the file before PHP even sees it. Here is the exact fix, first, and then the full explanation in simple words.

The Quick Fix: Change Nginx and PHP Together

You need to raise the limit in two places, and both must agree.

1. Nginx: Add client_max_body_size

Open your Nginx site config (for example /etc/nginx/sites-available/yourdomain.conf) and add this line inside the server { } block:

server {
    listen 80;
    server_name yourdomain.com;

    client_max_body_size 64M;

    # ... the rest of your config
}

2. PHP: Change php.ini

Open the PHP-FPM php.ini (for example /etc/php/8.3/fpm/php.ini) and set:

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300

3. Test and Reload

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl restart php8.3-fpm

Try your upload again. In most cases, the 413 error is gone. If you want to understand why this works, how to check that the new limits are really active, and what to do if it still fails, keep reading.

What Does “413 Request Entity Too Large” Mean?

The number 413 is an HTTP status code. It means the request you sent was too big for the server to accept. The “entity” is the body of your request, which is the file you are uploading.

Imagine you try to post a giant parcel through a small letterbox at the post office. The clerk at the door says, “Sorry, too big,” before the parcel ever reaches the sorting room. In your server:

Nginx is the clerk at the door.
PHP-FPM is the sorting room.
Your uploaded file is the parcel.

If the clerk rejects the parcel, the sorting room never knows it existed. That is why changing only php.ini does nothing when the 413 comes from Nginx.

How the Upload Travels (Why You Need Two Settings)

Your browser sends the file to Nginx.
Nginx checks the size against client_max_body_size. If it is too big, you get 413. The file never goes further.
If it passes, Nginx hands the request to PHP-FPM.
PHP checks post_max_size and upload_max_filesize. If it is too big, PHP quietly drops the file or WordPress shows an error like “exceeds the maximum upload size for this site”.
If everything passes, your script saves the file.

So the smallest limit in the chain wins.

The Default Limits (Why Uploads Fail Out of the Box)

Setting	Where	Default	What it controls
`client_max_body_size`	Nginx	1 MB	Biggest request body Nginx accepts
`upload_max_filesize`	php.ini	2 MB	Biggest single file PHP accepts
`post_max_size`	php.ini	8 MB	Biggest total POST data PHP accepts
`memory_limit`	php.ini	128 MB	Memory one PHP script may use
`max_execution_time`	php.ini	30 seconds	How long a script may run

These are the typical built-in defaults, and your host or control panel may have changed them. Nginx’s default of just 1 MB is why even a medium photo can be refused on a fresh server.

The Golden Rule: Keep the Numbers in Order

For uploads to work smoothly, use this order:

upload_max_filesize  <=  post_max_size  <=  client_max_body_size

Why?

A form upload includes extra data besides the file, so post_max_size must be equal to or bigger than upload_max_filesize.
client_max_body_size in Nginx must be equal to or bigger than the whole request, so it should not be smaller than post_max_size.

A neat way to do this is to keep the same value, like 64M, in all three places. Or make Nginx slightly higher (for example 70M) to leave room for the extra bytes in the request.

Step-by-Step Guide

Step 1: Find Your Nginx Configuration File

The common places are:

/etc/nginx/nginx.conf: the main file.
/etc/nginx/sites-available/yourdomain.conf: one file per site (Ubuntu and Debian), linked into sites-enabled.
/etc/nginx/conf.d/yourdomain.conf: used on many other systems.

To see the final merged configuration that Nginx is really using, run:

sudo nginx -T | grep -n client_max_body_size

This prints every client_max_body_size line in your whole setup, so you can see if a different value is overriding yours.

Step 2: Set client_max_body_size

You can place this directive in three places, each with a different reach:

http block (in nginx.conf): applies to every site on the server.
server block: applies to one website. This is the usual choice.
location block: applies only to one URL path. This is the safest choice for big uploads.

Example for a whole site:

server {
    server_name yourdomain.com;
    client_max_body_size 64M;
    ...
}

Example for one path only, for instance a special upload page:

location /upload/ {
    client_max_body_size 512M;
    try_files $uri $uri/ /index.php?$args;
}

A safety tip: Setting client_max_body_size 0; turns off the check completely, which lets anyone send huge files to your server. Avoid it on public sites. Choose a sensible number instead.

Step 3: Find Your PHP-FPM php.ini

PHP often has more than one php.ini: one for the command line (CLI) and one for PHP-FPM, which serves your website. You must edit the FPM one. On Ubuntu and Debian with PHP 8.3, it is usually:

/etc/php/8.3/fpm/php.ini

Replace 8.3 with your PHP version. On other systems, it may be something like /etc/php.ini or /etc/php-fpm.d/. The easiest way to be sure is to check from WordPress or a test script, as shown in Step 6.

Step 4: Edit the PHP Settings

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300
max_input_time = 300

upload_max_filesize and post_max_size are the key ones.
memory_limit should be bigger than post_max_size, because some scripts load data into memory.
max_execution_time and max_input_time give slow uploads on slow connections more time to finish.

Step 5: Check the Syntax, Then Reload

Always test Nginx’s configuration before reloading, so a typo does not take your site offline:

sudo nginx -t

If you see “syntax is ok” and “test is successful”, reload:

sudo systemctl reload nginx
sudo systemctl restart php8.3-fpm

Remember: PHP changes do not apply until PHP-FPM restarts, and Nginx changes do not apply until Nginx reloads.

Step 6: Confirm the New Limits Are Active

Do not guess. Check:

In WordPress: Go to Media → Add New. It shows “Maximum upload file size”. Or go to Tools → Site Health → Info → Media Handling, which lists upload_max_filesize and post_max_size.
In a test script: Create a temporary file with <?php phpinfo();, open it in your browser, look for the two values, and delete the file right after, because it shows private server details.

Warning: running php -i in the terminal shows the CLI settings, not the web (FPM) settings. They can be different, so do not trust that command for this.

Real-World Variations

If You Use WordPress Multisite

Multisite has its own upload limit setting. Go to Network Admin → Settings → Network Settings and check Max upload file size. It must also be high enough.

If You Use a Control Panel (cPanel, Plesk, RunCloud, CloudPanel)

Many panels overwrite manual changes, or give you a place to set Nginx and PHP options in the dashboard. Look for “PHP settings” and “Nginx directives”. Use the panel’s own fields so your changes do not get erased the next time the panel rebuilds its config.

If You Cannot Edit php.ini (Shared Hosting)

Some hosts let you use a .user.ini file in your website’s main folder with PHP-FPM:

upload_max_filesize = 64M
post_max_size = 64M

PHP-FPM reads .user.ini files, but it caches them for a few minutes, so changes may not show up right away. Also note that .htaccess with php_value lines does not work with Nginx, because Nginx does not read .htaccess files at all. If you cannot change Nginx yourself, ask your host’s support to raise client_max_body_size.

If You Use Docker

Put the Nginx directive in the config file that you mount into your Nginx container, and put the PHP settings in a custom .ini file mounted into the PHP-FPM container. Then restart both containers.

If You Use a Different PHP Pool Setting

PHP-FPM pools can override some PHP settings with lines like php_admin_value[upload_max_filesize] = 16M in the pool file (for example /etc/php/8.3/fpm/pool.d/www.conf). If your changes in php.ini seem ignored, check that file, because pool settings win.

Still Getting 413? Check the Other Layers

Sometimes there is another “clerk” before Nginx. Check each layer between the visitor and your PHP code:

A second Nginx. If one Nginx proxies to another, each needs its own client_max_body_size.
A load balancer or Ingress. Kubernetes Ingress and some load balancers have their own body-size settings.
Cloudflare. Cloudflare limits upload size depending on your plan. Free plans are often limited to around 100 MB per request, so very large files may need another upload method. Check Cloudflare’s current documentation.
A security plugin or WAF. Some block large requests.
Apache behind Nginx. If Nginx forwards to Apache, Apache has its own LimitRequestBody setting.

How to Tell Who Sent the 413

Look at the error page. If it says nginx, the clerk at the door said no. If your PHP application shows its own message, such as WordPress’s “exceeds the maximum upload size”, PHP made the decision. Also check the Nginx error log:

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

A line such as “client intended to send too large body” confirms Nginx rejected the upload.

Security: How High Should You Go?

A big upload limit helps real users, but it also gives attackers more room to waste your server’s bandwidth and disk space. Smart tips:

Choose a limit that fits your real needs, for example 64M or 128M, not 10G.
If only admins upload big files, set the high limit only for the admin upload path.
Restrict allowed file types in your application.
Keep PHP and WordPress updated.
For huge files, use a proper large-file method, such as direct-to-storage uploads or chunked uploads, instead of pushing everything through PHP.

Copy-and-Paste Cheat Sheet

# Nginx (server block)
client_max_body_size 64M;

# PHP-FPM php.ini
upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 256M
max_execution_time = 300

# Test and apply
sudo nginx -t
sudo systemctl reload nginx
sudo systemctl restart php8.3-fpm

Simple Word List (Glossary)

413: An error code meaning the request is too large.
Nginx: A popular web server that receives requests from browsers.
PHP-FPM: A process manager that runs PHP code for Nginx.
php.ini: The main settings file for PHP.
Request body: The data sent with a request, such as an uploaded file.
Directive: One setting line in a config file.
Reverse proxy: A server that forwards requests to another server.
Reload: Telling a service to read its new settings without a full restart.
CLI: Command line interface, where you type commands.
WAF: A web application firewall that blocks suspicious traffic.

Frequently Asked Questions (FAQ)

What causes 413 Request Entity Too Large in Nginx?

The uploaded file is bigger than Nginx’s client_max_body_size limit, which is 1 MB by default.

Why does changing php.ini not fix the 413 error?

Because Nginx rejects the request before it reaches PHP. You must raise client_max_body_size in Nginx as well.

Which settings do I need to change in PHP?

Change upload_max_filesize and post_max_size. It also helps to raise memory_limit and the time limits.

Where do I put client_max_body_size?

Inside the http, server or location block. The server block is the usual place for one website.

Do I need to restart Nginx or PHP-FPM?

Reload Nginx after editing its config, and restart PHP-FPM after changing php.ini. Test with nginx -t first.

Why does WordPress still show the old upload limit?

You may have edited the wrong php.ini (CLI instead of FPM), not restarted PHP-FPM, or a pool setting or multisite setting is overriding it.

Does .htaccess work for Nginx upload limits?

No. Nginx does not read .htaccess files. Use the Nginx config, or ask your host.

Is it safe to set client_max_body_size to 0?

It disables the limit, which is risky on public sites. Pick a reasonable size instead.

Can Cloudflare cause 413 errors?

Yes. Cloudflare has upload size limits depending on your plan, so check them if the error continues after fixing Nginx and PHP.

Final Thoughts

The 413 error is not a mystery. It simply means a size limit stopped your file at the door. The big lesson is to remember two gatekeepers: Nginx, with client_max_body_size, and PHP, with upload_max_filesize and post_max_size. Set them to matching values, test the config, reload the services and confirm the new limits in WordPress.

If you still see the error, check the other layers, like Cloudflare or a second proxy, and read the Nginx error log, which usually tells you exactly who said no.

Did this fix your upload problem? Tell us in the comments which step solved it. For more easy server and WordPress guides, keep following Connect Digital World.

Sources and further reading: The official Nginx documentation for client_max_body_size, the PHP manual for file upload and core configuration settings, WordPress documentation, and Cloudflare’s upload limit documentation. Always check the current documentation for your version.