413 Request Entity Too Large beheben

Kurz gesagt. Der 413-Fehler bedeutet, dass der Body deiner Anfrage größer ist als das konfigurierte Limit. NGINX erlaubt ohne eigenen Eintrag nur 1 MB über client_max_body_size, Apache regelt das über LimitRequestBody, PHP über upload_max_filesize und post_max_size. In WordPress greifen php.ini, .user.ini und .htaccess. Hinter einem Reverse Proxy oder CDN gilt immer der kleinste Wert im Pfad.

Was der 413-Fehler bedeutet

Du lädst ein Theme, ein Plugin oder eine große Mediendatei hoch und der Server antwortet mit „413 Request Entity Too Large“. Der Upload bricht ab, bevor die Datei durch ist. Der Grund liegt in einer Zahl: der Body deiner Anfrage ist größer als das Maximum, das der Server annimmt.

Der Statuscode liegt im 4xx-Bereich und zeigt damit formal auf die Client-Seite. Praktisch ist es fast immer ein Konfigurationsproblem. Die Datei ist legitim, nur das Limit auf dem Server ist zu knapp gesetzt.

Andere Bezeichnungen für denselben Fehler

Je nach Webserver und Browser siehst du eine andere Formulierung. Gemeint ist immer derselbe Statuscode:

• 413 Content Too Large: die aktuelle Bezeichnung seit RFC 9110.
• 413 Payload Too Large: die vorherige Bezeichnung aus RFC 7231, weiterhin weit verbreitet.
• Request Entity Too Large: die klassische Variante, die viele Server bis heute ausliefern.
• HTTP Error 413: der generische Sammelbegriff.
• 413 Request Entity Too Large (nginx): NGINX schreibt seinen Namen mit auf die Fehlerseite.

Die Aufgabe bleibt in allen Fällen gleich. Du passt die Kapazität des Servers an deine tatsächlichen Dateigrößen an.

Wann der Fehler auftritt

Ein 413 erscheint fast immer bei einem POST-Request. Die typischen Fälle:

• Du lädst ein großes Video oder ein umfangreiches ZIP-Archiv in die Mediathek.
• Du installierst ein Theme oder Plugin mit viel Beiwerk direkt über wp-admin.
• Du schickst ein Formular mit mehreren Anhängen ab.
• Du sendest per API einen umfangreichen JSON-Payload.

Ursachen des 413-Fehlers

Zu niedriges Upload-Limit auf dem Server

Das ist in den meisten Fällen die Ursache. In der Serverkonfiguration steckt ein Wert, der die maximale Größe eines HTTP-Request-Bodys begrenzt. Hoster setzen diese Grenze bewusst niedrig, weil ein offenes Limit DoS-Angriffe mit endlosen Datenströmen erleichtert. Sobald du darüber liegst, kommt der 413 zurück. Die Lösung liegt in den Direktiven für die maximale Body-Größe und in den passenden PHP-Werten.

Falsche Dateirechte

Seltener, aber prüfenswert. Gehört das temporäre Upload-Verzeichnis dem Webserver-Benutzer nicht oder sind die Rechte zu restriktiv, scheitert der Upload, bevor die Datei verarbeitet wird. Üblich ist in diesem Fall ein 403 oder ein PHP-Fehler und nicht ein 413. Prüfe die Rechte trotzdem, wenn alle Limits sauber gesetzt sind und der Upload weiter abbricht.

Zu wenig Serverressourcen

Auf ausgelasteten Systemen, besonders im Shared Hosting, brechen große Uploads ab, weil Arbeitsspeicher oder Ausführungszeit nicht reichen. Das ergibt in der Regel einen 500er oder einen Timeout. Siehst du dabei einen 413, prüfe, ob upload_max_filesize, post_max_size und das Limit des Webservers zueinander passen. Ein kleines post_max_size bei großzügigem upload_max_filesize ist ein häufiger Stolperstein, denn der niedrigere Wert entscheidet.

So findest du heraus, welche Schicht blockt

Bevor du Werte änderst, stelle fest, wer die Anfrage abgewiesen hat. Leg dafür eine Testdatei mit bekannter Größe an:

dd if=/dev/zero of=test-20mb.bin bs=1M count=20

Schick sie an den Endpunkt, der abbricht, und sieh dir die vollständige Antwort an:

curl -v -F "[email protected]" https://deine-domain.de/wp-admin/async-upload.php

Kommt der 413 mit einem Server: nginx-Header und ohne WordPress-Ausgabe, hat NGINX abgewiesen. Enthält die Antwort eine WordPress-Fehlermeldung, greift ein PHP-Limit. Im NGINX-Log steht der Fall im Klartext:

