413 Request Entity Too Large: causas y soluciones

Qué significa 413 Payload Too Large

El RFC 9110 define el nombre actual como 413 Content Too Large, aunque tanto 413 Payload Too Large como el más antiguo 413 Request Entity Too Large se refieren al mismo código de estado y ambos siguen apareciendo en servidores, frameworks, y páginas de error. Sea cual sea el texto, el significado es idéntico: la propia petición era sintácticamente correcta, pero su cuerpo superó un límite de tamaño antes de que el servidor la aceptara para procesarla. Esto ocurre casi siempre en subidas de archivos, pero puede ocurrir en cualquier petición con un cuerpo grande, incluido un payload masivo de una API.

Cómo aparece el error

Los navegadores normalmente muestran la página de error genérica que devuelva el servidor de origen o el borde; no hay ninguna interfaz propia del navegador para esto como sí la hay para un fallo de conexión. Es habitual verlo fallar en silencio en un formulario, con la respuesta visible solo en la pestaña de red, especialmente en una subida de archivo construida con JavaScript. Desde la línea de comandos, la respuesta lo confirma directamente:

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

Los registros de acceso y de error del servidor son el sitio más fiable para confirmar el tamaño exacto implicado y qué capa lo rechazó, ya que una petición se puede bloquear en el CDN, en el servidor web, o en la aplicación, y cada uno lo registra de forma distinta.

Qué causa un 413

• El client_max_body_size de nginx. El valor por defecto es 1 MB, lo bastante pequeño como para que casi cualquier subida de archivo real lo dispare hasta que se aumenta explícitamente:

  client_max_body_size 20M;

• El LimitRequestBody de Apache. Se fija por directorio o globalmente, y, como en nginx, por defecto tiene un tamaño que muchas aplicaciones superan sin que nadie lo haya cambiado a propósito.
• Los upload_max_filesize y post_max_size de PHP. Dos ajustes distintos en php.ini que ambos necesitan ser lo bastante grandes para la subida; post_max_size debe ser al menos tan grande como upload_max_filesize o el segundo ajuste limita al primero en silencio.
• El maxAllowedContentLength de IIS. Se fija en web.config bajo requestLimits, con un valor por defecto de unos 30 MB, y es distinto del propio ajuste maxRequestLength de ASP.NET, que usa unidades diferentes y necesita aumentarse junto a él.
• El límite de subida por plan de Cloudflare. Los planes Free y Pro limitan el tamaño del cuerpo de la petición a 100 MB con independencia de lo que aceptaría el servidor de origen por lo demás, y este límite no se puede aumentar desde la propia configuración del origen; hay que abordarlo del lado de Cloudflare o sortearlo con una ruta de subida directa que se salte el proxy.
• Los límites de payload de un API gateway. Los API gateways gestionados suelen limitar los cuerpos de petición muy por debajo de lo que permitiría un servidor web tradicional, a menudo en pocos megabytes de un solo dígito, lo que atrapa a los equipos que migran una función de subida existente detrás de un gateway nuevo.

Cómo saber de quién es la culpa

Esto casi nunca es culpa del visitante en el sentido de haber hecho algo mal; el archivo que está subiendo simplemente es más grande que un límite que existe en algún punto de la cadena, y la solución le corresponde a quien sea dueño de esa capa. Si el mismo archivo se sube bien en un entorno y falla en otro, compara cada capa de la ruta de la petición, ya que nginx, PHP, y un CDN pueden tener cada uno un límite distinto y gana el más pequeño. Ejecutar una comprobación HTTP con un cuerpo de petición cercano al límite que pretendes, enviada desde fuera de tu red, confirma cuál es de verdad el techo efectivo de extremo a extremo en lugar de fiarte de un único archivo de configuración.

Cómo corregir un error 413

Si eres el visitante

