HTTP 413 Request Entity Too Large: nginx-Fix

So sieht die Meldung aus

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"

Häufige Ursachen

client_max_body_size ist nicht gesetzt; der Standard in nginx ist 1 MB.
Der Wert steht im falschen Kontext oder in einer Datei, die nicht eingebunden wird.
Ein zweiter Proxy davor (Load Balancer, Docker-Proxy, Cloudflare mit 100 MB im Free-Plan) hat ein eigenes Limit.
PHP-Limits upload_max_filesize und post_max_size sind zu klein (führt meist zu Anwendungsfehlern statt 413).

Prüfen

Effektiven Wert in der geladenen Konfiguration suchen
nginx -T 2>/dev/null | grep -n client_max_body_size
413-Fälle im Log finden
grep 'too large body' /var/log/nginx/error.log | tail -n 10
PHP-Limits der FPM-Konfiguration prüfen (nicht der CLI)
grep -rE 'upload_max_filesize|post_max_size' /etc/php/8.3/fpm/
Upload gezielt testen
curl -s -o /dev/null -w '%{http_code}\n' -X PUT --data-binary @test-200M.bin https://cloud.beispiel.de/upload-test

Lösung

client_max_body_size 10G; im passenden server- oder location-Block setzen (0 deaktiviert die Prüfung).
Konfiguration testen und neu laden: nginx -t && systemctl reload nginx.
Das gleiche Limit auf allen vorgeschalteten Proxies anheben.
In PHP-FPM upload_max_filesize und post_max_size anpassen, danach systemctl reload php8.3-fpm.
Bei Nextcloud den Chunked Upload nutzen, damit einzelne Requests klein bleiben.

Häufige Fragen

Warum hilft die Änderung in php.ini nicht?

Weil der 413 von nginx kommt, bevor PHP die Anfrage sieht. Außerdem nutzt PHP-FPM eine andere php.ini als die CLI.

Ist client_max_body_size 0 eine gute Idee?

Nur hinter Authentifizierung. Auf öffentlichen Endpunkten erlaubt es beliebig große Requests und damit einfache Ressourcenangriffe.

HTTP 413 Request Entity Too Large bei nginx