HTTP 413 Request Entity Too Large: Grundursachen, Lösungen und Server-Konfigurationshandbuch

Der HTTP 413 Request Entity Too Large-Fehler ist ein serverseitiger Antwortstatuscode, der auftritt, wenn ein eingehender Anfrage-Body — meistens ein Datei-Upload — die maximale Payload-Größe überschreitet, die auf der Ebene des Webservers, Reverse-Proxys oder der Anwendungsschicht konfiguriert ist. Der Server lehnt die Anfrage aktiv ab, bevor er sie verarbeitet, und gibt dem Client einen 413-Status zurück.

Dieser Fehler ist kein clientseitiger Bug. Es handelt sich um einen bewussten Durchsetzungsmechanismus, der in Webserver wie Nginx und Apache, PHP-Laufzeitkonfigurationen und anwendungsseitige Middleware eingebaut ist. Zu verstehen, welche Schicht das Limit durchsetzt — und wie die korrekte Konfigurationsanweisung gezielt angepasst werden kann — ist der Unterschied zwischen einer sauberen Lösung und stundenlanger Fehlersuche.

Warum HTTP 413-Fehler auftreten: Eine schichtweise Analyse

Eine Datei-Upload-Anfrage durchläuft mehrere Verarbeitungsschichten, bevor sie Ihre Anwendung erreicht. Jede dieser Schichten kann die Anfrage unabhängig mit einer 413-Antwort ablehnen. Eine korrekte Diagnose des Fehlers erfordert die Identifizierung der verantwortlichen Schicht.

Schicht 1: Webserver-Direktiven

Nginx setzt Upload-Größenlimits über die client_max_body_size-Direktive durch. Ihr Standardwert beträgt 1MB, was für die meisten modernen Anwendungen sehr niedrig ist. Diese Direktive kann im http-, server– oder location-Blockkontext gesetzt werden, wobei der spezifischste Block Vorrang hat.

Apache verwendet die LimitRequestBody-Direktive, die in den meisten Distributionen standardmäßig 0 (unbegrenzt) ist — Hosting-Anbieter überschreiben dies jedoch routinemäßig in ihren globalen oder Virtual-Host-Konfigurationen mit einem restriktiven Wert. Apache verarbeitet außerdem .htaccess-Dateien, was bedeutet, dass das Limit auf Verzeichnisebene durchgesetzt werden kann, ohne die Hauptkonfiguration zu berühren.

Schicht 2: PHP-Laufzeitkonfiguration

PHP führt zwei unabhängige Direktiven ein, die beide erfüllt sein müssen, damit ein großer Upload erfolgreich ist:

• upload_max_filesize — die maximale Größe einer einzelnen hochgeladenen Datei
• post_max_size — die maximale Größe des gesamten POST-Anfrage-Bodys, die gleich oder größer als upload_max_filesize sein muss

Eine häufige Fehlkonfiguration besteht darin, upload_max_filesize = 50M zu setzen und dabei post_max_size auf seinem Standardwert von 8M zu belassen. Das POST-Body-Limit wird zuerst ausgewertet, sodass der Upload lautlos fehlschlägt, bevor das Dateigrößenlimit überhaupt geprüft wird.

Es gibt auch eine dritte Direktive, die häufig übersehen wird: max_input_time, die definiert, wie lange PHP auf den Empfang von Eingabedaten wartet. Bei langsamen Verbindungen mit großen Datei-Uploads kann dieses Timeout einen Fehler auslösen, der sich als 413 oder leere Antwort manifestiert.

Schicht 3: Reverse-Proxys und Load Balancer

Wenn Ihre Infrastruktur einen Reverse-Proxy verwendet — HAProxy, Varnish, Cloudflare oder eine Nginx-Instanz, die als Proxy vor einem anderen Server agiert — hat diese Proxy-Schicht eigene Body-Größenlimits. Ein von Cloudflare zurückgegebener 413 hat beispielsweise ein hartes Limit von 100MB bei Free- und Pro-Plänen, und keine serverseitige Konfiguration kann dies überschreiben. Überprüfen Sie stets die Antwort-Header Ihrer Proxy-Schicht, um den Ursprung des 413 zu identifizieren.

