« 413 Request Entity Too Large » : augmenter les limites de payload (FAQ)

L'erreur « 413 Request Entity Too Large » apparaît généralement dans n8n lorsqu'un webhook reçoit un fichier volumineux, par exemple un PDF, une image ou un payload JSON conséquent, et que la limite configurée est dépassée. Par défaut, n8n applique une limite de 16 MiB par payload, qui peut être augmentée via une seule variable d'environnement. Dans de nombreux cas, le véritable frein ne vient toutefois pas de n8n lui-même, mais d'un niveau situé en amont, le reverse proxy. État : juillet 2026.

Cet article FAQ explique quelle variable définir, comment distinguer une limite interne à n8n d'une limite du proxy, et à quoi faire attention lors de l'augmentation de la limite afin que votre instance reste stable.

Que signifie exactement l'erreur 413 dans n8n ?

Le code de statut HTTP 413 signale que le serveur rejette la requête entrante parce que son payload est plus volumineux que ce qui est autorisé. Dans n8n, cette limite s'applique surtout à deux endroits :

• Déclencheurs webhook, qui reçoivent de l'extérieur des fichiers ou des corps JSON volumineux, par exemple depuis des formulaires, des widgets de chat ou des systèmes externes.
• Traitement interne de grands ensembles de données au sein d'un workflow, lorsqu'un nœud renvoie un résultat qui dépasse la limite configurée.

Selon la documentation n8n sur les variables d'environnement des endpoints, la limite par défaut est de 16 MiB. Cela suffit pour la plupart des automatisations impliquant des données textuelles, de petites images ou des réponses API normales. Mais dès que des PDF, des images haute résolution ou des documents de plusieurs pages passent par un workflow, la limite est vite atteinte.

La variable d'environnement centrale : N8N_PAYLOAD_SIZE_MAX

Le levier décisif s'appelle N8N_PAYLOAD_SIZE_MAX. Elle définit la taille maximale du payload en MiB et est, selon la documentation officielle, fixée par défaut à 16. Pour augmenter la limite, définissez la variable sur une valeur plus élevée, par exemple :

• `N8N_PAYLOAD_SIZE_MAX=64` pour 64 MiB
• `N8N_PAYLOAD_SIZE_MAX=128` pour 128 MiB

Pour une installation Docker, ajoutez la variable à votre fichier Compose ou à l'environnement de la commande Docker run ; pour une installation npm, définissez-la avant le démarrage, par exemple via `N8N_PAYLOAD_SIZE_MAX=64 n8n`. Important : après avoir défini la variable, l'instance n8n doit être redémarrée pour que la modification prenne effet. Un simple rechargement de l'interface web ne suffit pas.

Pour les envois de fichiers via formulaire, il existe en outre une variable distincte, N8N_FORMDATA_FILE_SIZE_MAX, qui, selon la même documentation, est fixée par défaut à 200 MiB et régit spécifiquement la taille des fichiers au sein des payloads form-data, par exemple lorsqu'un webhook reçoit des téléversements de fichiers depuis un formulaire. Si vous souhaitez donc autoriser spécifiquement des pièces jointes plus volumineuses, vérifiez les deux variables et harmonisez-les entre elles.

Pourquoi définir la variable ne suffit parfois pas

Un piège fréquent au sein de la communauté n8n : la variable est correctement définie, mais l'erreur persiste malgré tout. La raison est presque toujours une instance en amont qui intercepte la requête avant même qu'elle n'atteigne n8n. Un fil de discussion communautaire sur les erreurs 413 lors du téléversement de PDF via webhookconfirme ce schéma : ce n'est pas n8n lui-même, mais la configuration Nginx en amont, qui limitait la requête, alors que la limite interne de n8n était nettement plus élevée.

Vérifiez donc dans l'ordre :

• Nginx en tant que reverse proxy :La directive `client_max_body_size` limite la taille du corps indépendamment de n8n. Une valeur comme `client_max_body_size 100M;` dans la configuration du serveur ou du location doit correspondre à la limite de n8n ou être plus généreuse.
• Traefik ou tunnel Cloudflare :Ceux-ci disposent également de leurs propres limites supérieures pour les corps de requête, qui doivent être configurées séparément.
• Configurations Docker avec un load balancer en amont :Les load balancers cloud apportent souvent leurs propres limites par défaut, parfois plus basses, qui s'appliquent indépendamment de n8n.