sudo tail -f /var/log/nginx/error.log

Die passende Zeile lautet „client intended to send too large body“ und nennt die tatsächliche Größe des Requests. Erhöhe danach genau das Limit, das gegriffen hat, statt alle Werte gleichzeitig hochzusetzen. So bleibt die Konfiguration nachvollziehbar und du behältst die Schutzwirkung auf den anderen Ebenen.

Wo welches Limit sitzt

Der kleinste Wert in dieser Kette entscheidet. Ein client_max_body_size von 512M bringt nichts, solange post_max_size bei 8M steht.

413 in WordPress beheben

Bei WordPress zeigt sich der Fehler meist im Upload-Bereich von wp-admin. Welcher Weg passt, hängt davon ab, wie viel Zugriff du auf den Server hast.

PHP-Upload-Limits erhöhen

Das ist der wichtigste Hebel. Öffne deine php.ini. Wenn keine existiert, legst du im Wurzelverzeichnis eine leere Datei an und setzt diese Werte:

upload_max_filesize = 64M
post_max_size = 64M
memory_limit = 128M

upload_max_filesize begrenzt die einzelne Datei, post_max_size den gesamten Request-Body. Setze post_max_size gleich hoch oder höher als upload_max_filesize, sonst greift der kleinere Wert. memory_limit darf darüber liegen, bei größeren Uploads sind 256M sinnvoll, sofern dein Hoster das zulässt.

Lade PHP-FPM oder den Webserver danach neu, damit die Werte aktiv werden.

Die .htaccess anpassen

Auf einem Apache-Server mit mod_php ist die .htaccess der zuverlässigste Weg ohne Zugriff auf die php.ini. Hänge diese Zeilen unten an:

php_value upload_max_filesize 64M
php_value post_max_size 64M
php_value max_execution_time 300
php_value max_input_time 300

Unter PHP-FPM funktionieren php_value-Direktiven nicht und Apache antwortet mit einem 500er. Nutze dann eine .user.ini im Wurzelverzeichnis mit derselben Syntax wie die php.ini.

functions.php als Notlösung

Kein Zugriff auf Serverdateien? Dann bleibt die functions.php deines Themes. Geh zu Design > Theme-Datei-Editor und ergänze:

@ini_set( 'upload_max_filesize', '64M' );
@ini_set( 'post_max_size', '64M' );
@ini_set( 'max_execution_time', '300' );

Zwei Einschränkungen: beim Theme-Wechsel ist die Änderung weg. Und upload_max_filesize sowie post_max_size lassen sich zur Laufzeit meist nicht mehr überschreiben, weil PHP sie vor dem Skriptstart auswertet. Bleibt das Upload-Limit unverändert, geh eine Ebene tiefer auf .user.ini, .htaccess oder php.ini.

Dateirechte zurücksetzen

Sitzen die Limits und der Upload scheitert weiter, setze die Rechte zurück. Standard sind 644 für Dateien und 755 für Verzeichnisse. Über SSH erledigst du das in zwei Befehlen:

find /var/www/html/wp-content -type d -exec chmod 755 {} \;
find /var/www/html/wp-content -type f -exec chmod 644 {} \;

Ohne SSH-Zugang nimmst du FileZilla oder einen anderen FTP-Client, öffnest den Ordner wp-content und klickst mit der rechten Maustaste auf „Dateiattribute“. Setze 755 für Ordner und 644 für Dateien in zwei getrennten Durchläufen.

413 auf NGINX und Apache beheben

Auf einem eigenen VPS reichen die WordPress-Ebenen oft nicht. Dann setzt du direkt an der Webserver-Konfiguration an.

client_max_body_size in NGINX setzen

NGINX erlaubt ohne eigenen Eintrag 1 MB. Das ist der häufigste Grund für einen 413 hinter NGINX. Öffne /etc/nginx/nginx.conf oder die Datei deiner Site unter /etc/nginx/sites-available/ und setze die Direktive im http-, server- oder location-Block:

client_max_body_size 64M;

Prüfe die Syntax und lade den Dienst neu, damit die Änderung greift:

sudo nginx -t
sudo systemctl reload nginx

LimitRequestBody in Apache setzen

Apache regelt das über LimitRequestBody. Die Direktive gehört in die httpd.conf, in den VirtualHost oder in eine lokale .htaccess:

LimitRequestBody 67108864