1. Comprime el archivo antes de subirlo, especialmente imágenes y vídeos, que a menudo se reducen drásticamente sin pérdida visible de calidad en tamaños normales.
2. Divide una subida grande en piezas más pequeñas si el sitio admite subidas por partes o reanudables, en lugar de enviar una única petición muy grande.
3. Revisa el límite de subida indicado por el sitio si hay uno publicado, ya que algunos 413 funcionan como estaba previsto y la solución es simplemente un archivo más pequeño.

Si administras el sitio

1. Aumenta el límite de todas las capas a la vez, no solo una. Una única petición suele pasar por un CDN, un servidor web, y un runtime de aplicación, y el límite configurado más pequeño en cualquier punto de esa cadena determina el techo real.
2. Fija nginx y Apache explícitamente en lugar de confiar en los valores por defecto:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. Iguala los dos ajustes de PHP. Aumenta tanto upload_max_filesize como post_max_size, y asegúrate de que el segundo sea igual o mayor que el primero.
4. Actualiza juntos el requestLimits de IIS y el maxRequestLength de ASP.NET en web.config, ya que miden lo mismo en unidades distintas y ambos necesitan aumentarse.
5. Sortea el límite de plan de Cloudflare para archivos genuinamente grandes subiendo directamente al almacenamiento con una URL firmada, saltándote por completo la ruta de petición proxyficada, en lugar de intentar aumentar un límite que ese nivel de plan no expone.
6. Revisa el límite de payload del propio API gateway por separado del servicio backend si hay uno delante de tu aplicación; puede rechazar una petición antes de que tus propios ajustes de aplicación, más generosos, lleguen siquiera a aplicarse.

Cómo prevenir que un 413 bloquee a usuarios reales

Un límite fijado demasiado bajo es fácil de pasar por alto hasta que alguien con un archivo grande lo dispara, y para entonces parece una función de subida rota en lugar de un desajuste de configuración. Una comprobación HTTP programada que envía una petición cercana al límite de tamaño que pretendes, con una aserción sobre el código de estado esperado, confirma que toda la cadena todavía la acepta después de cualquier cambio en el CDN, el servidor web, o la configuración de la aplicación. Combinado con la monitorización desde varias ubicaciones, también detecta un límite a nivel de CDN que solo se aplica en ciertos nodos de borde.

Errores relacionados

Consulta 400 Bad Request, que algunos servidores devuelven en lugar de 413 para la misma condición de cuerpo demasiado grande, la guía de la familia 4xx para la familia más amplia, y 406 Not Acceptable en otro sitio de esta tanda.

Preguntas frecuentes

¿Es 413 Payload Too Large lo mismo que 413 Request Entity Too Large?

Sí. El RFC 9110 renombró el texto de estado a 413 Content Too Large, pero ambos nombres más antiguos se refieren al mismo código de estado y significado idénticos, y las tres formas siguen apareciendo en la práctica según la versión del software del servidor.

¿Por qué falla mi subida aunque haya aumentado el client_max_body_size de nginx?

Es probable que otra capa de la cadena, habitualmente el post_max_size de PHP, el límite fijo del plan de un CDN, o un API gateway, esté imponiendo un límite más pequeño de forma independiente. Cada capa entre el cliente y la aplicación necesita permitir ese tamaño, no solo la que cambiaste.

¿Puedo aumentar el límite de 100 MB de Cloudflare en el plan gratuito o Pro?

No desde la propia configuración del servidor de origen; ese techo lo fija el nivel de plan. La solución habitual es subir los archivos grandes directamente al almacenamiento usando una URL firmada que se salte la ruta de petición proxyficada.

¿Cuenta el 413 como un bloqueo de seguridad?

Normalmente no. Suele ser un límite de recursos sencillo y no una regla defensiva, aunque algunos WAF sí usan cuerpos inusualmente grandes como una señal más entre varias a la hora de decidir si bloquear una petición.

¿Cuál es un límite de subida por defecto razonable si no he fijado ninguno?

No hay una cifra universal; depende por completo de lo que tu aplicación necesite legítimamente aceptar. Fíjalo deliberadamente en función del archivo legítimo más grande que esperas, en lugar de dejar el valor por defecto de cada capa tal cual.