413 Request Entity Too Large: Ursachen und Lösungen

2026-09-19

Ein 413 Payload Too Large, auch 413 Request Entity Too Large genannt, bedeutet, der Anfrage-Body ist größer als ein irgendwo zwischen Client und Anwendung gesetztes Limit. Der Server, oder etwas davor, hat sich geweigert, den Body überhaupt zu verarbeiten, sobald er gesehen oder abgeschätzt hat, wie groß er ist.

Was 413 Payload Too Large bedeutet

RFC 9110 definiert den aktuellen Namen als 413 Content Too Large, obwohl 413 Payload Too Large und das ältere 413 Request Entity Too Large beide auf denselben Statuscode verweisen und weiterhin bei Servern, Frameworks, und Fehlerseiten auftauchen. Unabhängig vom Wortlaut ist die Bedeutung identisch: Die Anfrage selbst war syntaktisch in Ordnung, aber ihr Body überschritt ein Größenlimit, bevor der Server sie zur Verarbeitung annehmen wollte. Das passiert am häufigsten bei Datei-Uploads, kann aber bei jeder Anfrage mit großem Body passieren, einschließlich eines Bulk-API-Payloads.

Wie sich der Fehler zeigt

Browser zeigen üblicherweise die einfache Fehlerseite, die der Ursprungsserver oder die Edge zurückgeschickt hat; es gibt keine dedizierte Browser-Oberfläche dafür wie bei einem Verbindungsfehler. Es kommt häufig vor, dass es in einem Formular still scheitert, wobei die Antwort nur im Netzwerk-Tab sichtbar ist, besonders bei einem mit JavaScript gebauten Datei-Upload. Von der Kommandozeile aus bestätigt die Antwort es direkt:

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

Server-Zugriffs- und Fehlerlogs sind der zuverlässigste Ort, um die genaue beteiligte Größe zu bestätigen und welche Schicht sie abgelehnt hat, da eine Anfrage am CDN, am Webserver, oder an der Anwendung blockiert werden kann, und jede protokolliert es unterschiedlich.

Was einen 413 verursacht

nginx' client_max_body_size. Der Standardwert ist 1 MB, klein genug, dass fast jeder echte Datei-Upload dagegen läuft, bis er ausdrücklich erhöht wird:
```
client_max_body_size 20M;
```
Apaches LimitRequestBody. Pro Verzeichnis oder global gesetzt, und, wie bei nginx, standardmäßig auf eine Größe, die viele Anwendungen überschreiten, ohne dass jemand sie absichtlich geändert hat.
PHPs upload_max_filesize und post_max_size. Zwei getrennte Einstellungen in php.ini, die beide groß genug für den Upload sein müssen; post_max_size muss mindestens so groß sein wie upload_max_filesize, sonst begrenzt die zweite Einstellung die erste still.
IIS' maxAllowedContentLength. Gesetzt in web.config unter requestLimits, standardmäßig rund 30 MB, und getrennt von ASP.NETs eigener maxRequestLength-Einstellung, die andere Einheiten nutzt und zusammen mit ihr erhöht werden muss.
Cloudflares planbasiertes Upload-Limit. Free- und Pro-Pläne begrenzen die Anfrage-Body-Größe auf 100 MB, unabhängig davon, was der Ursprungsserver sonst akzeptieren würde, und dieses Limit lässt sich nicht aus der Konfiguration des Ursprungs erhöhen; es muss auf Cloudflare-Seite adressiert oder mit einem direkten Upload-Pfad umgangen werden, der den Proxy überspringt.
API-Gateway-Payload-Limits. Verwaltete API-Gateways begrenzen Anfrage-Bodys üblicherweise deutlich unter dem, was ein traditioneller Webserver erlauben würde, oft im niedrigen einstelligen Megabyte-Bereich, was Teams trifft, die eine bestehende Upload-Funktion hinter ein neues Gateway migrieren.

So finden Sie heraus, wer schuld ist

Das ist fast nie Schuld eines Besuchers in dem Sinne, dass er etwas falsch gemacht hat; die Datei, die er hochlädt, ist einfach größer als ein irgendwo in der Kette existierendes Limit, und die Lösung gehört, wem auch immer diese Schicht gehört. Lädt dieselbe Datei in einer Umgebung sauber hoch und scheitert in einer anderen, vergleichen Sie jede Schicht im Anfragepfad, da nginx, PHP, und ein CDN jeweils ein unterschiedliches Limit haben können und das kleinste gewinnt. Eine HTTP-Prüfung mit einem Anfrage-Body nahe Ihrem beabsichtigten Limit, von außerhalb Ihres Netzwerks gesendet, bestätigt, was die tatsächliche Obergrenze durchgängig wirklich ist, statt sich auf eine einzelne Konfigurationsdatei zu verlassen.

So beheben Sie einen 413-Fehler

Wenn Sie Besucher sind

