«413 Request Entity Too Large»: aumentar los límites de payload (FAQ)

El error «413 Request Entity Too Large» suele aparecer en n8n cuando un webhook recibe un archivo más grande, por ejemplo un PDF, una imagen o un payload JSON extenso, y se supera el límite configurado. De forma predeterminada, n8n establece un límite de 16 MiB por payload, que se puede aumentar mediante una única variable de entorno. Sin embargo, en muchos casos el verdadero cuello de botella no está en n8n mismo, sino en una capa anterior, el proxy inverso. Actualizado: julio de 2026.

Este artículo de preguntas frecuentes muestra qué variable debe configurar, cómo distinguir entre un límite interno de n8n y un límite del proxy, y en qué debe fijarse al aumentar el límite para que su instancia se mantenga estable.

¿Qué significa exactamente el error 413 en n8n?

El código de estado HTTP 413 indica que el servidor rechaza la solicitud entrante porque su payload es mayor de lo permitido. En n8n, este límite se aplica sobre todo en dos lugares:

• Triggers de webhook, que reciben desde el exterior archivos o cuerpos JSON grandes, por ejemplo de formularios, widgets de chat o sistemas externos.
• Procesamiento interno de grandes conjuntos de datos dentro de un workflow, cuando un nodo devuelve un resultado que supera el límite configurado.

Según la documentación de n8n sobre las variables de entorno de los endpoints, el límite predeterminado es de 16 MiB. Esto es suficiente para la mayoría de las automatizaciones con datos de texto, imágenes pequeñas o respuestas de API normales. Pero en cuanto pasan por un workflow archivos PDF, imágenes de alta resolución o documentos de varias páginas, el límite se alcanza rápidamente.

La variable de entorno central: N8N_PAYLOAD_SIZE_MAX

La palanca decisiva se llama N8N_PAYLOAD_SIZE_MAX. Define el tamaño máximo del payload en MiB y, según la documentación oficial, está fijada de forma predeterminada en 16. Para aumentar el límite, configure la variable con un valor más alto, por ejemplo:

• `N8N_PAYLOAD_SIZE_MAX=64` para 64 MiB
• `N8N_PAYLOAD_SIZE_MAX=128` para 128 MiB

En una instalación con Docker, agregue la variable a su archivo Compose o al entorno de ejecución de Docker; en una instalación con npm, configúrela antes de iniciar, por ejemplo mediante `N8N_PAYLOAD_SIZE_MAX=64 n8n`. Importante: tras configurar la variable, la instancia de n8n debe reiniciarse para que el cambio surta efecto. No basta con recargar la interfaz web.

Para las cargas de archivos mediante formularios existe además una variable independiente, N8N_FORMDATA_FILE_SIZE_MAX, que, según la misma documentación, está fijada de forma predeterminada en 200 MiB y regula específicamente el tamaño de archivo dentro de los payloads form-data, por ejemplo cuando un webhook recibe cargas de archivos desde un formulario. Así que si desea permitir específicamente archivos adjuntos más grandes, revise ambas variables y ajústelas entre sí.

Por qué configurar la variable a veces no es suficiente

Un obstáculo frecuente en la comunidad de n8n: la variable está configurada correctamente, pero el error persiste de todos modos. La causa casi siempre es una instancia previa que intercepta la solicitud antes de que llegue siquiera a n8n. En un hilo de la comunidad sobre errores 413 al subir PDF mediante webhookse confirma este patrón: no fue n8n mismo, sino la configuración de Nginx situada delante, la que limitaba la solicitud, aunque el límite interno de n8n era considerablemente más alto.

Por eso, revise en este orden:

• Nginx como proxy inverso:La directiva `client_max_body_size` limita el tamaño del cuerpo de forma independiente de n8n. Un valor como `client_max_body_size 100M;` en la configuración del servidor o del location debe coincidir con el límite de n8n o ser más generoso.
• Traefik o túnel de Cloudflare:Aquí también existen límites superiores propios para los cuerpos de las solicitudes, que deben configurarse por separado.
• Configuraciones Docker con un balanceador de carga previo:Los balanceadores de carga en la nube suelen traer sus propios límites predeterminados, a veces más bajos, que se aplican independientemente de n8n.

