Beim Upload eines Plugin-ZIPs erscheint HTTP 413, noch bevor WordPress seine übliche Upload-Meldung anzeigen kann. Die Antwort trägt die Kennung des CDN und im PHP-Log fehlt jeder Eintrag. Eine Änderung von upload_max_filesizein WordPress wäre hier wirkungslos, weil die Anfrage PHP nie erreicht. Die richtige Maßnahme beginnt deshalb mit der Frage, welche Schicht die Antwort erzeugt.
Inhalt
Was HTTP 413 bedeutet
HTTP 413 „Content Too Large“ bedeutet, dass der Request-Body die zulässige Größe oder eine Richtlinie überschreitet. Die Antwort kann von CDN, WAF, Load Balancer, Reverse Proxy, Webserver, Hosting-Gateway oder Anwendung stammen. Wird die Anfrage vor PHP abgelehnt, haben WordPress- und PHP-Einstellungen keinen Einfluss. Status, Header, Antworttext und Request-ID helfen bei der Zuordnung.
Ein realistisches Beispiel
Ein kleiner Plugin-Upload funktioniert, ein größeres Archiv erhält 413. Die Antwort enthält einen CDN-spezifischen Header, während Origin- und PHP-Logs leer bleiben. Ein autorisierter Test direkt am Origin nimmt dieselbe Datei an. Damit ist die Grenze am CDN belegt. Sie wird nur für den erforderlichen Admin-Pfad und in einem vertretbaren Umfang angepasst; anschließend werden kleine und große Testdatei erneut über den öffentlichen Weg geprüft.
Warum die verursachende Schicht wichtig ist
Jede Schicht hat eigene Konfiguration, Zuständigkeit und Sicherheitswirkung. Eine globale Erhöhung am falschen Ort ändert den Fehler nicht und kann unnötig große Anfragen zulassen. Umgekehrt muss die nachgelagerte Infrastruktur eine freigegebene größere Payload auch verarbeiten können. Deshalb werden Grenzwerte von außen nach innen untersucht und nur an der ersten ablehnenden Stelle geändert.
Sicherer Einstieg
Notieren Sie URL, Methode, Dateigröße, Zeitpunkt, HTTP-Status und auffällige Antwortheader. Vergleichen Sie eine kleine funktionierende mit der abgelehnten Anfrage. Prüfen Sie anschließend CDN, WAF, Proxy, Webserver, Hosting und PHP in dieser Reihenfolge. Bitten Sie den jeweiligen Anbieter um die kleinste unterstützte, möglichst pfadbezogene Anpassung. Halten Sie eine harmlose reproduzierbare Testdatei bereit.
Technische Diagnose
Erstellen Sie für beide Payloads eine kurze Spur aus Status, Serverkennung, Request-ID und Logeintrag. Die erste Schicht, an der die größere Anfrage auf 413 wechselt, bestimmt den nächsten Schritt. Sobald PHP erreicht wird, müssen post_max_sizeund upload_max_filesizepassend gesetzt sein. Testen Sie knapp unter und über der Zielgröße und kontrollieren Sie dabei CDN-, Server- und PHP-Logs.
Risiken und Rollback
Sehr breite oder globale Größenfreigaben erhöhen Ressourcen- und Missbrauchsrisiken. Beschränken Sie Änderungen daher auf den notwendigen Endpunkt und dokumentieren Sie alten sowie neuen effektiven Wert. Prüfen Sie Upload, Authentifizierung, Malware-Scan, Speicherplatz und Timeout. Bei unerwünschter Last oder Providerablehnung stellen Sie die vorige Richtlinie wieder her und verwenden einen unterstützten Chunk-, CLI- oder Direktupload.
AIOWS-Modul
Wie AIOWS PHP Limits bei einem 413-Fehler einzuordnen ist
AIOWS PHP Limits kann aktive PHP-Werte anzeigen, unterstützte Änderungen versuchen und das wirksame Ergebnis prüfen. Das ist relevant, sobald belegt ist, dass die Anfrage PHP erreicht.
Ein 413-Fehler, der vom CDN, Proxy oder Webserver erzeugt wird, lässt sich damit nicht automatisch beheben. Auch Hosting-Obergrenzen können nicht garantiert überschrieben werden.
Nutzen Sie die Anzeige daher zunächst zur Abgrenzung. Ändern Sie PHP-Werte erst nach einem PHP-Logeintrag oder einem anderen eindeutigen Nachweis und wiederholen Sie anschließend dieselben Payload-Tests.
Weiterführende Beiträge
- Maximale Upload-Dateigröße in WordPress erhöhen
- post_max_size und upload_max_filesize in WordPress
- Maximale PHP-Ausführungszeit in WordPress überschritten
Fazit
Bestimmen Sie den Absender der 413-Antwort, bevor Sie PHP oder WordPress ändern. Passen Sie nur die nachgewiesene Grenze und möglichst nur den benötigten Pfad an. Ist eine vorgelagerte Richtlinie nicht sicher veränderbar, ist ein unterstützter Chunk-, CLI- oder Direktupload zuverlässiger als wirkungslose PHP-Direktiven.
