Ein Upload bricht mit 413 ab, weil nginx große Anfragen standardmäßig bei 1 MB kappt. Oft steckt dahinter noch ein zweites Limit in PHP.
Aufwand:
ca. 15 Min.
Gilt für:
nginx (alle aktuellen Versionen)
Das Symptom
Ein Upload – ein Bild, ein PDF, ein Formular mit Anhang – bricht ab, und im Log des
Webservers steht:
client intended to send too large body
Der Browser zeigt „413 Request Entity Too Large“ oder einfach eine abgebrochene Seite.
In der Anwendung selbst taucht nichts auf, als wäre die Anfrage nie angekommen.
Die „Layer 8“-Wahrheit
Genau das ist der Punkt: Die Anfrage ist nie angekommen. 413 ist einer der wenigen
Fehler, die man am richtigen Ort suchen muss, statt am naheliegenden. Man vermutet den
Schuldigen in der Anwendung, die den Upload entgegennimmt – dabei sitzt die Grenze eine
Ebene davor, im Webserver, der die Anfrage schon abweist, bevor die Anwendung sie zu
Gesicht bekommt. Deshalb schweigt deren Log: Es gibt schlicht nichts zu protokollieren.
nginx begrenzt die Größe des Anfragekörpers ab Werk auf ein Megabyte. Das ist bewusst
knapp gewählt, denn diese Grenze ist auch ein Schutzwall gegen mutwillig aufgeblähte
Anfragen. Sie heraufzusetzen ist eine Zeile – und die zweite Hälfte der Wahrheit ist,
dass eine Zeile oft nicht reicht. Wo PHP dahintersteht, wachen dort noch einmal zwei
eigene Grenzen, und ein vorgeschalteter Proxy bringt gern seine dritte mit. Die Kette
trägt nur so viel wie ihr schwächstes Glied. Wer nur an nginx dreht und dann verwundert
ist, dass 413 bleibt, hat nicht das falsche Werkzeug benutzt, sondern nur eines von
mehreren. Und die Prüfung ganz abzuschalten, indem man sie auf null setzt, tauscht ein
lästiges Limit gegen ein offenes Scheunentor – das ist kein Fortschritt.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Den wahren Auslöser erkennen
413 kommt nicht von der Anwendung, sondern vom Webserver davor. nginx begrenzt die Größe des Anfragekörpers per Voreinstellung auf ein Megabyte. Ein Foto vom Handy reißt das mühelos. Der Upload scheitert also, bevor er die Anwendung überhaupt erreicht – deshalb steht in deren Log nichts.
2.
Das Limit in der nginx-Konfiguration heraufsetzen
Die Direktive client_max_body_size gehört in den http-, server- oder location-Block. Der Wert sollte großzügig, aber nicht grenzenlos sein: Er ist auch ein Schutz davor, dass jemand den Server mit riesigen Anfragen zumüllt. Für Bild-Uploads sind einige Dutzend Megabyte üblich.
client_max_body_size 25m;
3.
Erst prüfen, dann neu laden
Vor dem Übernehmen die Konfiguration testen – ein Tippfehler legt sonst den ganzen Server lahm. Erst wenn der Test grün ist, wird neu geladen. Ein Reload trennt keine bestehenden Verbindungen, ein falscher Neustart schon.
sudo nginx -t && sudo systemctl reload nginx
4.
Das zweite, versteckte Limit in PHP heben
Läuft dahinter PHP, gibt es dort noch zwei eigene Grenzen. Beide müssen mindestens so groß sein wie die Datei, sonst kommt der Upload zwar durch nginx, scheitert aber danach. Diese Werte stehen in der php.ini, nicht in der nginx-Konfiguration – ein häufiger Grund, warum die erste Änderung scheinbar nichts bringt.
upload_max_filesize = 30M
post_max_size = 30M
5.
Nicht bei null landen
Man kann die Prüfung mit dem Wert 0 ganz abschalten. Das ist selten eine gute Idee: Ohne jede Obergrenze nimmt der Server beliebig große Anfragen an und wird angreifbar. Ein konkreter, ausreichender Wert ist fast immer die bessere Wahl als gar keiner.
Häufige Fragen (FAQ)
?Ich habe nginx geändert und bekomme trotzdem 413 – warum?
Dann greift wahrscheinlich ein zweites Limit. Läuft hinter nginx eine PHP-Anwendung, kappen deren Werte upload_max_filesize und post_max_size die Datei unabhängig von nginx. Steckt dazwischen ein weiterer Proxy oder ein Load Balancer, hat der oft eine eigene Obergrenze. Die Kette ist nur so großzügig wie ihr kleinstes Glied – alle Stationen müssen mitziehen.
?Warum zeigt mein Browser die Fehlerseite so hässlich oder gar nicht an?
Das ist bekannt und steht sogar in der nginx-Dokumentation: Browser können die 413-Antwort oft nicht sauber darstellen, weil der Server die Verbindung abbricht, während der Browser noch Daten sendet. Der Nutzer sieht dann eine abgebrochene oder leere Seite. Das ist kein zusätzlicher Fehler, sondern eine Folge davon, wie 413 zustande kommt.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Liegen mehrere HTTPS-Namen auf einer IP, entscheidet die SNI-Erweiterung, welches Zertifikat kommt. Fehlt sie, liefert der Server das Standardzertifikat.
nginx liefert 502 Bad Gateway? Der Upstream antwortet nicht wie erwartet. So findest du Dienst-, Timeout- und Berechtigungsursachen und reparierst sie.
nginx liefert 504 Gateway Timeout? Der Upstream antwortet nicht rechtzeitig, bevor nginx aufgibt. So findest du die Ursache und setzt Timeouts sinnvoll.