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

No me dan algo? El backend es php-fpm (max_post_size y max_upload_file_size se establecen en consecuencia).

  • Cómo es de grande tu archivo?
  • No hay problema con client_max_body_size en SSL habilitado. Yo sólo tengo el mismo problema en durado nginx versión y hace caso omiso de la presente directiva en conexiones seguras. Todavía en busca de solución.
  • En caso de que alguien de google esto: Nginx 1.1.19 (en Ubuntu 12.04) parece ignorar client_max_body_size en la ‘http’ directiva, a pesar de que está bien con él en ‘servidor’. Este parece haber sido introducido en una actualización en los últimos 6 meses o así, porque para mí el mismo archivo de configuración en el mismo servidor que se utiliza para trabajar.
  • y si usted viene aquí en 2018, esto parece fijo client_max_body_size en el http sección tiene el efecto esperado con nginx versión 1.14.1
  • Esto comprueba el contenido de la longitud de la cabecera (al menos en 1.4.6), por lo que si un gran archivo es cargado con unset de longitud de contenido, o la longitud del contenido ajustado a un valor menor que el máximo tamaño del cuerpo, no va a desencadenar el HTTP 413
InformationsquelleAutor q_no | 2010-01-13

12 Comentarios

  1. 125

    Siguientes nginx documentación, puede establecer client_max_body_size 20m ( o cualquier valor necesario ) en el siguiente contexto:

    context: http, server, location
    
    • Este consejo fue muy útil
    • No funcionó para mí en el lugar, trabajaron en el contexto del servidor. No estoy seguro si fue siendo reemplazado, no se puede decir.
    • Interesante. ¿Qué versión de NGinx tiene usted?
    • Lo mismo ocurre con lo que Dipen dijo, excepto que no se puede entrar en el servidor{} o ubicación{} los bloques… solo funciona en el http{} contexto. Extraño
    • Puedo confirmar que funciona solamente en nginx/1.4.1 corriendo en Debian GNU/Linux 7.1 (wheezy) en http{} sección.
    • Confirmación de la configuración de error al establecer en http o location configuración. Funciona cuando se establece en el server nivel. nginx/1.4.4
    • Atendiendo a la documentación que debe trabajar en 3 niveles. Tal vez usted tiene un contador de configuración en algún lugar?
    • No estoy seguro. He añadido a nginx.conf en http y fracasó. He comprobado sites-enabled/sites-available y no se ha establecido en cualquiera de los archivos de configuración de cualquiera de los dos. Sólo funcionó para mí después de añadirlo a la específica sites-enabled de configuración en el server nivel. Si lo he probado en el location área, sería un error. Cualquier otro lugar que se ajuste podría ser en conjunto? EDIT: Y esto es prácticamente una instalación limpia también.
    • interesante. El doc menciona ‘m’. ¿Qué sistema estás?
    • A nivel de ubicación, todo lo que puedo hacer es reducir el valor de y no aumentarlo. Ubuntu 16.04.1 LTS
    • Tienen el mismo con 1.10.1 puede reducir el tamaño del archivo de menos de 1m, pero no puede aumentar la eso. Por lo tanto puedo usar 500k, 600k, pero no un 100 o 100 metros. Ubuntu 16

  2. 94

    NGINX grandes cargas están trabajando con éxito en hospedado sitios WordPress, finalmente (como por sugerencias de nembleton & rjha94)

    Pensé que podría ser útil para alguien, si he añadido un poco de aclaración a sus sugerencias. Para empezar, por favor asegúrese de incluir su aumento de la carga de la directiva en TODOS los TRES de definición de bloques (servidor, localización & http). Cada uno debe tener una línea separada de la entrada. El resultado va a gustar algo como esto (donde el … refleja otras líneas en el bloque de definición):

    http {
        ...
        client_max_body_size 200M;
    }    
    

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

    server {
        ...
        client_max_body_size 200M;
    }
    
    location /{
        ...
        client_max_body_size 200M;
    } 
    

    (en mi ISPconfig 3 instalación, estos bloques se encuentran en /etc/nginx/conf.d/default.conf archivo)

    También, asegúrese de que su servidor php.archivo ini es consistente con estos configuración de NGINX. En mi caso, he cambiado la configuración en php.del ini File_Uploads sección para leer:

    upload_max_filesize = 200M
    

    Nota: si la gestión de un sistema de ISPconfig 3 instalación (mi instalación en CentOS 6.3, como por El Perfecto Servidor), será necesario manejar estas entradas en varios archivos separados. Si su configuración es similar a uno en el paso a paso de la instalación, el NGINX conf archivos que necesita para modificar se encuentra aquí:

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

    Mi php.archivo ini se encuentra aquí:

    /etc/php.ini
    

    Seguí a pasar por alto el http {} bloque en el nginx.conf archivo. Al parecer, con vistas a esto tuvo el efecto de limitar la carga a 1M límite predeterminado. Después de hacer los cambios asociados, usted también querrá asegurarse de que reinicie el NGINX y PHP FastCGI el Administrador de Procesos (PHP-FPM) servicios. En la configuración anterior, puedo usar los siguientes comandos:

    /etc/init.d/nginx restart
    /etc/init.d/php-fpm restart
    
    • Propongo utilizar /etc/init.d/nginx reload lugar. Esto tiene beneficios adicionales, tales como «si la configuración es incorrecta’ NginX no deje de funcionar.
    • Gracias esto fue realmente útil para mí! Solucionado mi problema después de cortar a su alrededor con un montón de diferentes php.el archivo ini de configuración, etc.
    • M minúscula trabajado para nosotros. client_max_body_size 100m;
    • Me gustaría recomendar el uso de nginx -t (pruebas de la sintaxis del archivo de configuración) y, a continuación, nginx -s reload (no el real de recarga) en su lugar.
    • Sólo necesito señalar que en mi vagrant cuadro hay dos archivos ini – /etc/php5/cli/php.ini y /etc/php5/fpm/php.ini y Symfony se carga la configuración de la fpm uno. Así que no se olvide de editar este.
    • En mi caso solo necesitas editar el http { } parte. He seguido su enfoque y, a continuación, por curiosidad he quitado la directiva de server {} y location {} y el escenario es todavía válida.
    • Esto hace el trabajo, pero usted debe ejecutar sudo service php5-fpm restart && sudo service nginx restart. Yo era capaz de establecer sólo el http {} bloque, no tenía la necesidad de establecer el servidor {} o ubicación {} bloques incluidos los hosts virtuales. PERO la configuración no volver a cargar hasta que reinicie php y nginx, así como una regla que siempre se ejecuta el comando de arriba si puedo cambiar cualquiera de nginx.conf o php.ini.
    • Para PHP7, Ubuntu 16, el servicio se llama php7.0-fpm, no php-fpm o php7-fpm. Tal vez hay alguna configuración de Ubuntu que habría creado un ‘enlace’ de php-fpm a php7.0-fpm que no me he enterado.
    • Gran solución, esta fijada para mí en Heroku utilizando NodeJS/Nginx. Yo soy mi caso estoy usando AdonisJS, y usted tiene que configurar el límite: ‘200mb’ y el maxSize: ‘200mb’ en el bodyParser.js archivo de configuración y, finalmente, aceptar el tamaño del archivo en su solicitud de código.archivo(‘archivo’, {maxSize: ‘200mb’});
    • Si usted ya es limitar el tamaño de carga en php.ini entonces usted puede desactivar el nginx ‘Content-length’ encabezado de configuración client_max_body_size a 0.
    • Similar a la anterior comentario he encontrado que la adición de sólo a la location bloque fue suficiente.

  3. 61

    Como de de Marzo de 2016, me encontré con este problema tratando de POST json a través de https (desde python solicitudes, pero no importa).

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

    1. el http directorio

    • Normalmente en /etc/nginx/nginx.conf

    2. el server directorio en tu vhost.

    • Para los usuarios de Debian/Ubuntu que se instala a través de apt-get (y otras distros a los gestores de paquetes que instalar nginx con vhosts por defecto), eso es /etc/nginx/sites-available/mysite.com, para aquellos que no tienen vhosts, es probable que su nginx.conf o en el mismo directorio como él.

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

    • Puede ser más específico que /, pero, si no su trabajo a todos, me gustaría recomendar la aplicación de este a / y, a continuación, una vez que su trabajo sea más específica.

    Recordar – si usted tiene SSL, que se requieren para establecer los pasos anteriores para el SSL server y location demasiado, dondequiera que puede ser (el ideal es el mismo que 2.). He encontrado que si el cliente intenta cargar sobre http, y las esperas para obtener 301 d a https, nginx eliminar realmente la conexión antes de que la redirección debido a que el archivo es demasiado grande para el servidor http, así que tiene que ser en tanto.

    Comentarios recientes sugieren que hay un problema con este SSL con los nuevos nginx versiones, pero estoy en la 1.4.6 y todo es bueno 🙂

    • La documentación indica el valor predeterminado como «1m», que resultó ser de 1 megabyte – no de 1 megabit. Creo que – aunque todavía no he probado – es siempre megabyte.
    • sí, siempre ha sido m no M, por lo que definitivamente es megabyte, porque me hizo una prueba a mí mismo.
    • Gracias a ambos – he eliminado el bit/byte bit.
    • A partir de 2018, y nginx versión 1.14.1, esto parece fijo client_max_body_size es honrado en la sección http sin necesidad de añadir en otro lugar.
  4. 23

    Que necesita aplicar los siguientes cambios:

    1. Actualización php.ini (Encontrar a la derecha en el archivo ini de phpinfo();) y aumentar post_max_size y upload_max_filesize para el tamaño que usted desea:

      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 la configuración de NginX para su sitio web y añadir client_max_body_size valor en su location, http, o server contexto.

      location /{
          client_max_body_size 200m;
          ...
      }
      
    3. Reiniciar NginX y PHP-FPM:

      service nginx restart
      service php5-fpm restart
      

    NOTA: en Algún momento (En mi caso casi todo el tiempo) lo que usted necesita para matar a php-fpm proceso si no la actualización del servicio de comando correctamente. Para hacer que usted puede obtener la lista de procesos (ps -elf | grep php-fpm) y matar a uno por uno (kill -9 12345) o utilice el siguiente comando para hacer esto para usted:

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

    Por favor, a ver si va a establecer client_max_body_size directiva dentro de http {} bloque y no en el interior de la ubicación {} bloque. La puse dentro de http{} bloque y funciona

  6. 10

    Alguien me corrija si esto es malo, pero me gusta para bloquear todo abajo tanto como sea posible, y si sólo tienes un objetivo para las cargas (como es generalmente el caso), entonces sólo objetivo de los cambios a un archivo. Esto funciona para mí en el Ubuntu nginx-extras principal 1.7+ paquete:

    location = /upload.php {
        client_max_body_size 102M;
        fastcgi_param PHP_VALUE "upload_max_filesize=102M \n post_max_size=102M";
        (...)
    }
    
    • Me gusta esta idea demasiado sin embargo, para mí esto no funciona de esta manera. Todo lo que puedo hacer es reducir el valor de y no aumentar en nivel de ubicación.
  7. 2

    Asumiendo que usted ya ha establecido la client_max_body_size y diversas configuraciones de PHP (upload_max_filesize /post_max_size , etc) en las otras respuestas, a continuación, reiniciar o recargar NGINX y PHP sin ningún resultado, ejecutar este…

    nginx -T

    Esto le dará sin resolver errores en su NGINX configs. En mi caso, he luchado con el 413 de error para un día entero antes de que me di cuenta de que había algunos otros sin resolver SSL errores en el NGINX config (mal de rutas para los certs) que debían ser corregidas. Una vez que me fijo de las cuestiones pendientes que tengo de ‘nginx -T’, reloaded NGINX, y EUREKA!! Que se fija.

  8. 2

    Estoy configurando un dev server para jugar con los espejos de nuestro anticuado vivo, he utilizado El Perfecto Servidor de Ubuntu 14.04 (nginx, se UNEN, MySQL, PHP, Postfix, Dovecot y ISPConfig 3)

    Después de experimentar el mismo problema, me encontré con este post y nada funcionaba. He cambiado el valor de cada archivo recomendada (nginx.conf, ispconfig.vhost, /sites-available/default, etc.)

    Finalmente, el cambio de client_max_body_size en mi /etc/nginx/sites-available/apps.vhost y reiniciar nginx es lo que hizo el truco. Espero que ayude a alguien más.

  9. 2

    Me encuentro con el mismo problema, pero he encontrado nada que ver con nginx. Estoy utilizando nodejs como servidor back-end, usar nginx como proxy inverso, 413 código es provocado por el nodo servidor. nodo uso koa analizar el cuerpo. koa límite de la urlencoded longitud.

    formLimit: límite de la urlencoded cuerpo. Si el cuerpo termina siendo mayor que este límite, 413 del código de error se devuelve. Por defecto es de 56 kb.

    conjunto formLimit a más, puede resolver este problema.

  10. 1

    Tuve un problema similar hace poco y descubrió, que client_max_body_size 0; puede resolver un problema. De esta forma se establecerá client_max_body_size a ningún límite. Pero la mejor práctica es para mejorar el código, así que no hay necesidad de aumentar este límite.

  11. 0

    Tenido el mismo problema que el client_max_body_size directiva fue ignorado.

    Mi tonto error, que yo ponga un archivo dentro de /etc/nginx/conf.d que no terminó con .conf. Nginx no cargar estos por defecto.

  12. -1

    Si usted está utilizando la versión de windows nginx, usted puede tratar de matar a todos nginx proceso y reiniciar a ver.
    Me encontré con el mismo problema En mi entorno, pero se ha solucionado con esta solución.

    • Ese fue mi problema, gracias! Uno de Nginx instancia no fue terminada correctamente, supongo. Nunca es malo para comprobar si se sale en windows tasklist /fi "imagename eq nginx.exe"

Dejar respuesta

Please enter your comment!
Please enter your name here