web-dev-qa-db-fra.com

nginx - client_max_body_size n'a aucun effet

nginx n'arrête pas de dire client intended to send too large body. Googling et RTM m'ont indiqué client_max_body_size. Je l'ai mis à 200m dans le nginx.conf ainsi que dans le vhost conf, redémarré Nginx plusieurs fois, mais le message d'erreur persiste.

Ai-je oublié quelque chose? Le backend est php-fpm (max_post_size et max_upload_file_size sont définis en conséquence).

nginx
167
q_no

Après documentation nginx , vous pouvez définir client_max_body_size 20m (ou toute autre valeur nécessaire) dans le contexte suivant:

context: http, server, location
118
nembleton

Les envois volumineux de NGINX fonctionnent avec succès sur les sites WordPress hébergés, enfin (selon les suggestions de nembleton et rjha94)

Je pensais que cela pourrait être utile pour quelqu'un si j'apportais une petite clarification à leurs suggestions. Pour commencer, veuillez vous assurer que vous avez inclus votre directive de chargement accru dans TOUS TROIS blocs de définition distincts (serveur, emplacement et http). Chacun devrait avoir une entrée de ligne séparée. Le résultat ressemblera à quelque chose comme ceci (où le ... reflète les autres lignes du bloc de définition): 

http {
    ...
    client_max_body_size 200M;
}

(dans mon installation ISPconfig 3, ce bloc est dans le fichier /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
}

(dans mon installation ISPconfig 3, ces blocs sont dans le fichier /etc/nginx/conf.d/default.conf)

Assurez-vous également que le fichier php.ini de votre serveur est cohérent avec ces paramètres NGINX. Dans mon cas, j'ai modifié les paramètres de la section File_Uploads de php.ini pour lire: 

upload_max_filesize = 200M

Remarque: si vous gérez une configuration ISPconfig 3 (ma configuration est CentOS 6.3, comme indiqué dans The Perfect Server ), vous devrez gérer ces entrées dans plusieurs fichiers distincts. Si votre configuration est similaire à une configuration pas à pas, les fichiers de configuration NGINX que vous devez modifier se trouvent ici: 

/etc/nginx/nginx.conf
/etc/nginx/conf.d/default.conf

Mon fichier php.ini était situé ici:

/etc/php.ini

J'ai continué à négliger le bloc http {} dans le fichier nginx.conf. Apparemment, ne pas en tenir compte avait pour effet de limiter le téléchargement à la limite par défaut de 1 M. Après avoir apporté les modifications associées, vous voudrez également vous assurer de redémarrer vos services NGINX et PHP FastCGI Process Manager (PHP-FPM). Sur la configuration ci-dessus, j'utilise les commandes suivantes:

/etc/init.d/nginx restart
/etc/init.d/php-fpm restart
83
jadik

