Fix Nginx 413 Request Entity Too Large (7 steps)

Quick answer for pros: Open your Nginx site config (usually /etc/nginx/sites-available/default), add client_max_body_size 50M; inside the server block, reload Nginx. Then check PHP's upload_max_filesize and post_max_size in php.ini. That's it.

Why you get a 413 error

The HTTP 413 status code means 'Request Entity Too Large.' What's actually happening here is the server (Nginx, Apache, or your reverse proxy) checks the size of the incoming request body before sending it to your app. If that body is bigger than what the server allows, it just drops the connection and sends back a 413. No processing, no error log entry – just rejection.

The default client_max_body_size in Nginx is 1 megabyte. That's tiny. Most PHP apps like WordPress, Nextcloud, or custom file upload forms need at least 10MB or 50MB. The fix isn't complicated, but you have to hit three places: Nginx, PHP, and sometimes your application itself.

Step-by-step fix

Find your Nginx config – Look in /etc/nginx/nginx.conf or /etc/nginx/sites-available/. If you have a site-specific config, edit that one. If not, edit the main config.
Add or change client_max_body_size – Inside the server block (not location), add this line:
```
client_max_body_size 50M;
```
The value can be 10M, 100M, whatever. Some people put it inside a location block – don't. It only affects that path. Put it in the server block so it applies to all uploads.
Reload Nginx – Run:
```
sudo nginx -t  # test config first
sudo systemctl reload nginx
```
The -t test saves you from breaking your site. If it fails, you have a syntax error.
Check PHP limits – Open your php.ini (find it with php --ini or look in /etc/php/). Change these two values:
```
upload_max_filesize = 50M
post_max_size = 55M
```
post_max_size must be bigger than upload_max_filesize because it covers the entire POST body, including form fields. If you upload a 50MB file plus form data, post needs room.
Restart PHP-FPM – Run:
```
sudo systemctl restart php8.1-fpm
```
Replace 8.1 with your PHP version.
Clear caches – If you use a caching proxy like Cloudflare or Varnish, purge the cache. They might store the 413 response.
Test – Upload a file that's close to your new limit. The error should be gone.

Alternative fixes if the main one fails

If you still get 413 after doing all that, here's what might be wrong:

Symptom	Likely cause	Fix
413 only on some paths (like /api/upload)	`client_max_body_size` set in a `location` block elsewhere	Search for any other `client_max_body_size` in your config and remove or bump it.
413 but Nginx logs show 200	Reverse proxy (like Apache in front of Nginx) blocking it	Check Apache's `LimitRequestBody` directive in `httpd.conf` or `.htaccess`.
413 with 'Request body too large' in log	PHP-FPM's `request_terminate_timeout` is too short	Set `request_terminate_timeout = 300` in `www.conf`. Big uploads take time.
413 only in HTTPS	Your load balancer or reverse proxy (like HAProxy) has its own limit	Check `tune.maxrewrite` and `timeout http-request` in HAProxy.

Another sneaky one: if you're using Kubernetes or Docker, the ingress controller (like Traefik or Nginx Ingress) has its own client_max_body_size default. You need to set it via annotation or ConfigMap there.

Prevention tip

The reason step 3 works is because Nginx checks the body size before it passes the request to PHP. If you only bump PHP limits but not Nginx, the error happens at the door. Always check Nginx first.

Prevent this in the future: Add client_max_body_size to your server block right from the start when you set up a new site. I set it to 10M by default, then bump it only for specific upload endpoints. Also monitor your upload logs – if you see 413 errors, you catch it early.

One more thing: don't set client_max_body_size to 0 (unlimited) unless you control who can upload. Spammers love that.