Schicht 4: Anwendungs- und CMS-Einschränkungen

Content-Management-Systeme und Frameworks wenden ihre eigenen Upload-Einschränkungen zusätzlich zu den Server- und PHP-Schichten an. WordPress liest das effektive Upload-Limit aus den PHP-Laufzeitwerten, setzt aber auch eigene Medienbibliothek-Beschränkungen durch. Einige WordPress-Plugins fügen zusätzliche Validierungsschichten hinzu. Benutzerdefinierte PHP-Anwendungen können $_FILES-Validierungslogik verwenden, die strengere Limits als der Server erlaubt auferlegt.

Nginx-Konfiguration: 413 auf Webserver-Ebene beheben

Bei Nginx erfordert die Behebung die Änderung von client_max_body_size im richtigen Konfigurationskontext. Die Bearbeitung des http-Blocks wendet das Limit global an; die Bearbeitung eines server– oder location-Blocks wendet es nur auf diesen Virtual Host oder Endpunkt an.

# Global setting — applies to all virtual hosts
http {
    client_max_body_size 100M;
}

# Per-virtual-host setting — preferred for multi-tenant environments
server {
    listen 80;
    server_name example.com;
    client_max_body_size 100M;

    # Granular control — apply only to the upload endpoint
    location /wp-admin/async-upload.php {
        client_max_body_size 256M;
    }
}

Überprüfen Sie nach der Bearbeitung die Konfigurationssyntax, bevor Sie neu laden:

nginx -t && systemctl reload nginx

Kritischer Sonderfall: Wenn Nginx als Reverse-Proxy vor PHP-FPM oder einem anderen Anwendungsserver agiert, müssen Sie auch die proxy_read_timeout– und proxy_send_timeout-Direktiven überprüfen. Ein großer Upload, der länger als das Timeout dauert, wird mitten in der Übertragung abgebrochen und erzeugt je nach Proxy-Verhalten einen 413- oder 504-Fehler.

Apache-Konfiguration: 413 auf Webserver-Ebene beheben

Apaches LimitRequestBody-Direktive akzeptiert einen Wert in Bytes. Die Direktive kann in httpd.conf, einem VirtualHost-Block, einem Directory-Block oder einer .htaccess-Datei platziert werden.

# In httpd.conf or VirtualHost block
LimitRequestBody 104857600

# In .htaccess (if AllowOverride is enabled for the directory)
LimitRequestBody 104857600

Der Wert 104857600 entspricht 100MB (100 × 1024 × 1024). Nach der Änderung von httpd.conf oder einer Virtual-Host-Datei starten Sie Apache neu:

apachectl configtest && systemctl restart apache2

Wichtiger Hinweis: In Shared-Hosting-Umgebungen können .htaccess-Änderungen ignoriert werden, wenn der Hosting-Anbieter AllowOverride None in seiner serverseitigen Konfiguration gesetzt hat. In diesem Fall kann nur der Hosting-Anbieter das Limit ändern. Dies ist einer der wichtigsten technischen Gründe, einen Wechsel zu einer VPS Hosting-Umgebung in Betracht zu ziehen, bei der Sie vollen Root-Zugriff auf die Serverkonfiguration haben.

PHP-Konfiguration: 413 auf Laufzeitebene beheben

Die php.ini-Datei ist die maßgebliche Quelle für PHP-Upload-Limits. Welche Datei bearbeitet werden muss, hängt von Ihrem PHP-Ausführungsmodell ab (mod_php, PHP-FPM, CLI). Verwenden Sie phpinfo() oder php --ini, um zu ermitteln, welche php.ini tatsächlich geladen wird.

