nginx - client_max_body_size hat keine Auswirkungen

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

• Normalerweise in /etc/nginx/nginx.conf

2. Das Verzeichnis server in Ihrem vhost.

• Für Debian/Ubuntu-Benutzer, die über apt-get installiert haben (und andere Distributionspaket-Manager, die nginx standardmäßig mit vhosts installieren), ist /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.  

• Sie können genauer als / 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:

1. 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```
   

2. 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;
       ...
   }
   

3. 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.