Du stehst vor deinem Monitor, willst gerade ein wichtiges Backup hochladen oder ein hochauflösendes Bild im CMS speichern, und plötzlich knallt dir der Server eine Fehlermeldung vor den Latz. Nichts geht mehr. Der Browser zeigt stur an: 413 Request Entity Too Large Nginx. Das ist nervig, passiert aber den Besten. Im Grunde sagt dir dein Webserver damit nur, dass du versuchst, ein Paket durch einen Briefschlitz zu quetschen, der viel zu schmal eingestellt ist. Die gute Nachricht ist, dass wir das Problem in weniger als fünf Minuten aus der Welt schaffen können, wenn du Zugriff auf deine Konfigurationsdateien hast.
Dieser Fehler tritt auf, weil Nginx standardmäßig sehr vorsichtig ist. Die Entwickler haben sich gedacht, dass es klug wäre, die maximale Größe von Client-Anfragen standardmäßig auf einen recht mickrigen Wert zu begrenzen. Meist liegt dieser Wert bei nur einem Megabyte. Wer heute ein Foto mit dem Smartphone macht, knackt diese Grenze oft schon beim ersten Klick. Wenn du also eine WordPress-Seite betreibst, eine eigene API baust oder ein Dateiverwaltungssystem pflegst, wirst du früher oder später über diese Hürde stolpern. Es ist kein Zeichen für einen kaputten Server, sondern lediglich eine Sicherheitsmaßnahme gegen sogenannte Denial-of-Service-Angriffe, bei denen jemand versucht, den Server mit riesigen Datenmengen lahmzulegen.
Warum die Standardeinstellungen oft nicht ausreichen
Wer moderne Webanwendungen baut, kommt mit einem Megabyte nicht weit. Denk an Videoplattformen oder Agenturen, die Bildmaterial in Druckqualität austauschen müssen. Hier ist die Standardkonfiguration schlichtweg realitätsfern. Nginx blockiert den Upload sofort, bevor die Daten überhaupt vollständig verarbeitet werden. Das schont zwar die Ressourcen des Servers, verhindert aber auch, dass deine Nutzer ihre Arbeit erledigen können.
Die Lösung für 413 Request Entity Too Large Nginx Schritt für Schritt
Um diese Sperre aufzuheben, müssen wir direkt in das Herz deines Webservers schauen. Die Lösung liegt in einer einzigen Direktive namens client_max_body_size. Du findest sie in den Konfigurationsdateien deines Nginx-Servers. Je nachdem, wie dein System aufgebaut ist, liegt diese Datei meist unter /etc/nginx/nginx.conf oder in einem spezifischen Verzeichnis für deine Seite unter /etc/nginx/sites-available/.
Den richtigen Ort in der Konfiguration finden
Du hast drei Möglichkeiten, wo du diese Änderung eintragen kannst. Wenn du die Änderung für den gesamten Server übernehmen willst, suchst du den http-Block in der Hauptkonfiguration. Das ist praktisch, wenn du viele kleine Projekte hostest, die alle ähnliche Anforderungen haben.
Falls du jedoch nur einer bestimmten Website mehr Spielraum geben willst, setzt du die Anweisung in den server-Block der entsprechenden Site-Konfiguration. Das ist der saubere Weg. So verhinderst du, dass du unnötige Sicherheitsrisiken für alle anderen Projekte auf dem gleichen Server eingehst. Es gibt sogar die Möglichkeit, das Ganze nur für einen bestimmten Pfad zu erlauben, indem du die Direktive in einen location-Block packst, zum Beispiel nur für den /upload-Ordner.
Die Umsetzung in der Praxis
Öffne die Datei mit einem Editor deiner Wahl, zum Beispiel Nano oder Vim. Du musst Root-Rechte haben, also nutze sudo. Such die Stelle, an der du die Änderung einfügen willst. Wenn dort bereits ein Eintrag für die maximale Körpergröße steht, pass den Wert einfach an. Wenn nicht, schreibst du eine neue Zeile.
Ein Beispiel für 100 Megabyte sieht so aus: client_max_body_size 100M;. Vergiss das Semikolon am Ende nicht. Das ist ein Klassiker unter den Fehlern, die dafür sorgen, dass Nginx danach gar nicht mehr startet. Du kannst auch Gigabyte-Werte angeben, etwa 2G, aber sei damit vorsichtig. Ein zu hoher Wert lädt Angreifer geradezu ein, deinen Arbeitsspeicher zu fluten.
Den Server neu starten
Nachdem du die Datei gespeichert hast, darfst du nicht vergessen, die Konfiguration zu prüfen. Tippe dazu nginx -t in deine Konsole. Wenn dort steht, dass die Syntax okay ist, kannst du den Dienst mit systemctl reload nginx oder service nginx reload neu laden. Der Befehl reload ist hier besser als restart, weil er laufende Verbindungen nicht hart trennt, sondern nur die neue Konfiguration einliest. Jetzt sollte die Meldung verschwinden und dein Upload funktionieren.
Wenn Nginx nicht das einzige Hindernis ist
Manchmal änderst du die Einstellung in Nginx und stellst fest, dass der Fehler immer noch da ist. Das ist der Moment, in dem viele Administratoren anfangen, an ihrem Verstand zu zweifeln. Wenn du PHP-Anwendungen wie WordPress oder Nextcloud nutzt, hat PHP oft eigene Vorstellungen davon, wie groß ein Upload sein darf. Nginx ist hier nur der Türsteher. Wenn der Türsteher dich durchlässt, kann es sein, dass dich der Hausherr im Inneren trotzdem rauswirft.
PHP Einstellungen anpassen
Du musst in diesem Fall die php.ini Datei bearbeiten. Dort gibt es zwei wichtige Werte: upload_max_filesize und post_max_size. Diese beiden müssen mindestens so groß sein wie der Wert, den du in Nginx eingestellt hast. Eigentlich sollte post_max_size immer ein Stück größer sein als upload_max_filesize, da beim Senden einer Datei auch noch Kopfdaten und Formularfelder mit übertragen werden.
Ein typisches Setup könnte so aussehen:
upload_max_filesize = 100Mpost_max_size = 110M
Nach der Änderung in der PHP-Konfiguration musst du den PHP-FPM Dienst neu starten. Meistens geht das mit systemctl restart php8.2-fpm (die Version musst du natürlich an deine installierte Version anpassen). Erst wenn beide Systeme – Nginx und PHP – aufeinander abgestimmt sind, läuft der Datentransfer reibungslos.
Proxies und Load Balancer
In komplexeren Umgebungen steht Nginx vielleicht gar nicht allein an vorderster Front. Vielleicht nutzt du einen Cloud-Anbieter oder einen zusätzlichen Proxy wie Cloudflare. Diese Dienste haben oft eigene Limits. Wenn Cloudflare vor deinem Server sitzt, liegt das Limit im kostenlosen Tarif bei 100 Megabyte. Versuchst du dort eine Datei mit 200 Megabyte hochzuladen, wird die Anfrage schon abgelehnt, bevor sie überhaupt deinen Nginx-Server erreicht. In solchen Fällen hilft es nichts, lokal am Server zu schrauben. Du musst dann entweder den Tarif beim Anbieter upgraden oder die Daten in kleineren Häppchen senden.
Sicherheitsaspekte beim Erhöhen der Limits
Ich sehe oft, dass Leute die Limits einfach auf 0 setzen. Das bedeutet bei Nginx: Unbegrenzt. Mach das bitte niemals auf einem produktiven System. Es ist die digitale Entsprechung dazu, die Haustür nachts weit offen stehen zu lassen und ein Schild "Bedient euch" dranzuhängen.
Ein Angreifer könnte eine Endlosschleife starten und riesige Datenmengen an deinen Server schicken. Das Ergebnis? Deine Festplatte läuft voll, dein Arbeitsspeicher kapituliert, und dein ganzer Dienst bricht zusammen. Setze das Limit immer nur so hoch wie unbedingt nötig. Wenn deine Nutzer maximal Bilder von 20 Megabyte hochladen müssen, dann stell 30 Megabyte ein. Das ist genug Puffer und bietet trotzdem Schutz.
Monitoring der Uploads
Es ist sinnvoll, die Error-Logs deines Servers im Auge zu behalten. Unter /var/log/nginx/error.log siehst du genau, wann und wie oft Nutzer gegen das Limit stoßen. Wenn du dort ständig Einträge findest, die den Text 413 request entity too large nginx enthalten, weißt du, dass dein Limit zu niedrig angesetzt ist. Ein gesundes Monitoring hilft dir, proaktiv zu handeln, bevor sich die ersten Nutzer bei dir beschweren.
Du kannst Tools wie das Nginx-Dashboard nutzen, um die Leistung im Blick zu behalten, falls du die kommerzielle Version einsetzt. Für alle anderen reichen oft einfache Log-Analyzer oder sogar ein simples grep auf der Kommandozeile aus.
Die Rolle des Arbeitsspeichers
Ein Punkt, der oft übersehen wird, ist der Speicherbedarf während des Uploads. Wenn eine Datei hochgeladen wird, muss Nginx sie irgendwo zwischenspeichern. Dafür gibt es die Direktive client_body_buffer_size. Wenn die hochgeladene Datei größer ist als dieser Puffer, schreibt Nginx die Daten in eine temporäre Datei auf die Festplatte. Das ist langsamer als der RAM, aber sicherer für die Systemstabilität.
Standardmäßig ist dieser Puffer recht klein eingestellt, oft nur 8k oder 16k. Auf modernen Systemen mit viel RAM kannst du diesen Wert ruhig auf 128k oder sogar 256k erhöhen. Das beschleunigt den Prozess bei vielen kleinen Anfragen spürbar. Aber auch hier gilt: Wer übertreibt, riskiert bei vielen gleichzeitigen Verbindungen, dass der RAM zur Neige geht.
Typische Stolperfallen und wie man sie umgeht
Ein häufiges Problem ist die Vererbung von Einstellungen. Du hast das Limit im http-Block geändert, wunderst dich aber, dass eine bestimmte Domain immer noch blockt. Schau nach, ob in der spezifischen Site-Konfiguration ein anderer Wert steht, der den globalen Wert überschreibt. In Nginx gilt immer: Die spezifischste Regel gewinnt.
Berechtigungen für temporäre Verzeichnisse
Nginx braucht einen Ort, an dem es große Dateien zwischenspeichern kann, wenn sie den RAM-Puffer überschreiten. Normalerweise ist das /var/lib/nginx/body. Wenn der Nutzer, unter dem Nginx läuft (oft www-data), dort keine Schreibrechte hat, scheitert der Upload ebenfalls. Das sieht dann im Log oft nach einem 500er Fehler aus, kann aber auch merkwürdige 413er Phänomene auslösen. Prüfe im Zweifel mit ls -ld /var/lib/nginx/body, ob die Rechte stimmen.
Timeout-Probleme bei langsamen Verbindungen
Große Dateien brauchen Zeit. Wenn dein Nutzer eine 500 Megabyte Datei mit einer lahmen DSL-Leitung hochlädt, kann es sein, dass die Verbindung abbricht, bevor Nginx fertig ist. Das hat zwar nichts direkt mit dem 413er Fehler zu tun, ist aber oft das nächste Problem, das auftaucht, sobald du das Größenlimit gelöst hast.
Du solltest dann die Werte für client_body_timeout und send_timeout erhöhen. Standardmäßig stehen diese oft auf 60 Sekunden. Bei massiven Uploads kann das zu kurz sein. Setz sie ruhig auf 300 Sekunden oder mehr, wenn du weißt, dass deine Nutzer oft mit großen Datenmengen hantieren.
Praktische Beispiele aus der Webentwicklung
Stell dir vor, du betreust ein Portal für Fotografen. Die Leute laden dort RAW-Dateien hoch. Eine Datei hat locker 50 Megabyte. Du hast Nginx auf einem Standard-Debian installiert. Ohne Anpassung wird kein einziger Fotograf glücklich sein.
Ich habe in solchen Projekten gute Erfahrungen damit gemacht, die Limits stufenweise zu testen. Erst auf 64M, dann auf 128M. Man muss auch die Infrastruktur dahinter im Blick haben. Wenn dein Server nur 2 GB RAM hat, solltest du nicht 50 parallele Uploads von 500 MB erlauben. Das rechnet sich einfach nicht und führt zum Absturz.
Mobile Apps und API-Schnittstellen
Bei APIs ist das Ganze noch kritischer. Wenn eine Mobile App Daten sendet, zum Beispiel ein Video-Snippet, und der Server mit einem 413 antwortet, muss die App das korrekt interpretieren. Viele schlechte Apps zeigen dann nur "Netzwerkfehler" an. Das hilft dem Nutzer nicht weiter. Als Entwickler solltest du sicherstellen, dass deine API-Dokumentation die maximal erlaubte Größe klar kommuniziert.
Es gibt gute Ressourcen bei der Internet Engineering Task Force (IETF), die sich mit HTTP-Statuscodes beschäftigen. Es ist immer klug, sich an diese Standards zu halten, damit die Kommunikation zwischen Client und Server sauber bleibt.
Cloud-Umgebungen und Container
Wenn du Docker nutzt, musst du darauf achten, dass die Konfiguration auch im Container landet. Oft wird vergessen, die angepasste nginx.conf per Volume zu mounten oder im Dockerfile zu kopieren. Das führt dazu, dass lokal alles super funktioniert, aber in der Cloud plötzlich wieder der 413er auftaucht.
In Kubernetes-Umgebungen mit einem Ingress-Controller wie dem von Nginx wird diese Einstellung oft über Annotations gelöst. Du schreibst dann direkt in deine Ingress-Ressource: nginx.ingress.kubernetes.io/proxy-body-size: "100m". Das ist sehr elegant, weil du den globalen Controller nicht anfassen musst und die Verantwortung direkt beim jeweiligen Service liegt.
Nächste Schritte zur Fehlerbehebung
Wenn du jetzt vor deinem Terminal sitzt, gehe diese Liste der Reihe nach durch. Das spart Zeit und schont die Nerven.
- Konfigurationsdatei finden: Suche nach deiner Nginx-Konfiguration unter
/etc/nginx/. - Direktive einfügen: Füge
client_max_body_size 100M;(oder deinen Wunschwert) in denhttp,serveroderlocationBlock ein. - Syntax prüfen: Führe unbedingt
nginx -taus. Ein kleiner Tippfehler legt sonst deine ganze Website lahm. - Reload ausführen: Lade den Dienst mit
systemctl reload nginxneu. - Backend prüfen: Falls du PHP nutzt, pass die
php.inian und starte den PHP-Dienst neu. - Testen: Versuche den Upload erneut. Wenn es immer noch hakt, schau in das Error-Log unter
/var/log/nginx/error.log.
Mit diesen Schritten hast du das Problem im Griff. Es ist eine der einfachsten Übungen in der Serveradministration, aber sie hat eine enorme Wirkung auf die Nutzererfahrung. Nichts ist frustrierender als ein technisches Hindernis, das man nicht versteht. Jetzt verstehst du es und kannst es lösen.
