413 request entity too large

Du willst gerade ein wichtiges Video hochladen oder ein großes Backup deiner WordPress-Seite einspielen und plötzlich starrt dich diese eine Zeile an: 413 Request Entity Too Large. Das nervt gewaltig. Dein Browser sagt dir im Grunde, dass du versuchst, ein fettes Paket durch einen viel zu schmalen Briefschlitz zu quetschen. Der Server sieht die Datenmenge, bekommt Panik und bricht die Verbindung sofort ab. Ich habe das schon dutzende Male bei Kundenprojekten erlebt, meistens genau dann, wenn es schnell gehen muss. In diesem Moment bringt es dir nichts, die Fehlermeldung nur anzustarren. Wir müssen unter die Haube deines Servers schauen und die künstlichen Grenzen aufheben, die deine Arbeit blockieren.

Warum dein Server dich plötzlich blockiert

Der HTTP-Statuscode 413 ist kein Zufallsprodukt oder ein kaputtes Kabel. Er ist eine Sicherheitsmaßnahme. Administratoren konfigurieren Webserver so, dass sie nur eine bestimmte Menge an Daten pro Anfrage akzeptieren. Das schützt den Server davor, mit massiven Uploads bombardiert zu werden, die den Speicher auffressen oder den Dienst lahmlegen könnten. Denk an einen DoS-Angriff, bei dem jemand versucht, gigantische Dateien hochzuladen, nur um deine CPU zum Glühen zu bringen. Standardmäßig sind diese Limits oft extrem niedrig eingestellt. Bei Nginx liegt die Grenze oft bei gerade einmal einem Megabyte. Das reicht heutzutage nicht mal mehr für ein hochauflösendes Foto vom Smartphone.

Wenn du also ein Plugin hochlädst oder ein Bild im Backend deiner Webseite austauschen willst, rennst du gegen diese Wand. Die Kommunikation bricht ab, bevor die Datei überhaupt verarbeitet werden kann. Es ist ein klassisches Konfigurationsproblem. Du musst dem Server explizit sagen: „Hey, ich vertraue diesem Upload, lass die Daten durch.“ Das Schöne ist, dass du dafür kein Informatikstudium brauchst. Ein paar Zeilen in der Konfigurationsdatei reichen meistens aus.

Die Rolle des Client-Requests

Der Client – also dein Browser – schickt einen Header mit, der die Länge des Inhalts ankündigt. Der Server liest diesen Content-Length-Header. Er vergleicht den Wert mit seiner eigenen erlaubten Höchstgrenze. Liegt dein Wert drüber, wird gar nicht erst versucht, die Datei zu speichern. Er schickt sofort die Fehlermeldung zurück. Das spart Ressourcen, weil der Server nicht erst 500 MB empfängt, um dann zu merken, dass er sie gar nicht will.

Sicherheit gegen Bequemlichkeit

Manchmal fragen mich Leute, warum man das Limit nicht einfach auf unendlich setzt. Das wäre ein fataler Fehler. Ein offenes Tor lädt Missbrauch ein. Du musst ein Gleichgewicht finden. Setze das Limit so hoch wie nötig für deine tägliche Arbeit, aber so niedrig wie möglich, um Angreifern keine unnötige Angriffsfläche zu bieten. Für die meisten Webseiten sind 64 MB oder 128 MB ein solider Mittelweg. Wer professionelle Videoproduktion betreibt, muss natürlich in den Gigabyte-Bereich gehen.

Strategien zur Behebung von 413 Request Entity Too Large

Um dieses Problem zu lösen, müssen wir wissen, welche Software auf deinem Server läuft. Die meisten nutzen entweder Nginx oder Apache. Beide handhaben diese Limits unterschiedlich. Wenn du ein Shared-Hosting-Paket hast, bei dem du keinen Zugriff auf die Hauptkonfiguration hast, wird es etwas kniffliger, aber auch dafür gibt es Lösungen über die .htaccess-Datei oder die php.ini.

Anpassungen bei Nginx-Servern

Nginx ist berüchtigt für sein extrem strenges Standardlimit von 1 MB. Wenn du hier etwas ändern willst, suchst du nach der Direktive client_max_body_size. Du findest die Konfigurationsdatei meist unter /etc/nginx/nginx.conf oder in deiner spezifischen Site-Konfiguration unter /etc/nginx/sites-available/.

Du fügst die Zeile einfach im http, server oder location Block hinzu. Wenn du sie im http Block platzierst, gilt sie für alle Webseiten auf diesem Server. Das ist bequem, aber manchmal unsauber. Besser ist es, das Limit im server Block deiner speziellen Domain zu setzen. Schreib dort zum Beispiel client_max_body_size 100M; rein. Vergiß nicht, den Dienst danach mit sudo systemctl reload nginx neu zu starten. Ohne den Reload weiß der Server nichts von seinem neuen Glück.