Komprimieren Sie die Datei vor dem Hochladen, besonders Bilder und Videos, die bei typischen Größen oft dramatisch schrumpfen, ohne sichtbaren Qualitätsverlust.
Teilen Sie einen großen Upload in kleinere Teile auf, falls die Website Chunked- oder fortsetzbare Uploads unterstützt, statt eine sehr große Anfrage zu senden.
Prüfen Sie das angegebene Upload-Limit der Website, falls eines veröffentlicht ist, da manche 413er wie beabsichtigt funktionieren und die Lösung einfach eine kleinere Datei ist.

Wenn Sie die Website betreiben

Erhöhen Sie jedes Schichtlimit zusammen, nicht nur eines. Eine einzelne Anfrage durchläuft typischerweise ein CDN, einen Webserver, und eine Anwendungslaufzeit, und das kleinste irgendwo in dieser Kette konfigurierte Limit bestimmt die tatsächliche Obergrenze.
Setzen Sie nginx und Apache ausdrücklich, statt sich auf Standardwerte zu verlassen:
```
# nginx
client_max_body_size 20M;

# Apache
LimitRequestBody 20971520
```
Gleichen Sie PHPs zwei Einstellungen ab. Erhöhen Sie sowohl upload_max_filesize als auch post_max_size, und stellen Sie sicher, dass die zweite mindestens so groß wie die erste ist.
Aktualisieren Sie IIS' requestLimits und ASP.NETs maxRequestLength zusammen in web.config, da sie dasselbe in unterschiedlichen Einheiten messen und beide erhöht werden müssen.
Umgehen Sie Cloudflares Plan-Limit für tatsächlich große Dateien, indem Sie direkt mit einer signierten URL in den Speicher hochladen und so den proxied Anfragepfad ganz überspringen, statt zu versuchen, ein Limit zu erhöhen, das diese Plan-Stufe nicht anbietet.
Prüfen Sie das eigene Payload-Limit des API-Gateways getrennt vom Backend-Dienst, falls eines vor Ihrer Anwendung sitzt; es kann eine Anfrage ablehnen, bevor Ihre eigenen, großzügigeren Anwendungseinstellungen überhaupt zum Zug kommen.

So verhindern Sie, dass ein 413 echte Nutzer blockiert

Ein zu niedrig gesetztes Limit übersieht man leicht, bis jemand mit einer großen Datei darauf trifft, und bis dahin sieht es wie eine kaputte Upload-Funktion aus, nicht wie eine Konfigurations-Fehlpassung. Eine geplante HTTP-Prüfung, die eine Anfrage nahe Ihrem beabsichtigten Größenlimit sendet, mit einer Zusicherung auf den erwarteten Statuscode, bestätigt, dass die gesamte Kette sie nach jeder Änderung an CDN-, Webserver-, oder Anwendungskonfiguration weiterhin akzeptiert. Kombiniert mit Monitoring von mehreren Standorten erkennt sie außerdem ein CDN-seitiges Limit, das nur an bestimmten Edge-Knoten greift.

Häufig gestellte Fragen

Ist 413 Payload Too Large dasselbe wie 413 Request Entity Too Large?

Ja. RFC 9110 hat den Statustext in 413 Content Too Large umbenannt, aber beide älteren Namen verweisen auf denselben Statuscode und dieselbe Bedeutung, und alle drei Formulierungen tauchen je nach Version der Serversoftware weiterhin in freier Wildbahn auf.

Warum scheitert mein Upload, obwohl ich nginx' client_max_body_size erhöht habe?

Eine andere Schicht in der Kette, häufig PHPs post_max_size, das feste Plan-Limit eines CDN, oder ein API-Gateway, setzt wahrscheinlich unabhängig ein kleineres Limit durch. Jede Schicht zwischen Client und Anwendung muss die Größe erlauben, nicht nur die eine, die Sie geändert haben.

Kann ich Cloudflares 100-MB-Limit im Free- oder Pro-Plan erhöhen?

Nicht über die eigene Konfiguration des Ursprungsservers; diese Obergrenze ist durch die Plan-Stufe fest vorgegeben. Die übliche Umgehung ist, große Dateien direkt mit einer signierten URL in den Speicher hochzuladen, die den proxied Anfragepfad überspringt.

Zählt 413 als Sicherheitsblockierung?

Typischerweise nicht. Es ist meist ein unkompliziertes Ressourcenlimit statt einer defensiven Regel, obwohl manche WAFs ungewöhnlich große Bodys als eines von mehreren Signalen nutzen, wenn sie entscheiden, ob eine Anfrage blockiert wird.

Was ist ein vernünftiges Standard-Upload-Limit, falls ich keins gesetzt habe?

Es gibt keine universelle Zahl; das hängt vollständig davon ab, was Ihre Anwendung legitim akzeptieren muss. Setzen Sie es bewusst basierend auf Ihrer größten erwarteten legitimen Datei, statt den Standardwert jeder Schicht unverändert zu lassen.