Der Wert steht in Byte, 67108864 entspricht also 64 MB. Mit 0 hebst du die Grenze komplett auf. Lass das im Produktivbetrieb, denn ein offenes Limit macht den Server angreifbar.

413 in Reverse-Proxy-Setups

Moderne Stacks stellen NGINX als Reverse Proxy vor Apache, einen Application-Server oder einen Docker-Container. Dann siehst du einen 413 von NGINX, obwohl die Apache-Konfiguration korrekt ist. Der Request landet zuerst bei NGINX. Liegt er über client_max_body_size, erreicht er das Backend nie.

Setze das Limit deshalb auf jeder Schicht: Load Balancer, CDN, Reverse Proxy, Webserver und PHP. Entscheidend ist immer der kleinste Wert im Pfad.

Ein zweiter Wert lohnt hier ebenfalls einen Blick. Liegt client_body_buffer_size unter der Dateigröße, puffert NGINX den Request-Body auf der Festplatte. Der Upload funktioniert weiter, kostet bei vielen parallelen Uploads aber I/O und wird messbar langsamer.

So verhinderst du den 413-Fehler

Dateien verkleinern und komprimieren

Der einfachste Weg um einen 413 herum ist eine kleinere Datei. Für Bilder in WordPress nutzt du Smush oder EWWW Image Optimizer. Videos gehören auf YouTube oder Vimeo statt in die Mediathek, das spart Speicherplatz und Bandbreite auf dem Server.

Chunked Uploads aktivieren

Chunked Upload zerlegt eine große Datei in kleine Teile, zum Beispiel 2 MB, und schickt sie einzeln. Jeder Request bleibt damit unter dem Limit und der 413 tritt nicht auf. Viele WordPress-Plugins für große Dateien arbeiten so, ohne dass du eine Serverdatei anfassen musst.

CDN-Limits im Blick behalten

Ein CDN wie Cloudflare verteilt Traffic, bringt aber eigene Upload-Grenzen mit. Der kostenlose Tarif und Pro liegen bei 100 MB pro Request, Business bei 200 MB und Enterprise standardmäßig bei 500 MB. Eine 150-MB-Datei stoppt also im CDN, bevor dein Server sie überhaupt sieht. Stimme die CDN-Grenze mit client_max_body_size oder LimitRequestBody ab.

Serverwerte regelmäßig prüfen

Ruf eine phpinfo()-Seite auf und sieh dir upload_max_filesize, post_max_size und memory_limit an. Mit wachsender Seite passen alte Limits irgendwann nicht mehr. Lösch die Datei nach der Prüfung wieder, weil sie Details über deine Umgebung offenlegt.

Wo die NGINX-Konfiguration liegt

Die Hauptdatei liegt auf den meisten Linux-Distributionen unter /etc/nginx/nginx.conf. Viele Setups verteilen die Konfiguration zusätzlich auf /etc/nginx/sites-available/ und /etc/nginx/sites-enabled/. Lege vor jeder Änderung ein Backup an und prüfe mit sudo nginx -t, denn ein Tippfehler verhindert den Neustart.

FAQ: 413 Request Entity Too Large

Sonderfälle

Der 413 taucht auch außerhalb klassischer Uploads auf. Bei einem Headless-WordPress oder WordPress als Backend-API triffst du ihn bei REST-API-Aufrufen mit großen JSON-Payloads. Die Ursache ist dieselbe, nur der Kontext unterscheidet sich. Hier hilft zusätzlich, den Payload aufzuteilen statt das Limit weiter anzuheben.

Lokale Umgebungen sind der zweite Sonderfall. Dein Entwicklungssystem hat oft großzügige Limits, das Produktionssystem deutlich engere. Der Fehler zeigt sich dann erst nach dem Deployment. Teste Uploads deshalb in einem Staging-System, das die Produktionskonfiguration abbildet.

Womit du anfängst

Ohne Serverzugriff beginnst du bei der .htaccess oder der .user.ini. Mit Serverzugriff gehst du direkt an /etc/nginx/nginx.conf oder die Apache-Konfiguration und setzt das Limit dort, wo es für den ganzen Server gilt. Danach testest du mit einem echten Upload in Produktionsgröße, ob jede Schicht den neuen Wert übernommen hat.

Halte die Werte anschließend dokumentiert und prüfe sie erneut, sobald du den Stack erweiterst. Ein neues CDN, ein zusätzlicher Load Balancer oder ein Wechsel von mod_php zu PHP-FPM bringt ein neues Limit mit, das du kennen solltest, bevor der nächste Upload daran hängen bleibt.