Ce n'est que lorsque tous les niveaux, à savoir le proxy et n8n lui-même, sont réglés sur une limite suffisamment élevée que l'erreur 413 disparaît de manière fiable. Dans un ancien cas, désormais résolu, issu du forum communautaire de n8n, la cause était même un bug dans une version antérieure de n8n qui bloquait les payloads dès 100 Ko, indépendamment de la limite définie. Une mise à jour vers une version récente de n8n résout aussi fiablement ce type d'anciens problèmes.

Définir des limites de manière réfléchie plutôt que de maximiser systématiquement

Avant de régler la limite de façon réflexe sur une valeur très élevée, il vaut la peine de considérer brièvement le revers de la médaille. La documentation souligne explicitement qu'une limite de payload plus élevée requiert davantage de mémoire et de puissance de calcul et peut affecter les performances de l'ensemble de l'instance. Quiconque exploite en production de nombreux workflows en parallèle devrait donc adapter la limite au besoin réel, et non au maximum théoriquement possible.

Quelques repères pratiques :

• Définissez la valeur aussi élevée que nécessaire, pas aussi élevée que possible. Pour le traitement de PDF, 32 à 64 MiB suffisent souvent ; pour des données vidéo, davantage peut être nécessaire.
• Surveillez la consommation mémoire de votre instance après l'ajustement, en particulier en auto-hébergement avec des ressources limitées.
• Combinez si possible des limites de payload élevées avec le mode système de fichiers pour les données binaires, contrôlé via N8N_DEFAULT_BINARY_DATA_MODE, plutôt que de conserver les fichiers volumineux en mémoire. Selon la documentation, n8n conserve par défaut les données binaires en mémoire en mode « default », ce qui entraîne rapidement une pression mémoire en cas de payloads volumineux.

Si vous exploitez une instance n8n en production et ne souhaitez pas rechercher vous-même chaque sujet d'infrastructure, vous pouvez externaliser la configuration, le monitoring et la résolution des problèmes dans le cadre d'un accompagnement et suivi n8n par NordFlux. Vous gardez ainsi le contrôle de vos workflows et de vos données, tandis que l'ajustement technique fin s'effectue en arrière-plan.

Questions fréquentes

Quelle variable d'environnement augmente la limite de payload dans n8n ?

La variable N8N_PAYLOAD_SIZE_MAXdéfinit la taille maximale du payload en MiB et est, selon la documentation n8n, fixée par défaut à 16. Vous l'augmentez en définissant la variable sur une valeur plus élevée, puis en redémarrant l'instance.

Pourquoi ai-je toujours une erreur 413 malgré l'augmentation de N8N_PAYLOAD_SIZE_MAX ?

Dans la plupart de ces cas, une autre limite se situe en amont de n8n, par exemple dans une configuration Nginx avec `client_max_body_size`, dans Traefik ou dans un load balancer en amont. n8n lui-même autorise peut-être déjà la requête, mais le proxy la bloque avant. Vérifiez donc chaque niveau de l'infrastructure individuellement.

Quelle est la différence entre N8N_PAYLOAD_SIZE_MAX et N8N_FORMDATA_FILE_SIZE_MAX ?

N8N_PAYLOAD_SIZE_MAX limite la taille totale d'une requête vers n8n. N8N_FORMDATA_FILE_SIZE_MAX régit spécifiquement la taille maximale des fichiers au sein des payloads form-data, par exemple lors de téléversements de fichiers via un formulaire webhook, et est fixée par défaut à 200 MiB. Pour les téléversements de fichiers purs via des formulaires, c'est généralement cette seconde variable qui est pertinente.

Dois-je redémarrer n8n après avoir défini la variable ?

Oui. Les variables d'environnement comme N8N_PAYLOAD_SIZE_MAX sont lues au démarrage du processus n8n. Recharger l'interface web ne suffit pas ; l'instance, ou le conteneur, doit être redémarré pour que la nouvelle limite prenne effet.

Y a-t-il des inconvénients à régler la limite très haut ?

Oui. Selon la documentation, une limite de payload plus élevée augmente les besoins en mémoire et en puissance de calcul et peut affecter les performances de l'ensemble de l'instance. Réglez donc la limite délibérément en fonction du besoin réel plutôt que systématiquement sur une valeur très élevée.