À compter du mars 2016 , je me suis heurté à ce problème en essayant de POST json via https (à partir de requêtes python, ce n'est pas important).

L'astuce consiste à mettre "client_max_body_size 200M;" à au moins deux endroits http {} et server {}:

1. le répertoire http

  • Typiquement dans /etc/nginx/nginx.conf

2. le répertoire server dans votre vhost.

  • Pour les utilisateurs de Debian/Ubuntu qui ont installé via apt-get (et d’autres gestionnaires de paquets de distribution qui installent nginx avec vhosts par défaut), thats /etc/nginx/sites-available/mysite.com, pour ceux qui n’ont pas de vhosts, c’est probablement votre nginx.conf ou dans le même répertoire que celui-ci. .

3. le répertoire location / au même endroit que 2.  

  • Vous pouvez être plus spécifique que /, mais si cela ne fonctionne pas du tout, je vous recommande d’appliquer cela à /, puis une fois que son fonctionnement sera plus spécifique.

N'oubliez pas - si vous utilisez SSL, vous devrez également définir les paramètres ci-dessus pour les balises SSL server et location également, où que ce soit (idéalement identique à 2. ). J'ai constaté que si votre client essayait de télécharger sur http et que vous vous attendiez à ce qu'il reçoive 301 en https, nginx abandonnera la connexion avant la redirection car le fichier est trop volumineux pour le serveur http. dans les deux.

Des commentaires récents suggèrent qu'il y a un problème avec ceci sur SSL avec les nouvelles versions de nginx, mais je suis sur 1.4.6 et tout va bien :)

54
J.J

Vous devez appliquer les modifications suivantes:

  1. Mettez à jour php.ini (recherchez le fichier INI de droite dans phpinfo();) et augmentez post_max_size et upload_max_filesize à la taille souhaité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. Mettez à jour les paramètres NginX de votre site Web et ajoutez la valeur client_max_body_size dans votre contexte location, http ou server.

    location / {
    client_max_body_size 200m;
    ...
}

  3. Redémarrez NginX et PHP-FPM: 

    service nginx restart
service php5-fpm restart

REMARQUE: Parfois (dans mon cas presque chaque fois) vous devez tuer le processus php-fpm s'il n'a pas été actualisé correctement par la commande de service. Pour ce faire, vous pouvez obtenir la liste des processus (ps -elf | grep php-fpm) et tuer un par un (kill -9 12345) ou utiliser la commande suivante pour le faire à votre place:

ps -elf | grep php-fpm | grep -v grep | awk '{ print $4 }' | xargs kill -9
18
Qorbani

Veuillez voir si vous définissez la directive client_max_body_size dans le bloc http {} et non dans le bloc location {}. Je l'ai défini à l'intérieur du bloc http {} et cela fonctionne

11
rjha94

Quelqu'un me corrige si c'est mauvais, mais j'aime tout verrouiller autant que possible, et si vous n'avez qu'une seule cible pour les téléchargements (comme c'est généralement le cas), ciblez simplement vos modifications dans ce fichier. Cela fonctionne pour moi sur le paquet Ubuntu nginx-extras mainline 1.7+:

location = /upload.php {
    client_max_body_size 102M;
    fastcgi_param PHP_VALUE "upload_max_filesize=102M \n post_max_size=102M";
    (...)
}
10
digitaltoast

En supposant que vous ayez déjà défini client_max_body_size et divers paramètres PHP (upload_max_filesize/post_max_size, etc.) dans les autres réponses, puis redémarrez ou rechargez NGINX et PHP, exécutez cette opération ...

nginx -T

Cela vous donnera toutes les erreurs non résolues dans vos configs NGINX. Dans mon cas, j'ai eu des difficultés avec l'erreur 413 pendant une journée entière avant de me rendre compte qu'il y avait d'autres erreurs SSL non résolues dans la configuration de NGINX (mauvais chemin pour les certs) qui devaient être corrigées. Une fois que j'ai résolu les problèmes non résolus que j'ai eus de 'nginx -T', j'ai rechargé NGINX et EUREKA !! Cela l'a corrigé.

1
P-Didz

Je suis en train de configurer un serveur de développement pour jouer avec celui qui correspond à notre version obsolète, j’ai utilisé The Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot et ISPConfig 3)

Après avoir rencontré le même problème, je suis tombé sur ce post et rien ne fonctionnait. J'ai changé la valeur dans chaque fichier recommandé (nginx.conf, ispconfig.vhost,/sites-available/default, etc.)

Finalement, changer client_max_body_size dans mon /etc/nginx/sites-available/apps.vhost et redémarrer nginx est ce qui a fait l’essentiel. Espérons que cela aide quelqu'un d'autre.

1
Jeramiah Harland

Je rencontre le même problème, mais je n'ai rien trouvé à faire avec nginx. J'utilise nodejs comme serveur principal, j'utilise nginx comme proxy inverse, le code 413 est déclenché par le serveur de noeud. utilisation de noeud koa parse le corps. koa limite la longueur codée par url.

formLimit: limite du corps codé en url. Si le corps finit par dépasser cette limite, un code d'erreur 413 est renvoyé. La valeur par défaut est 56 Ko.

définir formLimit à plus grand peut résoudre ce problème.

1
pangpang

J'ai eu un problème similaire récemment et ai découvert que client_max_body_size 0; peut résoudre un tel problème. Cela définira client_max_body_size sur aucune limite. Cependant, la meilleure pratique consiste à améliorer votre code. Il n'est donc pas nécessaire d'augmenter cette limite.

0
Adrián Molčan

Avait le même problème que la directive client_max_body_size a été ignorée.

Mon erreur idiote a été de placer un fichier dans /etc/nginx/conf.d qui ne finissait pas par .conf. Nginx ne les chargera pas par défaut.

0
Philippe Gerber