nginx - client_max_body_size não tem efeito

nginx continua dizendo client intended to send too large body. Googling e RTM me apontaram client_max_body_size. Eu o configurei 200mno Nginx, nginx.confbem como no vhost conf, reiniciei o Nginx algumas vezes, mas ainda estou recebendo a mensagem de erro.

Eu esqueci alguma coisa? O back-end é php-fpm( max_post_sizee max_upload_file_sizeé definido de acordo).

Após a documentação do nginx , você pode definir client_max_body_size 20m (ou qualquer valor necessário) no seguinte contexto:

context: http, server, location

Os uploads grandes do NGINX estão trabalhando com êxito em sites hospedados do WordPress, finalmente (conforme sugestões de nembleton & rjha94)

Eu pensei que poderia ser útil para alguém, se eu adicionasse um pouco de esclarecimento às sugestões deles. Para iniciantes, verifique se você incluiu sua diretiva de upload aumentada em TODOS OS TRÊS blocos de definição separados (servidor, local e http). Cada um deve ter uma entrada de linha separada. O resultado será algo assim (onde o ... reflete outras linhas no bloco de definição):

http {
    ...
    client_max_body_size 200M;
}    

(na minha configuração do ISPconfig 3, este bloco está no arquivo /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(na minha configuração do ISPconfig 3, esses blocos estão no arquivo /etc/nginx/conf.d/default.conf)

Além disso, verifique se o arquivo php.ini do seu servidor é consistente com essas configurações do NGINX. No meu caso, alterei a configuração na seção File_Uploads do php.ini para ler:

upload_max_filesize = 200M

Nota: se você estiver gerenciando uma instalação do ISPconfig 3 (minha instalação é no CentOS 6.3, conforme The Perfect Server ), será necessário gerenciar essas entradas em vários arquivos separados. Se sua configuração for semelhante à configuração passo a passo, os arquivos conf NGINX que você precisa modificar estão localizados aqui:

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

Meu arquivo php.ini estava localizado aqui:

/etc/php.ini

Continuei a ignorar o bloco http {} no arquivo nginx.conf. Aparentemente, ignorar isso teve o efeito de limitar o upload ao limite padrão de 1 milhão. Após fazer as alterações associadas, você também deve reiniciar os serviços NGINX e PHP FastCGI Process Manager (PHP-FPM). Na configuração acima, eu uso os seguintes comandos:

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

Em março de 2016 , deparei-me com este problema ao tentar POST o json por https (a partir de solicitações python, não que isso importe).

O truque é colocar "client_max_body_size 200M;" em pelo menos dois lugares http {}eserver {} :

1. o httpdiretório

• Normalmente em /etc/nginx/nginx.conf

2. o serverdiretório em seu vhost.

• Para usuários do Debian / Ubuntu que instalaram via apt-get (e outros gerenciadores de pacotes de distribuição que instalam o nginx com vhosts por padrão), isso é /etc/nginx/sites-available/mysite.com, para aqueles que não têm vhosts, provavelmente é o seu nginx.conf ou no mesmo diretório.

3. o location /diretório no mesmo local que 2.

• Você pode ser mais específico do que /, mas, se não estiver funcionando, recomendo aplicar isso /e, depois que o trabalho for mais específico.

Lembre -se - se você tiver SSL, isso exigirá que você defina o acima para o SSL servere locationtambém, onde quer que seja (idealmente o mesmo que 2. ). Descobri que se o seu cliente tenta fazer o upload no http e você espera que ele seja enviado 301 para https, o nginx eliminará a conexão antes do redirecionamento, devido ao arquivo ser muito grande para o servidor http, portanto, ele deve ser em ambos .

Comentários recentes sugerem que há um problema com isso no SSL nas versões mais recentes do nginx, mas eu estou no 1.4.6 e está tudo bem :)

Você precisa aplicar as seguintes alterações:

1. Atualize php.ini(encontre o arquivo ini correto phpinfo();) e aumente post_max_sizee upload_max_filesizedimensione o tamanho desejado:

   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. Atualização Nginx configurações para o seu site e adicionar client_max_body_sizevalor no seu location, httpou servercontexto.

   location / {
       client_max_body_size 200m;
       ...
   }
   

3. Reinicie o NginX e o PHP-FPM:

   service nginx restart
   service php5-fpm restart
   

NOTA: Em algum momento (no meu caso quase sempre), você precisará interromper o php-fpmprocesso se ele não for atualizado corretamente pelo comando de serviço. Para fazer isso, você pode obter a lista de processos ( ps -elf | grep php-fpm) e matar um por um ( kill -9 12345) ou usar o seguinte comando para fazer isso por você:

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

Por favor, veja se você está definindo a diretiva client_max_body_size dentro do bloco http {} e não no local {}. Eu configurei dentro do bloco http {} e funciona

Alguém me corrija se isso for ruim, mas eu gosto de bloquear tudo o máximo possível e, se você tiver apenas um destino para uploads (como geralmente é o caso), basta direcionar suas alterações para esse arquivo. Isso funciona para mim no pacote 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";
    (...)
}

Eu tive um problema semelhante recentemente e descobri que isso client_max_body_size 0;pode resolver esse problema. Isso definirá client_max_body_size como sem limite. Mas a melhor prática é melhorar seu código, portanto, não há necessidade de aumentar esse limite.

Supondo que você já tenha definido o client_max_body_size e várias configurações do PHP (upload_max_filesize / post_max_size, etc) nas outras respostas, reiniciado ou recarregado o NGINX e o PHP sem nenhum resultado, execute isso ...

nginx -T

Isso fornecerá erros não resolvidos nas configurações do NGINX. No meu caso, lutei com o erro 413 por um dia inteiro antes de perceber que havia outros erros SSL não resolvidos na configuração do NGINX (caminho incorreto para certs) que precisavam ser corrigidos. Depois de corrigir os problemas não resolvidos que recebi do 'nginx -T', recarreguei o NGINX e o EUREKA !! Isso consertou.

Estou configurando um servidor dev para brincar com esse que reflete nosso servidor desatualizado, usei o servidor perfeito - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot e ISPConfig 3)

Depois de enfrentar o mesmo problema, me deparei com este post e nada estava funcionando. Alterei o valor em todos os arquivos recomendados (nginx.conf, ispconfig.vhost, / sites-available / default, etc.)

Finalmente, mudar o client_max_body_sizemeu /etc/nginx/sites-available/apps.vhoste reiniciar o nginx foi o que fez o truque. Espero que ajude alguém.

Encontro o mesmo problema, mas não achei nada a ver com o nginx. Estou usando o nodejs como servidor back-end, use o nginx como um proxy reverso, o código 413 é acionado pelo servidor do nó. nó use koa analisar o corpo. koa limita o comprimento do código de URL.

formLimit: limite do corpo codificado em url. Se o corpo acabar sendo maior que esse limite, um código de erro 413 será retornado. O padrão é 56kb.

definir formLimit para maior pode resolver esse problema.

Teve o mesmo problema que o client_max_body_size diretiva foi ignorada.

Meu erro bobo foi que eu coloquei um arquivo dentro do /etc/nginx/conf.dqual não terminava .conf. O Nginx não os carregará por padrão.

Se você estiver usando a versão nginx do Windows, poderá tentar matar todo o processo nginx e reiniciá-lo para ver. Encontrei o mesmo problema no meu ambiente, mas resolvi-o com esta solução.