nginx - client_max_body_size n'a aucun effet


205

nginx n'arrête pas de dire client intended to send too large body. Google et RTM m'ont indiqué client_max_body_size. Je l'ai défini 200mdans le nginx.confainsi que dans le vhost conf, redémarré Nginx plusieurs fois mais je reçois toujours le message d'erreur.

Ai-je oublié quelque chose? Le backend est php-fpm( max_post_sizeet max_upload_file_sizeest défini en conséquence).


4
Il y a un problème avec client_max_body_size sur SSL activé. Je viens de rencontrer le même problème sur la dernière version de nginx et il ignore cette directive dans les connexions sécurisées. Toujours à la recherche d'une solution.
Neolo

14
Au cas où quelqu'un d'autre googlerait ceci: Nginx 1.1.19 (sur Ubuntu 12.04) semble ignorer client_max_body_size dans la directive 'http', bien que cela soit bien dans 'server'. Cela semble avoir été introduit dans une mise à jour au cours des 6 derniers mois, car pour moi, le même fichier de configuration sur le même serveur fonctionnait.
Dave

1
@Dave et si vous venez ici en 2018, cela semble résolu - client_max_body_sizedans la httpsection a l'effet attendu avec nginx version 1.14.1
DomQ

Cela vérifie l'en-tête de la longueur du contenu (au moins dans 1.4.6), donc si un gros fichier est téléchargé avec une longueur de contenu non définie ou une longueur de contenu définie sur une valeur inférieure à la taille maximale du corps, cela ne déclenchera pas le HTTP 413
Charles L.

Réponses:


131

En suivant la documentation de nginx , vous pouvez définir client_max_body_size 20m (ou toute valeur dont vous avez besoin) dans le contexte suivant:

context: http, server, location

20
Cela n'a pas fonctionné pour moi sur place, a fonctionné dans le contexte du serveur. Je ne sais pas si elle a été remplacée, je ne peux pas le dire.
Dipen

@Dipen: Intéressant. Quelle version de NGinx possédez-vous?
nembleton

7
Idem ce que Dipen a dit, sauf que je ne peux pas l'obtenir dans les blocs serveur {} ou emplacement {} ... cela ne fonctionne que dans le contexte http {}. Odd
Robbie

4
Je peux confirmer que cela ne fonctionne que sur nginx / 1.4.1 fonctionnant sur Debian GNU / Linux 7.1 (wheezy) dans la section http {}.
Fernando Kosh

La confirmation du paramètre échoue lors de l'activation httpou des locationparamètres. Fonctionne lorsqu'il est réglé au serverniveau. nginx / 1.4.4
AlbertEngelB

104

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