; Minimum required changes for large file uploads
upload_max_filesize = 128M
post_max_size = 128M
max_input_time = 300
max_execution_time = 300
memory_limit = 256M

Nach der Bearbeitung von php.ini starten Sie den entsprechenden Dienst neu:

# For PHP-FPM
systemctl restart php8.2-fpm

# For Apache with mod_php
systemctl restart apache2

Alternative Methoden, wenn php.ini nicht zugänglich ist:

Wenn Sie einen Shared-Hosting-Plan ohne direkten php.ini-Zugriff nutzen, können Sie PHP-Einstellungen möglicherweise über folgende Wege überschreiben:

1. Eine .user.ini-Datei im Web-Root (funktioniert mit PHP-FPM):

upload_max_filesize = 64M
post_max_size = 64M

1. Eine .htaccess-Direktive (funktioniert nur mit mod_php):

php_value upload_max_filesize 64M
php_value post_max_size 64M

1. PHP-Laufzeitcode (begrenzte Wirksamkeit, nicht für den Produktionseinsatz empfohlen):

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

Beachten Sie, dass ini_set() in PHP 7.x und höher upload_max_filesize oder post_max_size zur Laufzeit nicht überschreiben kann — diese Direktiven werden vor dem Beginn der Skriptausführung ausgewertet. Die .user.ini– oder .htaccess-Methoden sind weitaus zuverlässiger.

WordPress-spezifische Lösung für 413-Fehler

WordPress zeigt sein effektives Upload-Limit im Bereich Medien > Neu hinzufügen an. Wenn das angezeigte Limit niedriger ist als das, was Sie in php.ini konfiguriert haben, liegt das typischerweise daran, dass WordPress aus einem anderen PHP-Prozess liest oder eine Caching-Schicht veraltete Konfigurationsdaten liefert.

Fügen Sie Folgendes zu wp-config.php hinzu, um die Upload-Größe explizit zu definieren:

@ini_set( 'upload_max_size', '128M' );
@ini_set( 'post_max_size', '128M' );
define( 'WP_MEMORY_LIMIT', '256M' );

Bei WordPress-Multisite-Installationen wird die Upload-Größe auf Netzwerkebene separat unter Netzwerkverwaltung > Einstellungen > Netzwerkeinstellungen > Maximale Upload-Dateigröße gesteuert. Diese Einstellung ist unabhängig von PHP-Limits und muss zusätzlich zu den serverseitigen Änderungen konfiguriert werden.

Vergleich: Wo 413 je nach Hosting-Umgebung behoben werden kann

Diagnose: Welche Schicht gibt den 413 zurück

Bevor Sie eine Lösung anwenden, bestätigen Sie die Quelle der 413-Antwort. Verwenden Sie curl mit ausführlicher Ausgabe, um die Antwort-Header zu untersuchen:

curl -v -X POST -F "file=@/path/to/largefile.zip" https://example.com/upload

Untersuchen Sie den Server-Antwort-Header sowie alle X-Powered-By– oder CF-RAY-Header. Ein CF-RAY-Header zeigt an, dass der 413 von Cloudflare stammt, nicht von Ihrem Server. Eine Antwort von nginx/1.x.x verweist auf die Nginx-Schicht. Kein Server-Header kann auf einen Load Balancer oder WAF vor Ihrer Anwendung hinweisen.

Überprüfen Sie auch Ihre Server-Fehlerprotokolle unmittelbar nach dem Auslösen des 413:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP-FPM
tail -f /var/log/php8.2-fpm.log

Wenn die Serverkonfiguration nicht ausreicht: Infrastrukturüberlegungen

Für Anwendungen, die routinemäßig große Dateiübertragungen verarbeiten — Videoplattformen, Backup-Systeme, medizinische Bildgebung, große E-Commerce-Produktkataloge — ist das Hardcoding hoher Upload-Limits in eine Shared-Server-Konfiguration keine nachhaltige Architektur. Ziehen Sie folgende Alternativen in Betracht:

• Chunked Uploads: Teilen Sie große Dateien clientseitig mithilfe von Bibliotheken wie Resumable.js oder Uppy in kleinere Teile auf. Jeder Teil liegt innerhalb des Server-Limits, und der Server setzt sie wieder zusammen. Dies umgeht 413 vollständig.
• Direkte Uploads in Object Storage: Generieren Sie eine vorzeichnete URL für S3-kompatiblen Speicher und lassen Sie den Client direkt hochladen, wodurch Ihr Webserver vollständig umgangen wird. Der Webserver verarbeitet nur die Metadaten-Transaktion.
• Dedizierte Upload-Endpunkte: Konfigurieren Sie einen separaten location-Block in Nginx mit einem höheren client_max_body_size speziell für Upload-Routen, während das Standard-Limit für alle anderen Endpunkte restriktiv bleibt.

Für rechenintensive Workloads mit großer Dateiverarbeitung — Video-Transcoding, Machine-Learning-Inferenz auf hochgeladenen Daten — bietet eine GPU Hosting-Umgebung die Verarbeitungskapazität, um sowohl den Upload als auch die anschließende Berechnung ohne Engpässe zu bewältigen.

Wenn Ihre Anwendung eine verwaltete Control-Panel-Umgebung mit vollem PHP-Konfigurationszugriff benötigt, bietet ein VPS mit cPanel den MultiPHP INI Editor in WHM, der domänenspezifische PHP-Direktiven-Überschreibungen ohne Kommandozeilenzugriff ermöglicht.

Sicherheitsüberlegungen beim Erhöhen von Upload-Limits

Das Erhöhen von Upload-Limits ohne entsprechende Sicherheitshärtung schafft eine reale Angriffsfläche. Ein Server, der 500MB POST-Anfragen akzeptiert, ist ein potenzielles Ziel für Denial-of-Service-Angriffe, die Festplatten-I/O, Arbeitsspeicher oder Verbindungspools erschöpfen.

Implementieren Sie die folgenden Maßnahmen zusammen mit jeder Limit-Erhöhung:

• Rate Limiting auf Upload-Endpunkten: Verwenden Sie in Nginx limit_req_zone, um die Upload-Häufigkeit pro IP zu begrenzen.
• Dateitypvalidierung: Verlassen Sie sich niemals auf den vom Client angegebenen MIME-Typ. Validieren Sie Dateisignaturen (Magic Bytes) serverseitig.
• Upload-Verzeichnisberechtigungen: Das Verzeichnis, das Uploads empfängt, darf nicht über das Web zugänglich oder ausführbar sein. Speichern Sie Uploads außerhalb des Document Root.
• Virenscan: Integrieren Sie ClamAV oder einen ähnlichen Scanner in die Upload-Pipeline für jeden öffentlich zugänglichen Upload-Endpunkt.
• Nur authentifizierte Uploads: Verlangen Sie eine Authentifizierung, bevor große Payloads akzeptiert werden. Nicht authentifizierte große Upload-Endpunkte werden trivial missbraucht.

Für Produktionsumgebungen, die sensible hochgeladene Daten verarbeiten, stellt die Kombination Ihrer Hosting-Infrastruktur mit ordnungsgemäß konfigurierten SSL Certificates sicher, dass Dateiübertragungen während der Übertragung verschlüsselt sind und das Abfangen hochgeladener Inhalte verhindert wird.

Technische Entscheidungsmatrix: Die richtige Lösung wählen

Praktische Checkliste zur Behebung von HTTP 413