Die Lösung für Apache-Nutzer

Apache geht die Sache etwas anders an. Hier heißt der entscheidende Parameter LimitRequestBody. Im Gegensatz zu Nginx hat Apache oft gar kein striktes Standardlimit von Haus aus, oder es ist deutlich großzügiger bemessen. Aber viele Hosting-Anbieter setzen eigene Grenzen. Du kannst diesen Wert in deiner httpd.conf oder direkt in der .htaccess-Datei in deinem Web-Verzeichnis ändern.

Der Wert wird hier in Bytes angegeben. Wenn du also 100 MB erlauben willst, musst du das umrechnen. Das wären dann 104857600 Bytes. Ein Eintrag in der .htaccess sieht dann so aus: LimitRequestBody 104857600. Das ist besonders praktisch, wenn du keinen Zugriff auf die Server-Root-Rechte hast. Viele deutsche Hoster erlauben solche Anpassungen über die .htaccess problemlos.

Wenn PHP das eigentliche Hindernis ist

Oft denkst du, der Webserver sei schuld, dabei blockiert PHP im Hintergrund den Prozess. PHP hat eigene Regeln für Uploads. Selbst wenn Nginx ein Gigabyte durchlässt, sagt PHP vielleicht bei 2 MB „Stopp“. Das ist ein klassisches Missverständnis bei der Fehlersuche. Du siehst vielleicht die allgemeine Fehlermeldung des Servers, aber die Ursache liegt tiefer in der Skriptsprache.

Die wichtigsten PHP-Parameter

Du musst zwei Werte in deiner php.ini im Auge behalten. Erstens: upload_max_filesize. Das definiert das maximale Gewicht einer einzelnen Datei. Zweitens: post_max_size. Dieser Wert muss immer größer oder gleich der upload_max_filesize sein. Warum? Weil ein Datei-Upload technisch gesehen ein POST-Request ist, der neben der Datei auch noch andere Daten enthalten kann. Wenn du eine 50 MB Datei erlaubst, aber POST auf 10 MB begrenzt, wird der Upload scheitern.

Ich empfehle zudem, das memory_limit und die max_execution_time zu erhöhen. Nichts ist frustrierender, als wenn der Upload zwar erlaubt ist, das Skript aber nach 30 Sekunden abbricht, weil die Verarbeitung der großen Datei zu lange dauert. Setze die Zeit auf 300 Sekunden hoch, wenn du wirklich große Brocken bewegst.

PHP-Einstellungen ohne Zugriff auf die php.ini

Falls du bei einem Hoster wie Strato oder 1&1 Ionos bist und die zentrale php.ini nicht bearbeiten kannst, hilft oft eine lokale Datei im Hauptverzeichnis deines FTP-Accounts. Erstelle einfach eine Textdatei namens .user.ini oder füge die Werte in deine .htaccess ein, falls der Server mod_php nutzt. Bei modernen Setups mit PHP-FPM funktioniert die .user.ini meistens besser. Schreib dort einfach upload_max_filesize = 128M und post_max_size = 128M hinein. Es kann ein paar Minuten dauern, bis der Server diese Datei einliest.

Das Problem mit Proxys und Load Balancern

In modernen Infrastrukturen kommuniziert dein Browser oft nicht direkt mit dem Webserver. Da hängt noch ein Load Balancer, ein Reverse Proxy wie Varnish oder ein Dienst wie Cloudflare dazwischen. Das macht die Fehlersuche komplizierter. Du kannst deinen Nginx perfekt eingestellt haben, aber wenn der Proxy davor die Daten blockiert, siehst du trotzdem den Fehler.

Cloudflare und seine Grenzen

Cloudflare ist ein Segen für die Sicherheit, aber ein Fluch für riesige Uploads in der Gratis-Version. Im kostenlosen Tarif begrenzt Cloudflare die maximale Upload-Größe auf 100 MB. Wenn du versuchst, eine 150 MB Datei durchzuschleusen, wird Cloudflare den Request abfangen. Du bekommst dann oft eine Cloudflare-eigene Fehlerseite zu sehen.

Hier hast du nur zwei Optionen: Entweder du upgradest auf einen Pro- oder Business-Plan, die höhere Limits erlauben, oder du umgehst Cloudflare für diesen spezifischen Upload. Du könntest zum Beispiel eine Subdomain anlegen, die nicht durch den Cloudflare-Proxy (die graue Wolke im DNS) läuft, nur um solche Wartungsarbeiten durchzuführen.

Reverse Proxies und Buffer-Einstellungen