J'ai pensé que cela pourrait être utile pour quelqu'un, si j'apportais un petit éclaircissement à ses suggestions. Pour commencer, assurez-vous d'avoir inclus votre directive de téléchargement accrue dans TOUS LES TROIS blocs de définition distincts (serveur, emplacement et http). Chacun doit avoir une entrée de ligne distincte. Le résultat ressemblera à quelque chose comme ça (où le ... reflète d'autres lignes dans le bloc de définition):

http {
    ...
    client_max_body_size 200M;
}    

(dans ma configuration ISPconfig 3, ce bloc se trouve dans le fichier /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(dans ma configuration ISPconfig 3, ces blocs se trouvent dans le fichier /etc/nginx/conf.d/default.conf)

Assurez-vous également que le fichier php.ini de votre serveur est compatible avec ces paramètres NGINX. Dans mon cas, j'ai changé le paramètre dans 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 sur CentOS 6.3, selon The Perfect Server ), vous devrez gérer ces entrées dans plusieurs fichiers distincts. Si votre configuration est similaire à celle de la configuration pas à pas, les fichiers de conf NGINX que vous devez modifier se trouvent ici:

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

Mon fichier php.ini se trouvait ici:

/etc/php.ini

J'ai continué à ignorer le bloc http {} dans le fichier nginx.conf. Apparemment, ignorer cela a eu pour effet de limiter le téléchargement à la limite par défaut de 1M. Après avoir apporté les modifications associées, vous voudrez également être sûr 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

24
Je vous suggère d'utiliser à la /etc/init.d/nginx reloadplace. Cela a ajouté des avantages tels que «si la configuration est incorrecte», NginX n'arrêtera pas de fonctionner.
Hengjie

Merci, cela m'a vraiment aidé! Résolu mon problème après avoir piraté avec de nombreux paramètres de fichiers php.ini, etc.
Yos

Les minuscules ont fonctionné pour nous. client_max_body_size 100m;
so_mv

13
@Hengjie Je recommanderais d'utiliser à la place nginx -t(teste la syntaxe du fichier de configuration) puis nginx -s reload(effectue le rechargement réel).
Anoyz

Il suffit de souligner que dans ma boîte vagabonde, il y avait deux fichiers ini - /etc/php5/cli/php.ini et /etc/php5/fpm/php.ini et la configuration chargée de Symfony était celle de fpm. N'oubliez donc pas de modifier celui-ci.
Jalal

65

Depuis mars 2016 , je suis tombé sur ce problème en essayant de POSTER json sur https (à partir de requêtes python, ce n'est pas important).

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

1. l' httpannuaire

  • Typiquement dans /etc/nginx/nginx.conf

2. le serverrépertoire de votre vhost.

  • Pour les utilisateurs Debian / Ubuntu qui ont installé via apt-get (et d'autres gestionnaires de packages de distribution qui installent nginx avec vhosts par défaut), c'est /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 lui.

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

  • Vous pouvez être plus précis que /, mais si cela ne fonctionne pas du tout, je recommanderais de l'appliquer à /, puis une fois que son fonctionnement sera plus spécifique.

N'oubliez pas - si vous avez SSL, cela vous obligera à définir ce qui précède pour le SSL serveret locationaussi, où que ce soit (idéalement le même que 2. ). J'ai trouvé que si votre client essayait de télécharger sur http, et que vous vous attendiez à ce qu'il obtienne 301 pour https, nginx abandonnerait la connexion avant la redirection en raison du fichier trop volumineux pour le serveur http, donc il doit être dans les deux .

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


3
La documentation indique la valeur par défaut comme "1m" qui s'est avérée être 1 mégaoctet - pas 1 mégabit. Je pense - même si je ne l'ai pas encore testé - c'est toujours mégaoctet.
Thomas

2
@Thomas ouais ça a toujours été m pas M, donc c'est définitivement mégaoctet, parce que j'ai fait un test moi-même.
CppLearner

1
Merci à vous deux - j'ai supprimé le bit / octet.
JJ

2
À partir de 2018 et de la version 1.14.1 de nginx, cela semble corrigé - client_max_body_sizeest honoré dans la section httpsans avoir besoin de l'ajouter ailleurs.
DomQ

27

Vous devez appliquer les modifications suivantes:

  1. Mettez à jour php.ini(recherchez le bon fichier ini phpinfo();) et augmentez post_max_sizeet 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. Mise à jour des paramètres Nginx pour votre site Web et ajouter la client_max_body_sizevaleur dans votre location, httpou le servercontexte.

    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 php-fpmprocessus s'il n'a pas été correctement actualisé par la commande de service. Pour ce faire, vous pouvez obtenir la liste des processus ( ps -elf | grep php-fpm) et les tuer un par un ( kill -9 12345) ou utiliser la commande suivante pour le faire pour vous:

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

12

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 mis dans le bloc http {} et ça marche


11

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), alors ciblez simplement vos modifications dans ce fichier. Cela fonctionne pour moi sur le package 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";
    (...)
}

J'aime aussi cette idée mais pour moi ça ne marche pas comme ça. Tout ce que je peux faire, c'est réduire la valeur et ne pas l'augmenter au niveau de l'emplacement.
Geza Turi

4

J'ai eu un problème similaire récemment et j'ai découvert que cela client_max_body_size 0;pouvait résoudre un tel problème. Cela mettra client_max_body_size à aucune limite. Mais la meilleure pratique consiste à améliorer votre code, il n'est donc pas nécessaire d'augmenter cette limite.


3

En supposant que vous avez déjà défini le client_max_body_size et divers paramètres PHP (upload_max_filesize / post_max_size, etc.) dans les autres réponses, puis redémarré ou rechargé NGINX et PHP sans aucun résultat, exécutez ceci ...

nginx -T

Cela vous donnera toutes les erreurs non résolues dans vos configurations NGINX. Dans mon cas, j'ai eu du mal avec l'erreur 413 pendant toute une journée avant de réaliser qu'il y avait d'autres erreurs SSL non résolues dans la configuration NGINX (chemin incorrect pour les certificats) qui devaient être corrigées. Une fois que j'ai résolu les problèmes non résolus que j'ai obtenus avec 'nginx -T', NGINX rechargé et EUREKA !! Cela l'a corrigé.


3

J'installe un serveur de développement pour jouer avec celui qui reflète notre live 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 message et rien ne fonctionnait. J'ai changé la valeur dans chaque fichier recommandé (nginx.conf, ispconfig.vhost, / sites-available / default, etc.)

Enfin, changer client_max_body_sizemon /etc/nginx/sites-available/apps.vhostet redémarrer nginx est ce qui a fait l'affaire. J'espère que cela aide quelqu'un d'autre.


3

Je rencontre le même problème, mais je n'ai rien trouvé à voir 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. nœud utiliser koa analyser le corps. koa limite la longueur encodée en url.

formLimit: limite du corps encodé en url. Si le corps finit par être supérieur à cette limite, un code d'erreur 413 est renvoyé. La valeur par défaut est 56 Ko.

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


0

A eu le même problème que la client_max_body_sizedirective a été ignoré.

Mon erreur stupide était que j'ai mis un fichier à l'intérieur /etc/nginx/conf.dqui ne s'est pas terminé .conf. Nginx ne les chargera pas par défaut.


-2

Si vous utilisez la version Windows nginx, vous pouvez essayer de tuer tous les processus nginx et le redémarrer pour voir. J'ai rencontré le même problème dans mon environnement, mais je l'ai résolu avec cette solution.


C'était mon problème, merci! Une instance de Nginx n'a pas été fermée correctement, je suppose. Il n'est jamais mauvais de vérifier s'il est sorti sur Windowstasklist /fi "imagename eq nginx.exe"
Valery Baranov
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.