nginx - client_max_body_size no tiene efecto

205

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).

q_no
fuente
44
Hay un problema con client_max_body_size en SSL habilitado. Acabo de tener el mismo problema en la versión nginx durada e ignora esta directiva en conexiones seguras. Todavía estoy buscando solución.
Neolo
14
En caso de que alguien más busque en Google esto: Nginx 1.1.19 (en Ubuntu 12.04) parece ignorar client_max_body_size en la directiva 'http', aunque está bien en 'servidor'. Esto parece haberse introducido en una actualización en los últimos 6 meses más o menos, porque para mí solía funcionar el mismo archivo de configuración en el mismo servidor.
Dave
1
@Dave y si vienes aquí en 2018, esto parece arreglado: client_max_body_sizeen la httpsección tiene el efecto esperado con nginx versión 1.14.1
DomQ
Esto verifica el encabezado de la longitud del contenido (al menos en 1.4.6), por lo que si se carga un archivo grande con una longitud de contenido no establecida o una longitud de contenido establecida en un valor menor que el tamaño máximo del cuerpo, no activará el HTTP 413
Charles L.

Respuestas:

131

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
Nembleton
fuente
20
No funcionó para mí en la ubicación, funcionó en el contexto del servidor. No estoy seguro si fue anulado, no puedo decir.
Dipen
@Dipen: Interesante. ¿Qué versión de NGinx tienes?
nembleton
77
Lo mismo dice Dipen, excepto que no puedo obtenerlo en el servidor {} o en los bloques de ubicación {} ... solo funciona en el contexto http {}. Odd
Robbie
44
Puedo confirmar que solo funciona en nginx / 1.4.1 ejecutándose en Debian GNU / Linux 7.1 (wheezy) en la sección http {}.
Fernando Kosh
La confirmación de la configuración falla cuando se activa httpo la locationconfiguración. Funciona cuando se establece en servernivel. nginx / 1.4.4
AlbertEngelB
104

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
jadik
fuente
24
Te sugiero que uses /etc/init.d/nginx reloaden su lugar. Esto ha agregado beneficios como 'si la configuración es incorrecta', NginX no dejará de funcionar.
Hengjie
¡Gracias, esto fue realmente útil para mí! Resolví mi problema después de piratear con muchas configuraciones diferentes de archivos php.ini, etc.
Yos
Minúscula m trabajó para nosotros. client_max_body_size 100m;
so_mv 01 de
13
@Hengjie Recomendaría usar nginx -t(prueba la sintaxis del archivo de configuración) y luego nginx -s reload(hace la recarga real) en su lugar.
Anoyz
Solo necesito señalar que en mi cuadro vagabundo había dos archivos ini: /etc/php5/cli/php.ini y /etc/php5/fpm/php.ini y la configuración cargada de Symfony era la fpm. Así que no olvides editar este.
Jalal
65

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 :)

JJ
fuente
3
La documentación establece el valor predeterminado como "1 m", que resultó ser 1 megabyte, no 1 megabit. Creo que, aunque todavía no lo he probado, siempre es megabyte.
Thomas
2
@Thomas, sí, siempre ha sido m, no M, por lo que definitivamente es megabyte, porque yo mismo hice una prueba.
CppLearner
1
Gracias a los dos, he eliminado el bit / bit de byte.
JJ
2
A partir de 2018 y nginx versión 1.14.1, esto parece arreglado: client_max_body_sizese cumple en la sección httpsin necesidad de agregarlo en ningún otro lugar.
DomQ
27

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
Qorbani
fuente
12

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

rjha94
fuente
11

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";
    (...)
}
tostada digital
fuente
También me gusta esta idea, pero para mí no funciona de esta manera. Todo lo que puedo hacer es reducir el valor y no aumentarlo a nivel de ubicación.
Geza Turi
4

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.

Adrián Molčan
fuente
3

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ó.

P-Didz
fuente
3

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.

Jeramiah Harland
fuente
3

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.

pangpang
fuente
0

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.

Philippe Gerber
fuente
-2

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.

nathan.xu
fuente
Ese fue mi problema, gracias! Supongo que una instancia de Nginx no salió correctamente. Nunca es malo verificar si se salió de Windowstasklist /fi "imagename eq nginx.exe"
Valery Baranov