Wenn du einen eigenen Reverse Proxy betreibst, musst du auch dort die client_max_body_size anpassen. Es reicht nicht, das nur beim Zielserver (dem Upstream) zu tun. Der Proxy muss die Datenmenge ja erst mal annehmen, um sie weiterzuleiten. Achte auch auf Puffer-Einstellungen. Wenn der Proxy versucht, den gesamten Upload im RAM zwischenzuspeichern, bevor er ihn weiterreicht, kann dein Arbeitsspeicher schnell vollaufen. Nutze stattdessen temporäre Dateien auf der Festplatte für große Requests.

Die offizielle Dokumentation von Nginx bietet hierzu detaillierte technische Einblicke in die Funktionsweise der Pufferung. Es lohnt sich, dort mal reinzuschauen, wenn dein Server unter Last einknickt.

Fehlerursachen bei WordPress und CMS

WordPress-Nutzer trifft dieser Fehler besonders hart. Du willst ein neues Theme installieren und plötzlich erscheint eine kryptische Meldung oder einfach nur „Verbindung fehlgeschlagen“. In der WordPress-Welt wird dieser Fehler oft fälschlicherweise als reiner PHP-Fehler interpretiert. Aber oft ist es eben die Webserver-Ebene.

Plugins als Stolperstein

Es gibt Plugins, die versuchen, diese Limits dynamisch zu erhöhen. Ehrlich gesagt: Lass die Finger davon. Diese Tools machen oft nichts anderes, als zu versuchen, die htaccess oder php.ini zu überschreiben. Das schlägt bei vielen sicher konfigurierten Servern fehl. Es ist sauberer und sicherer, die Änderungen manuell vorzunehmen. So weißt du genau, was wo steht.

Ein spezieller Fall sind Backup-Plugins wie UpdraftPlus oder Duplicator. Diese zerlegen große Backups oft in kleinere Chunks. Das ist ein cleverer Workaround. Wenn dein Server absolut keine großen Dateien zulässt und du nichts an der Konfiguration ändern kannst, schau in den Einstellungen deines Backup-Tools nach „Split-Archiv“ oder „Chunk-Größe“. Stell sie auf 20 MB ein. Dann werden statt einer riesigen Datei viele kleine gesendet. Das umgeht das Limit elegant.

Die Mediathek-Falle

Wenn du in der WordPress-Mediathek siehst, dass das maximale Upload-Limit bei 2 MB liegt, ist das ein direkter Hinweis auf deine PHP-Einstellungen. Sobald du die Werte in der php.ini änderst, springt diese Anzeige in WordPress automatisch nach oben. Falls sie das nicht tut, funkt vielleicht dein Theme dazwischen, das ein eigenes Limit in der functions.php setzt. Suche dort nach ini_set Befehlen.

Analyse mit den Browser-Entwicklertools

Bevor du wild in Konfigurationsdateien herumschreibst, solltest du sicherstellen, dass es wirklich dieser Fehler ist. Drück in deinem Browser F12, um die Entwicklertools zu öffnen. Geh auf den Tab „Netzwerk“ und starte deinen Upload erneut.

Du wirst einen roten Eintrag sehen. Klick ihn an und schau dir die Header an. Wenn dort unter Statuscode klipp und klar 413 steht, weißt du Bescheid. Manchmal steht dort auch „Connection Reset“. Das passiert, wenn der Server die Verbindung so abrupt kappt, dass der Browser nicht mal mehr den Fehlercode richtig lesen kann. In der Konsole findest du oft wertvolle Hinweise darauf, welche Komponente der Kette die Bremse gezogen hat.

Server-Logs lesen

Die Wahrheit steht in den Logs. Schau per SSH auf deinen Server. Die Datei /var/log/nginx/error.log oder /var/log/apache2/error.log ist dein bester Freund. Dort steht meistens eine sehr präzise Fehlermeldung wie client intended to send too large body. Mit dieser Information kannst du exakt sehen, welche URL betroffen war und wie groß der Request tatsächlich war. Das hilft dir, das neue Limit realistisch zu setzen, statt nur zu raten.

Spezielle Szenarien und exotische Fehlerquellen

Manchmal liegt es weder am Server noch an PHP. Es gibt seltene Fälle, in denen Sicherheitssoftware auf deinem eigenen Computer den Request blockiert. Manche Antivirenprogramme scannen ausgehenden Traffic. Wenn sie eine riesige Datei in einem HTTP-POST sehen, halten sie das für verdächtig und unterbrechen den Stream. Das ist selten, aber ich habe es schon erlebt. Deaktiviere testweise kurzzeitig deinen Webschutz, um das auszuschließen.

Mobile Verbindungen und Timeouts

Wenn du über ein instabiles mobiles Netzwerk hochlädst, kann ein Paketverlust dazu führen, dass der Server denkt, der Request sei beendet oder fehlerhaft. Das resultiert zwar meistens in einem 408- oder 400-Fehler, aber manche Server-Konfigurationen werfen dann fälschlicherweise einen 413 aus, wenn die Header-Daten korrumpiert sind. Nutze für große Uploads immer eine stabile Kabelverbindung.