Solo cuando todas las capas, es decir, el proxy y n8n mismo, están configuradas con un límite suficientemente alto, el error 413 desaparece de forma fiable. En un caso antiguo, ya resuelto, del foro de la comunidad de n8n, la causa fue incluso un error en una versión anterior de n8n que bloqueaba los payloads ya a partir de 100 KB, independientemente del límite configurado. Una actualización a una versión actual de n8n también resuelve de forma fiable ese tipo de problemas heredados.

Establecer límites con criterio en lugar de maximizarlos sin más

Antes de configurar el límite de forma refleja en un valor muy alto, vale la pena echar un breve vistazo al reverso de la moneda. La documentación señala expresamente que un límite de payload más alto exige más memoria y más capacidad de procesamiento y puede afectar el rendimiento de toda la instancia. Quien opera en producción muchos workflows en paralelo debería, por tanto, ajustar el límite a la necesidad real, no a lo que sea teóricamente posible.

Algunas pautas prácticas:

• Configure el valor tan alto como sea necesario, no tan alto como sea posible. Para el procesamiento de PDF suelen bastar entre 32 y 64 MiB; para datos de vídeo puede hacer falta más.
• Observe el consumo de memoria de su instancia tras el ajuste, especialmente en self-hosting con recursos limitados.
• Combine, en la medida de lo posible, límites de payload grandes con el modo de sistema de archivos para datos binarios, controlado mediante N8N_DEFAULT_BINARY_DATA_MODE, en lugar de mantener los archivos grandes en memoria. Según la documentación, n8n mantiene los datos binarios en memoria de forma predeterminada en el modo «default», lo que con payloads grandes genera rápidamente presión sobre la memoria.

Quien opera una instancia de n8n en producción y no quiere investigar cada tema de infraestructura por su cuenta puede externalizar la configuración, la monitorización y la resolución de problemas mediante la consultoría y el soporte de n8n de NordFlux. Usted conserva el control sobre sus workflows y datos, mientras el ajuste técnico fino se realiza en segundo plano.

Preguntas frecuentes

¿Qué variable de entorno aumenta el límite de payload en n8n?

La variable N8N_PAYLOAD_SIZE_MAXdefine el tamaño máximo del payload en MiB y, según la documentación de n8n, está fijada de forma predeterminada en 16. Se aumenta configurando la variable con un valor más alto y reiniciando después la instancia.

¿Por qué sigo recibiendo un error 413 a pesar de haber aumentado N8N_PAYLOAD_SIZE_MAX?

En la mayoría de estos casos hay otro límite delante de n8n, por ejemplo en una configuración de Nginx con `client_max_body_size`, en Traefik o en un balanceador de carga previo. Puede que n8n mismo ya permita la solicitud, pero el proxy la bloquea antes. Por eso, revise cada capa de la infraestructura por separado.

¿Cuál es la diferencia entre N8N_PAYLOAD_SIZE_MAX y N8N_FORMDATA_FILE_SIZE_MAX?

N8N_PAYLOAD_SIZE_MAX limita el tamaño total de una solicitud a n8n. N8N_FORMDATA_FILE_SIZE_MAX regula específicamente el tamaño máximo de archivo dentro de los payloads form-data, por ejemplo en cargas de archivos mediante un formulario de webhook, y está fijada de forma predeterminada en 200 MiB. Para cargas de archivos puras mediante formularios, normalmente es esta segunda variable la relevante.

¿Debo reiniciar n8n después de configurar la variable?

Sí. Las variables de entorno como N8N_PAYLOAD_SIZE_MAX se leen al iniciar el proceso de n8n. No basta con recargar la interfaz web; la instancia, o el contenedor, debe reiniciarse para que el nuevo límite surta efecto.

¿Hay desventajas si configuro el límite muy alto?

Sí. Según la documentación, un límite de payload más alto aumenta la necesidad de memoria y de capacidad de procesamiento y puede afectar el rendimiento de toda la instancia. Configure, por tanto, el límite de forma deliberada según la necesidad real y no de forma genérica en un valor muy alto.