HTTP 413 Request Entity Too Large in nginx

What the message looks like

2026/10/23 11:20:13 [error] 1234#1234: *3456 client intended to send too large body: 104857600 bytes, client: 198.51.100.7, server: cloud.beispiel.de, request: "PUT /remote.php/dav/files/anna/video.mp4 HTTP/2.0"

Common causes

• client_max_body_size is not set; the nginx default is 1 MB.
• The directive is in the wrong context or in a file that is not included.
• A second proxy in front (load balancer, Docker proxy, Cloudflare with 100 MB on the free plan) has its own limit.
• PHP limits upload_max_filesize and post_max_size are too small (usually an application error rather than 413).

Check

1. Find the effective value in the loaded config
   nginx -T 2>/dev/null | grep -n client_max_body_sizeCopy
2. Find 413 cases in the log
   grep 'too large body' /var/log/nginx/error.log | tail -n 10Copy
3. Check the PHP-FPM limits (not the CLI ones)
   grep -rE 'upload_max_filesize|post_max_size' /etc/php/8.3/fpm/Copy
4. Test an upload directly
   curl -s -o /dev/null -w '%{http_code}\n' -X PUT --data-binary @test-200M.bin https://cloud.example.com/upload-testCopy

Fix

• Set client_max_body_size 10G; in the right server or location block (0 disables the check).
• Test and reload: nginx -t && systemctl reload nginx.
• Raise the same limit on every proxy in front.
• Adjust upload_max_filesize and post_max_size in PHP-FPM, then systemctl reload php8.3-fpm.
• With Nextcloud, rely on chunked uploads so single requests stay small.

FAQ

Why doesn't changing php.ini help?

Because the 413 comes from nginx before PHP ever sees the request. Also, PHP-FPM uses a different php.ini than the CLI.

Is client_max_body_size 0 a good idea?

Only behind authentication. On public endpoints it allows arbitrarily large requests and makes simple resource attacks easy.