HTTP 413 Request Entity Too Large: fix per nginx

Come appare il messaggio

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"

Cause frequenti

client_max_body_size non è impostato; il default di nginx è 1 MB.
La direttiva è nel contesto sbagliato o in un file che non viene incluso.
Un secondo proxy davanti (load balancer, proxy Docker, Cloudflare con 100 MB nel piano free) ha un suo limite.
I limiti PHP upload_max_filesize e post_max_size sono troppo bassi (di solito errore dell'app più che 413).

Verifica

Trova il valore effettivo nella configurazione caricata
nginx -T 2>/dev/null | grep -n client_max_body_size
Trova i casi 413 nel log
grep 'too large body' /var/log/nginx/error.log | tail -n 10
Controlla i limiti di PHP-FPM (non quelli della CLI)
grep -rE 'upload_max_filesize|post_max_size' /etc/php/8.3/fpm/
Prova un upload diretto
curl -s -o /dev/null -w '%{http_code}\n' -X PUT --data-binary @test-200M.bin https://cloud.example.com/upload-test

Soluzione

Imposta client_max_body_size 10G; nel blocco server o location giusto (0 disattiva il controllo).
Testa e ricarica: nginx -t && systemctl reload nginx.
Alza lo stesso limite su tutti i proxy a monte.
Adegua upload_max_filesize e post_max_size in PHP-FPM, poi systemctl reload php8.3-fpm.
Con Nextcloud sfrutta l'upload a chunk, così le singole richieste restano piccole.

Domande frequenti

Perché modificare php.ini non serve?

Perché il 413 arriva da nginx prima che PHP veda la richiesta. In più PHP-FPM usa un php.ini diverso da quello della CLI.

client_max_body_size 0 è una buona idea?

Solo dietro autenticazione. Su endpoint pubblici permette richieste enormi e rende facili gli attacchi alle risorse.

HTTP 413 Request Entity Too Large su nginx