• Identifizieren Sie die Schicht, die den 413 zurückgibt, mithilfe von curl -v und Server-Fehlerprotokollen, bevor Sie Änderungen vornehmen
• Setzen Sie bei Nginx client_max_body_size im spezifischsten anwendbaren Block (location bevorzugt gegenüber server gegenüber http)
• Stellen Sie sicher, dass post_max_size in php.ini immer größer oder gleich upload_max_filesize ist
• Erhöhen Sie max_input_time und max_execution_time für große Dateien bei langsamen Verbindungen
• Überprüfen Sie, ob .htaccess-Überschreibungen erlaubt sind (AllowOverride All oder AllowOverride Options), bevor Sie sich darauf verlassen
• Überprüfen Sie alle Proxy-Schichten unabhängig voneinander — CDN, Load Balancer und Anwendungsserver setzen Limits jeweils separat durch
• Laden Sie nach jeder Konfigurationsänderung den entsprechenden Dienst neu (nicht nur neu starten) und leeren Sie alle Opcode- oder Seiten-Caches
• Konfigurieren Sie bei WordPress Multisite das Netzwerk-Upload-Limit zusätzlich zu den PHP-Direktiven
• Implementieren Sie Rate Limiting und Dateitypvalidierung, bevor Sie Limits auf öffentlich zugänglichen Upload-Endpunkten erhöhen
• Wenn Shared Hosting den Konfigurationszugriff verhindert, migrieren Sie zu einer VPS Hosting– oder Dedicated Servers-Umgebung für vollständige Kontrolle

Häufig gestellte Fragen

Was ist das Standard-Upload-Limit in Nginx, das einen 413-Fehler verursacht?

Nginx setzt client_max_body_size standardmäßig auf 1MB. Jeder Anfrage-Body, der 1MB überschreitet, gibt einen 413 zurück, sofern diese Direktive nicht explizit in der Nginx-Konfiguration erhöht wird.

Kann ich einen 413-Fehler ohne Root-Zugriff auf den Server beheben?

Auf Shared Hosting können Sie Korrekturen über .htaccess (nur Apache, wenn AllowOverride es erlaubt) oder eine .user.ini-Datei (nur PHP-FPM) versuchen. Wenn der Hosting-Anbieter jedoch restriktive globale Limits gesetzt hat, sind diese Methoden wirkungslos und Sie müssen den Support kontaktieren oder auf einen VPS-Plan upgraden.

Warum schlägt mein Upload fehl, obwohl ich upload_max_filesize in php.ini erhöht habe?

Die häufigste Ursache ist, dass post_max_size auf seinem niedrigeren Standardwert bleibt. PHP wertet das POST-Body-Größenlimit vor dem individuellen Dateigrößenlimit aus, sodass der Upload abgelehnt wird, bevor upload_max_filesize überhaupt geprüft wird. Erhöhen Sie immer beide Direktiven gleichzeitig.

Verursacht Cloudflare 413-Fehler?

Ja. Cloudflare setzt eigene Anfrage-Body-Größenlimits durch: 100MB bei Free- und Pro-Plänen, 200MB bei Business und 500MB bei Enterprise. Wenn Ihre Anfrage diese Limits überschreitet, gibt Cloudflare einen 413 zurück, bevor die Anfrage Ihren Ursprungsserver erreicht. Keine serverseitige Konfigurationsänderung wird dies beheben — Sie müssen entweder Ihren Cloudflare-Plan upgraden, direkten Upload-Bypass (vorzeichnete URLs) verwenden oder Chunked Uploads implementieren.

Wie behebe ich 413 in WordPress auf einem cPanel-Server dauerhaft?

Verwenden Sie den MultiPHP INI Editor in WHM, um upload_max_filesize und post_max_size für die spezifische PHP-Version und Domain zu erhöhen. Überprüfen Sie dann, ob die Änderung in WordPress unter Medien > Neu hinzufügen widergespiegelt wird. Aktualisieren Sie bei WordPress Multisite zusätzlich die maximale Upload-Größe unter Netzwerkverwaltung > Einstellungen. Bei direkter Verwendung des WHM INI Editors sind keine .htaccess– oder wp-config.php-Änderungen erforderlich.