nginx - client_max_body_size no tiene efecto

nginx sigue diciendo client intended to send too large body. Google y RTM me señalaron client_max_body_size. Me puse a 200men el nginx.conf, así como en el vhost confNginx, reiniciar un par de veces, pero todavía estoy recibiendo el mensaje de error.

¿Pasé por alto algo? El backend es php-fpm( max_post_sizey max_upload_file_sizese configuran en consecuencia).

Siguiendo la documentación de nginx , puede establecer client_max_body_size 20m (o cualquier valor que necesite) en el siguiente contexto:

context: http, server, location

Finalmente, las cargas grandes de NGINX funcionan con éxito en sitios alojados de WordPress (según las sugerencias de nembleton y rjha94)

Pensé que podría ser útil para alguien, si añadía un poco de aclaración a sus sugerencias. Para empezar, asegúrese de haber incluido su directiva de aumento de carga en los TRES bloques de definición separados (servidor, ubicación y http). Cada uno debe tener una entrada de línea separada. Al resultado le gustará algo como esto (donde el ... refleja otras líneas en el bloque de definición):

http {
    ...
    client_max_body_size 200M;
}    

(en mi configuración de ISPconfig 3, este bloque está en el archivo /etc/nginx/nginx.conf)

server {
    ...
    client_max_body_size 200M;
}

location / {
    ...
    client_max_body_size 200M;
} 

(en mi configuración de ISPconfig 3, estos bloques están en el archivo /etc/nginx/conf.d/default.conf)

Además, asegúrese de que el archivo php.ini de su servidor sea coherente con esta configuración de NGINX. En mi caso, cambié la configuración en la sección File_Uploads de php.ini para leer:

upload_max_filesize = 200M

Nota: si está administrando una configuración de ISPconfig 3 (mi configuración es en CentOS 6.3, según The Perfect Server ), deberá administrar estas entradas en varios archivos separados. Si su configuración es similar a la de la configuración paso a paso, los archivos conf de NGINX que necesita modificar se encuentran aquí:

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

Mi archivo php.ini se encuentra aquí:

/etc/php.ini

Continué pasando por alto el bloque http {} en el archivo nginx.conf. Aparentemente, pasar por alto esto tuvo el efecto de limitar la carga al límite predeterminado de 1M. Después de realizar los cambios asociados, también querrá asegurarse de reiniciar sus servicios NGINX y PHP FastCGI Process Manager (PHP-FPM). En la configuración anterior, uso los siguientes comandos:

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

A partir de marzo de 2016 , me encontré con este problema tratando de PUBLICAR json a través de https (desde solicitudes de Python, no es que importe).

El truco es poner "client_max_body_size 200M;" en al menos dos lugares http {}yserver {} :

1. el httpdirectorio

• Típicamente en /etc/nginx/nginx.conf

2. el serverdirectorio en su vhost.

• Para los usuarios de Debian / Ubuntu que instalaron a través de apt-get (y otros administradores de paquetes de distribución que instalan nginx con vhosts de forma predeterminada), es decir /etc/nginx/sites-available/mysite.com, para aquellos que no tienen vhosts, probablemente sea su nginx.conf o en el mismo directorio que él.

3. el location /directorio en el mismo lugar que 2.

• Puede ser más específico que /, pero si no funciona, recomendaría aplicar esto /y luego, una vez que funcione, sea más específico.

Recuerde : si tiene SSL, eso requerirá que configure lo anterior para SSL servery locationtambién, donde sea que sea (idealmente lo mismo que 2. ). Descubrí que si su cliente intenta cargar en http y espera que obtenga 301 a https, nginx realmente cortará la conexión antes de la redirección debido a que el archivo es demasiado grande para el servidor http, por lo que debe ser en tanto .

Los comentarios recientes sugieren que hay un problema con esto en SSL con las nuevas versiones de nginx, pero estoy en 1.4.6 y todo está bien :)

Debe aplicar los siguientes cambios:

1. Actualice php.ini(Encuentre el archivo ini correcto phpinfo();) y aumente post_max_sizey upload_max_filesizeal tamaño que desee:

   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. Actualización de Nginx configuración de su sitio web y añadir client_max_body_sizevalor en su location, httpo servercontexto.

   location / {
       client_max_body_size 200m;
       ...
   }
   

3. Reinicie NginX y PHP-FPM:

   service nginx restart
   service php5-fpm restart
   

NOTA: En algún momento (en mi caso, casi siempre) debe matar el php-fpmproceso si no se actualizó correctamente mediante el comando de servicio. Para hacerlo, puede obtener la lista de procesos ( ps -elf | grep php-fpm) y matar uno por uno ( kill -9 12345) o usar el siguiente comando para hacerlo por usted:

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

Vea si está configurando la directiva client_max_body_size dentro del bloque http {} y no dentro del bloque de ubicación {}. Lo configuré dentro del bloque http {} y funciona

Alguien me corrige si esto es malo, pero me gusta bloquear todo lo más posible, y si solo tiene un objetivo para las cargas (como suele ser el caso), entonces solo dirija sus cambios a ese archivo. Esto funciona para mí en el paquete 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";
    (...)
}

Tuve un problema similar recientemente y descubrí que client_max_body_size 0;puede resolver ese problema. Esto establecerá client_max_body_size en ningún límite. Pero la mejor práctica es mejorar su código, por lo que no hay necesidad de aumentar este límite.

Suponiendo que ya ha configurado client_max_body_size y varias configuraciones de PHP (upload_max_filesize / post_max_size, etc.) en las otras respuestas, reinicie o vuelva a cargar NGINX y PHP sin ningún resultado, ejecute esto ...

nginx -T

Esto le dará cualquier error no resuelto en sus configuraciones de NGINX. En mi caso, luché con el error 413 durante todo un día antes de darme cuenta de que había otros errores SSL no resueltos en la configuración de NGINX (ruta incorrecta para los certificados) que debían corregirse. ¡Una vez que solucioné los problemas no resueltos que recibí de 'nginx -T', volví a cargar NGINX y EUREKA! Eso lo arregló.

Estoy configurando un servidor de desarrollo para jugar que refleja nuestro obsoleto en vivo, utilicé The Perfect Server - Ubuntu 14.04 (nginx, BIND, MySQL, PHP, Postfix, Dovecot e ISPConfig 3)

Después de experimentar el mismo problema, me encontré con esta publicación y nada funcionaba. Cambié el valor en cada archivo recomendado (nginx.conf, ispconfig.vhost, / sites-available / default, etc.)

Finalmente, cambiar client_max_body_sizeen my /etc/nginx/sites-available/apps.vhosty reiniciar nginx es lo que funcionó. Esperemos que ayude a alguien más.

Me encuentro con el mismo problema, pero no encontré nada que ver con nginx. Estoy usando nodejs como servidor de fondo, uso nginx como proxy inverso, el servidor de nodo activa el código 413. uso del nodo koa analizar el cuerpo. koa limita la longitud codificada en urlen.

formLimit: límite del cuerpo codificado en urlen. Si el cuerpo termina siendo mayor que este límite, se devuelve un código de error 413. El valor predeterminado es 56kb.

establecer formLimit en más grande puede resolver este problema.

Tenía el mismo problema que la client_max_body_sizedirectiva fue ignorada.

Mi error tonto fue que puse un archivo dentro /etc/nginx/conf.dque no terminó con .conf. Nginx no cargará estos por defecto.

Si está utilizando la versión de Windows nginx, puede intentar eliminar todo el proceso nginx y reiniciarlo para ver. Encontré el mismo problema en mi entorno, pero lo resolví con esta solución.