nginx sagt immer client intended to send too large body
. Googling und RTM wiesen mich auf client_max_body_size
. Ich habe es auf 200m
in nginx.conf
sowie in vhost conf
gesetzt, Nginx ein paar Mal neu gestartet, aber ich erhalte immer noch die Fehlermeldung.
Habe ich etwas übersehen? Das Backend ist php-fpm
(max_post_size
und max_upload_file_size
sind entsprechend gesetzt).
Nach der nginx-Dokumentation können Sie client_max_body_size 20m (oder einen beliebigen Wert, den Sie benötigen) im folgenden Kontext festlegen:
context: http, server, location
NGINX große Uploads funktionieren schließlich erfolgreich auf gehosteten WordPress-Sites (gemäß den Vorschlägen von nembleton & rjha94).
Ich dachte, es könnte für jemanden hilfreich sein, wenn ich ihren Vorschlägen eine kleine Klarstellung hinzufüge. Für den Anfang sollten Sie sich vergewissern, dass Sie Ihre erweiterte Upload-Anweisung in ALL THREE separaten Definitionsblöcken (Server, Standort & http) enthalten haben. Jeder sollte einen separaten Zeileneintrag haben. Das Ergebnis wird in etwa so aussehen (wobei ... die anderen Zeilen des Definitionsblocks widerspiegelt):
http {
...
client_max_body_size 200M;
}
(In meinem ISPconfig 3-Setup befindet sich dieser Block in der Datei /etc/nginx/nginx.conf.)
server {
...
client_max_body_size 200M;
}
location / {
...
client_max_body_size 200M;
}
(In meinem ISPconfig 3-Setup befinden sich diese Blöcke in der Datei /etc/nginx/conf.d/default.conf.)
Stellen Sie außerdem sicher, dass die Datei php.ini Ihres Servers mit diesen NGINX-Einstellungen übereinstimmt. In meinem Fall habe ich die Einstellung im Abschnitt File_Uploads von php.ini geändert, um zu lesen:
upload_max_filesize = 200M
Hinweis: Wenn Sie ein ISPconfig 3-Setup verwalten (mein Setup ist unter The Perfect Server auf CentOS 6.3), müssen Sie diese Einträge in mehreren separaten Dateien verwalten. Wenn Ihre Konfiguration der Konfiguration in Schritt für Schritt ähnelt, befinden sich hier die NGINX-Conf-Dateien, die Sie ändern müssen:
/etc/nginx/nginx.conf
/etc/nginx/conf.d/default.conf
Meine php.ini-Datei befindet sich hier:
/etc/php.ini
Ich übersah den http {} -Block in der Datei nginx.conf weiterhin. Anscheinend hatte das Übersehen dieses Problems den Upload auf das Standardlimit von 1M begrenzt. Nachdem Sie die entsprechenden Änderungen vorgenommen haben, möchten Sie auch sicher sein, dass Sie die Dienste NGINX und PHP FastCGI Process Manager (PHP-FPM) neu starten. In der obigen Konfiguration verwende ich die folgenden Befehle:
/etc/init.d/nginx restart
/etc/init.d/php-fpm restart
Seit März 2016 bin ich auf dieses Problem gestoßen und habe versucht, POST über https zu jsonieren (von Python-Anfragen, nicht dass es wichtig ist).
Der Trick besteht darin, "client_max_body_size 200M;" an mindestens zwei Stellen http {}
und server {}
:
1. das Verzeichnis http
/etc/nginx/nginx.conf
2. Das Verzeichnis server
in Ihrem vhost.
/etc/nginx/sites-available/mysite.com
, für diejenigen, die keine vhosts haben, wahrscheinlich die Datei nginx.conf oder das gleiche Verzeichnis . 3. das location /
-Verzeichnis an derselben Stelle wie 2.
/
sein, aber wenn es überhaupt nicht funktioniert, würde ich empfehlen, dies auf /
anzuwenden und dann einmal genauer zu arbeiten. Denken Sie daran - Wenn Sie über SSL verfügen, müssen Sie die SSL-Variablen server
und location
auch dort festlegen, wo dies möglich ist (idealerweise dasselbe wie 2. ). Ich habe festgestellt, dass, wenn Ihr Client versucht, auf http hochzuladen, und Sie davon ausgehen, dass er 301-zu-https erhält, die Verbindung vor der Weiterleitung durch Nginx unterbrochen wird, weil die Datei für den http-Server zu groß ist in beide.
Neuere Kommentare deuten darauf hin, dass ein Problem mit SSL in neueren Nginx-Versionen vorliegt, aber ich bin auf 1.4.6 und alles ist gut :)
Sie müssen die folgenden Änderungen anwenden:
Aktualisieren Sie php.ini
(Finden Sie die rechte Ini-Datei von phpinfo();
) und erhöhen Sie post_max_size
und upload_max_filesize
auf die gewünschte Größe:
sed -i "s/post_max_size =.*/post_max_size = 200M/g" /etc/php5/fpm/php.ini
sed -i "s/upload_max_filesize =.*/upload_max_filesize = 200M/g" /etc/php5/fpm/php.ini```
Aktualisieren Sie die NginX-Einstellungen für Ihre Website, und fügen Sie in Ihrem Kontext location
, http
oder server
den Wert client_max_body_size
hinzu.
location / {
client_max_body_size 200m;
...
}
Starten Sie NginX und PHP-FPM neu:
service nginx restart
service php5-fpm restart
ANMERKUNG: Irgendwann (in meinem Fall fast jedes Mal) müssen Sie den php-fpm
-Prozess beenden, wenn er nicht ordnungsgemäß durch den Dienstbefehl aktualisiert wurde. Dazu können Sie eine Liste der Prozesse (ps -elf | grep php-fpm
) abrufen und einen nach dem anderen beenden (kill -9 12345
) oder den folgenden Befehl verwenden, um dies für Sie auszuführen:
ps -elf | grep php-fpm | grep -v grep | awk '{ print $4 }' | xargs kill -9
Bitte überprüfen Sie, ob Sie die client_max_body_size -Direktive innerhalb des http {} - Blocks und nicht innerhalb des location {} - Blocks setzen. Ich habe es in http {} gesetzt und es funktioniert
Jemand korrigiert mich, wenn dies schlecht ist, aber ich sperre alles so gut wie möglich ein. Wenn Sie nur ein Ziel für Uploads haben (wie es normalerweise der Fall ist), zielen Sie Ihre Änderungen einfach auf diese eine Datei. Dies funktioniert für mich mit dem Ubuntu nginx-extras mainline 1.7+ Paket:
location = /upload.php {
client_max_body_size 102M;
fastcgi_param PHP_VALUE "upload_max_filesize=102M \n post_max_size=102M";
(...)
}
Angenommen, Sie haben bereits client_max_body_size und verschiedene PHP -Einstellungen (upload_max_filesize/post_max_size usw.) in den anderen Antworten festgelegt, dann NGINX und PHP ohne Ergebnis neu gestartet oder neu geladen, führen Sie Folgendes aus ...
nginx -T
Dadurch erhalten Sie alle nicht aufgelösten Fehler in Ihren NGINX-Konfigurationen. In meinem Fall hatte ich einen ganzen Tag lang mit dem 413-Fehler zu kämpfen, bevor mir klar wurde, dass einige andere ungelöste SSL-Fehler in der NGINX-Konfiguration (falscher Pfad für Zertifikate) korrigiert werden mussten. Nachdem ich die ungelösten Probleme behoben hatte, erhielt ich von 'nginx -T', nachgeladenen NGINX und EUREKA !! Das hat es behoben.
Ich bin dabei, einen Dev-Server einzurichten, mit dem unser veralteter Live-Server gespiegelt wird. Ich verwendete The Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot und ISPConfig 3) .
Nachdem ich das gleiche Problem hatte, stieß ich auf diesen Beitrag und nichts funktionierte. Ich habe den Wert in jeder empfohlenen Datei geändert (nginx.conf, ispconfig.vhost,/sites-available/default usw.).
Abschließend änderte der client_max_body_size
in meinem /etc/nginx/sites-available/apps.vhost
und der Neustart von nginx den Trick. Hoffentlich hilft es jemand anderem.
Ich habe das gleiche Problem, aber ich habe nichts mit Nginx zu tun. Ich benutze nodejs als Backend-Server, benutze Nginx als Reverse-Proxy, 413-Code wird vom Knotenserver ausgelöst. Knoten benutze koa parse den Körper. koa begrenzen die urlencodierte Länge.
formLimit: Grenze des urlencodierten Körpers. Wenn der Body letztendlich größer als diese Grenze ist, wird ein 413-Fehlercode zurückgegeben. Die Standardeinstellung ist 56kb.
wenn Sie formLimit auf Größer setzen, können Sie dieses Problem lösen.
Ich hatte kürzlich ein ähnliches Problem und fand heraus, dass client_max_body_size 0;
ein solches Problem lösen kann. Dies setzt client_max_body_size auf kein Limit. Es wird jedoch empfohlen, den Code zu verbessern, sodass dieses Limit nicht erhöht werden muss.
Hatte das gleiche Problem, dass die client_max_body_size
-Direktive ignoriert wurde.
Mein dummer Fehler war, dass ich eine Datei in /etc/nginx/conf.d
legte, die nicht mit .conf
endete. Nginx lädt diese standardmäßig nicht.