too - nginx try_files

nginx-client_max_body_size no tiene ningún efecto

Question

nginx sigue diciendo que el client intended to send too large body . Google y RTM me indicaron client_max_body_size . Lo configuré a 200m en nginx.conf y también en el vhost conf , reinicié Nginx un par de veces pero sigo recibiendo el mensaje de error.

¿Pasé por alto algo? El backend es php-fpm ( max_post_size y max_upload_file_size se establecen en consecuencia).

Answer 1

A partir de marzo de 2016 , me encontré con este problema tratando de POST json sobre https (de solicitudes de Python, no es que importe).

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

1. el directorio http

• Normalmente en /etc/nginx/nginx.conf

2. el directorio del server en su vhost.

• Para los usuarios de Debian / Ubuntu que instalaron vía apt-get (y otros administradores de paquetes de distribución que instalan nginx con vhosts por defecto), eso es /etc/nginx/sites-available/mysite.com , para aquellos que no tienen fantasmas, es probable que su nginx.conf o en el mismo directorio que él.

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

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

Recuerde : si tiene SSL, esto requerirá que configure lo anterior para el server SSL y la location también, donde sea que eso sea (idealmente lo mismo que 2. ). Descubrí que si su cliente intenta cargar en http y espera que sean 301 en https, nginx desconectará la conexión antes de redirigir debido a que el archivo es demasiado grande para el servidor http, por lo que debe ser en ambos .

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

Answer 2

Alguien me corrige si esto es malo, pero me gusta bloquear todo lo posible tanto como sea posible, y si solo tienes un objetivo para las cargas (como suele ser el caso), solo debes dirigir tus cambios a ese único 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";
    (...)
}

Answer 3

Debe aplicar los siguientes cambios:

1. Actualice php.ini (Encuentre el archivo ini correcto desde phpinfo(); ) y aumente los post_max_size y upload_max_filesize al 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. Actualice la configuración de NginX para su sitio web y agregue el valor de client_max_body_size en su location , http o contexto del server .

   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 todas las veces) necesita matar el proceso php-fpm si no se actualizó correctamente por el comando de servicio. Para hacer eso puedes obtener una lista de procesos ( ps -elf | grep php-fpm ) y matar uno por uno ( kill -9 12345 ) o usar el siguiente comando para hacerlo por ti:

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

Answer 4

Las cargas grandes de NGINX están funcionando con éxito en sitios alojados de WordPress, finalmente (según las sugerencias de nembleton & rjha94)

Pensé que podría ser útil para alguien, si añadí un poco de aclaración a sus sugerencias. Para empezar, asegúrese de haber incluido su directiva de aumento de carga en TODOS 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 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 estas configuraciones de NGINX. En mi caso, cambié la configuración en la sección File_Uploads de php.ini para que diga:

upload_max_filesize = 200M

Nota: si está administrando una configuración ISPconfig 3 (mi configuración está en CentOS 6.3, según The Perfect Server ), necesitará administrar estas entradas en varios archivos separados. Si su configuración es similar a una en 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 deberá 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

Answer 5

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

Answer 6

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.

Answer 7

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

Answer 8

Tuve el mismo problema que la directiva client_max_body_size fue ignorada.

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