API-Schnittstellen und JSON-Payloads

Nicht nur Datei-Uploads sind betroffen. Wenn du eine API nutzt und ein riesiges JSON-Objekt per POST schickst, kannst du ebenfalls in das Limit laufen. Das passiert oft bei Datenimporten zwischen zwei Systemen. Hier musst du die Daten in kleinere Stapel (Batches) aufteilen. Es ist ohnehin schlechter Stil, 50 MB Rohdaten in einem einzigen API-Call zu schicken. Zerlege es in Häppchen von 500 Datensätzen. Das ist stabiler und leichter zu debuggen, wenn mal etwas schiefgeht.

Best Practices für die dauerhafte Lösung

Wenn du das Problem einmal gelöst hast, dokumentiere die Änderung. Es ist extrem nervig, wenn du nach einem Server-Update oder einem Umzug plötzlich wieder vor dem gleichen Problem stehst. Viele Linux-Distributionen überschreiben bei Major-Updates Konfigurationsdateien. Nutze Tools wie Ansible oder einfache Shell-Skripte, um deine Server-Einstellungen zu versionieren.

Monitoring einrichten

Gute Administratoren lassen sich benachrichtigen, wenn gehäuft 4xx-Fehler auftreten. Tools wie Grafana oder einfache Log-Parser können dir zeigen, ob deine Nutzer regelmäßig gegen das Upload-Limit rennen. Wenn das passiert, solltest du dein Geschäftsmodell oder deine technische Infrastruktur überdenken. Vielleicht ist es Zeit für einen dedizierten Storage-Server oder einen Dienst wie Amazon S3 für große Dateien.

Den richtigen Wert finden

Wie hoch soll das Limit nun sein? Hier ist eine kleine Faustregel:

1. Für normale Blogs: 32 MB (reicht für optimierte Bilder).
2. Für Business-Seiten mit PDF-Downloads: 64 MB.
3. Für Online-Kurse mit Video-Uploads: 500 MB bis 1 GB.
4. Für Agenturen, die Backups schieben: 2 GB oder mehr.

Alles über 2 GB wird über das klassische HTTP-Protokoll ohnehin etwas wackelig. Da solltest du eher über FTP, SFTP oder spezialisierte Protokolle nachdenken, die Resumable Uploads unterstützen. Das spart Frust bei Verbindungsabbrüchen.

Praktische Schritte zur sofortigen Behebung

Du hast jetzt die Theorie im Kopf, jetzt geht es an die Umsetzung. Hier ist dein Schlachtplan, den du Schritt für Schritt abarbeiten kannst, um die Blockade zu lösen.

1. Identifiziere deinen Webserver. Tippe curl -I deine-url.de im Terminal ein. Im Header Server: siehst du, ob Nginx oder Apache läuft.
2. Wenn Nginx: Öffne die Konfigurationsdatei deiner Seite. Suche nach client_max_body_size. Wenn sie nicht existiert, füge sie im server Block hinzu. Setze sie auf client_max_body_size 128M;. Speichere und führe nginx -t aus, um die Syntax zu prüfen. Dann lade den Dienst neu.
3. Wenn Apache: Prüfe, ob du die .htaccess im Stammverzeichnis deiner Seite bearbeiten kannst. Füge LimitRequestBody 134217728 hinzu (das sind 128 MB). Wenn das nicht hilft, musst du in die globale httpd.conf deines Servers ran.
4. Prüfe PHP: Erstelle eine Datei namens info.php mit dem Inhalt <?php phpinfo(); ?>. Ruf sie im Browser auf und suche nach upload_max_filesize. Liegt der Wert unter deiner Dateigröße? Dann passe die php.ini oder .user.ini an.
5. Lösche die info.php danach sofort wieder aus Sicherheitsgründen.
6. Teste den Upload erneut. Wenn es immer noch nicht geht, prüfe, ob ein Proxy wie Cloudflare oder eine Firewall wie ModSecurity dazwischenfunkt.

Mit diesen Schritten hast du das Problem systematisch eingekreist. Meistens ist es wirklich nur diese eine Zeile in der Nginx-Konfiguration, die alles aufhält. Bleib ruhig, arbeite die Kette von außen (Webserver) nach innen (PHP/Applikation) ab. Dann verschwindet die Meldung so schnell, wie sie gekommen ist. Schau dir zur Vertiefung auch die PHP-Dokumentation zu Upload-Fehlern an, dort werden noch weitere Statuscodes erklärt, die nach dem 413-Fehler auftreten könnten. Viel Erfolg beim Fixen deines Setups.