Türkei (Türkisch)
Germany (German)
Worldwide (English)
AnforderungsflussClient, NGINX und Backend-Verbindungsbrempunkt
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
413 Request Entity Too Large zeigt an, dass der Anfragekörper des Clients die von NGINX akzeptierte Grenze überschreitet. Das einfache Erhöhen von client_max_body_size kann nicht ausreichen; PHP, Anwendung, Proxy, CDN und temporäre Disk-Grenzen müssen zusammenpassen.
2026/07/17 03:40:44 [error] 2284#2284: *821 client intended to send too large body: 52429187 bytes, client: 203.0.113.10, request: "POST /wp-admin/async-upload.php HTTP/2.0"NGINX, sendet den Request ohne Backend an, wenn der Wert von client_max_body_size den Request-Body in einem POST/PUT-Request überschreitet und gibt 413 zurück. Dies kann dazu führen, dass in der PHP-Logdatei keine Einträge entstehen.
client_max_body_size kann auf http, server- oder location-Ebene definiert werden. Ein Wert, der in einem engeren Block definiert ist, überschreibt den höheren Level; daher kann die Hinzufügung nur in nginx.conf die effektiven vhost-Einstellungen nicht ändern.
Nachdem der NGINX-Limit erhöht wurde, sollten PHP’s upload_max_filesize und post_max_size, die Anwendungsbeschränkung, Nginx Proxy Manager oder CDN-Beschränkung ebenfalls geprüft werden.
Große Anfragen können in eine temporäre Datei geschrieben werden. Der Upload schlägt fehl, wenn /tmp oder client_body_temp_path voll ist, auch wenn die Grenze ausreichend ist.
Bei unbegrenzten Werten erhöht sich der Ressourcenverbrauch und das Missbrauchsrisiko. Die Obergrenze sollte nur für das jeweilige Domain/Locationsbereich angemessen sein.
Den aktiven Wert nicht erraten; die client_max_body_size-Zeile finden, die für dieselbe Domäne und Location in der nginx -T-Ausgabe angewendet wird.
Suchen Sie nach dem Ausdruck, den Sie in der E-Mail, im Browser oder im SSH-Protokoll sehen. Jede Karte enthält eine Bedeutung, eine wahrscheinliche Ursache und eine sichere erste Maßnahme.
Bedeutung: Der Anfragetext überschreitet die NGINX-Limits.
Mögliche Ursache: client_max_body_size ist kleiner als die hochgeladene Datei.
Bedeutung: NGINX lehnte den Antrag ohne Weiterleitung an den Backend ab.
Mögliche Ursache: Server/Standort-Ebene-Body-Grenze.
Bedeutung: Der gleiche HTTP-Status hat unterschiedliche Anzeigemöglichkeiten.
Mögliche Ursache: NGINX, Proxy oder API-Gateway-Limit.
Bedeutung: Der Datei übersteigt die PHP-Grenze nach NGINX.
Mögliche Ursache: PHP upload_max_filesize ist niedrig.
Bedeutung: Gesamter POST-Körper überschreitet den PHP-Wert post_max_size.
Mögliche Ursache: post_max_size ist kleiner als die Datei- und Formengabe gesamt.
Bedeutung: Vorläufige Upload-Datei konnte nicht geschrieben werden.
Mögliche Ursache: Festplatte oder Inode ist voll.
Bedeutung: Backend-Framework hat seine eigene Body-Grenze angewendet.
Mögliche Ursache: Django/Laravel/Node-ähnliche Anwendungseinstellung.
Bedeutung: Die Anforderung könnte den CDN-Limits vor Erreichen des Ursprungs überschritten haben.
Mögliche Ursache: Plan- oder Proxy-Upload-Grenze.
Es wurden keine Datensätze gefunden, die diesem Ausdruck entsprechen.
Befehle sind für den Root-Zugriff vorgesehen. Sammeln Sie zunächst nur den Status und die Protokolle. Ändern Sie die dauerhafte Einstellung nicht, ohne den Grund dafür zu erkennen.
nginx -T | grep -n 'client_max_body_size'Include-Dateien mit allen Definitionen.
grep -R 'too large body' /var/log/nginx 2>/dev/null | tail -n 100Anfragegröße, URL und Domain werden angezeigt.
php -i | grep -E 'upload_max_filesize|post_max_size|memory_limit|max_execution_time'CLI zeigt PHP-Werte an; Web-PHP muss ebenfalls validiert werden.
df -h
df -i
nginx -T | grep -n 'client_body_temp_path'Überprüft den während des Uploads verwendeten Speicherplatz auf der Festplatte und inode.
curl -sk -o /dev/null -w '%{http_code}\n' -F '[email protected]' https://example.com/yukleFührt einen kontrollierten Upload-Test zum echten Endpunkt durch.
nginx -t && systemctl reload nginxSichert die sichere Umsetzung der neuen Limitierung.
Obwohl die Grundursache des NGINX-Fehlers dieselbe ist, variieren Paketpfade, Dienstnamen, Sicherheitsebenen und die Verwaltung virtueller Hosts je nach verwendeter Linux-Distribution oder Plesk-Infrastruktur.
Systemd, Paketpfad und journald-Prüfunglen für NGINX 413 Request Entity Too Large.
nginx -T | grep -n client_max_body_size
php -i | grep -E 'upload_max_filesize|post_max_size'
tail -n 100 /var/log/nginx/error.logSELinux, PHP-FPM-Pool und RHEL-basierte Dienstkontrollen für NGINX 413 Request Entity Too Large.
nginx -T | grep -n client_max_body_size
php -i | grep -E 'upload_max_filesize|post_max_size'
df -h; df -iNGINX-Virtualhost-Dateien, die von Plesk generiert werden: nginx 413 request entity too large-Prüfungle.
grep -R 'client_max_body_size' /var/www/vhosts/system/example.com/conf /etc/nginx 2>/dev/null
plesk repair web example.com -nMessung und Anpassung der Grenzwerte von welchem Layer die Anfrage von welcher Größe abgelehnt hat und machen Sie sie nur im erforderlichen Umfang kompatibel.
Nicht nur ein Datei, auch die Multipart-Form-Daten-Uploads berücksichtigen.
stat -c '%n %s bytes' test.binFühren Sie separate Tests von Origin und CDN durch.
curl -skI https://example.com/; curl -skI --resolve example.com:443:ORIGIN_IP https://example.com/Überprüfen Sie den kleinsten client_max_body_size-Wert für den gleichen Server/Standort.
nginx -T | grep -nC 4 client_max_body_sizeDie PHP-Einstellung post_max_size und die Anwendungseinstellung dürfen nicht kleiner als der NGINX-Limit sein.
php -i | grep -E 'upload_max_filesize|post_max_size'Großer Body wird auf temporäre Disk geschrieben, benötigt freien Speicherplatz und Inodes.
df -h; df -iNicht nur eine Konfigurationsprüfung, laden Sie Ihre Anwendungsendpunkt hoch.
nginx -t && systemctl reload nginx
curl -sk -F '[email protected]' https://example.com/yukleNGINX, PHP und WordPress Multisite-Limits werden gemeinsam überprüft.
nginx -T | grep client_max_body_size; php -i | grep -E 'upload_max|post_max'Body-Grenze neben PHP-Dauer und Upload-Temp-Bereich ist wichtig.
df -h /tmp; php -i | grep upload_tmp_dirNGINX nachfolgende Framework oder API-Gateway kann Grenzwerte anwenden.
curl -sv -H 'Content-Type: application/json' --data-binary @data.json https://example.com/apiÄnderungen sollten in das container-interne effektive Konfigurations- oder benutzerdefinierte Feld geschrieben werden.
docker exec nginx nginx -T | grep client_max_body_sizeUnterscheiden Sie die CDN-Planbegrenzung mit einer direkten Testung an Origin.
curl --resolve example.com:443:ORIGIN_IP -skI https://example.com/Zusätzliche nginx-Direktiven können in diesem Bereich domänenbasierte Grenzwerte definieren.
plesk repair web example.com -nDer Anforderungskörper überschreitet die client_max_body_size-Einstellung, und NGINX sendet es ohne es an den Backend weiterzugeben zurück mit 413.
In der NGINX Open Source-Dokumentation wird die Standardwert als 1 MB angegeben.
Es kann nach Bedarf als http, server oder der engsten location-Block geschrieben werden. Aus Sicherheitsgründen sollte der engste Umfang bevorzugt werden.
PHP upload_max_filesize, post_max_size, Framework, CDN, Proxy oder Festplattenplatz ist auf eine niedrigere Grenze gesetzt.
0 Limit deaktiviert; es sollte nur in kontrollierten Szenarien in Betracht gezogen werden, da es das Risiko von Missbrauch und Ressourcenverbrauch erhöht.
NGINX-Limit, aktive Web- PHP-Upload-/Post-Beschränkungen und WordPress-Multisite-Upload-Beschränkungen sollten gemeinsam eingestellt werden.
Bei einer Konfigurationsänderung reicht ein Neuladen nach nginx -t in der Regel aus; ein Neustart ist nicht erforderlich.
Durch die gemeinsame Analyse von cPanel, WHM, CloudLinux, LiteSpeed, MariaDB, Exim und Sicherheitsebenen beheben wir die Grundursache des Fehlers, anstatt nur den Dienst zu entfernen.