«413 Request Entity Too Large»: повышаем лимиты payload (FAQ)

Ошибка «413 Request Entity Too Large» в n8n обычно возникает, когда веб-хук принимает файл большего размера, например PDF, изображение или объёмный JSON-payload, и настроенный верхний предел превышается. По умолчанию n8n устанавливает лимит в 16 МиБ на payload, который можно повысить с помощью одной переменной окружения. Однако во многих случаях реальным ограничением является не сам n8n, а уровень перед ним, обратный прокси. Состояние на июль 2026 года.

Эта статья с часто задаваемыми вопросами показывает, какую переменную нужно установить, как отличить внутренний лимит n8n от лимита прокси, и на что обратить внимание при повышении лимита, чтобы ваш инстанс оставался стабильным.

Что именно означает ошибка 413 в n8n?

HTTP-код состояния 413 сигнализирует о том, что сервер отклоняет входящий запрос, поскольку его payload больше допустимого. В n8n этот лимит действует прежде всего в двух местах:

• Веб-хук триггеры, которые принимают извне файлы или большие JSON-тела, например из форм, чат-виджетов или внешних систем.
• Внутренняя обработка больших наборов данных внутри воркфлоу, когда нода возвращает результат, превышающий настроенный верхний предел.

Согласно документации n8n о переменных окружения для endpoint, лимит по умолчанию составляет 16 МиБ. Для большинства автоматизаций с текстовыми данными, небольшими изображениями или обычными ответами API этого достаточно. Но как только через воркфлоу проходят PDF, изображения высокого разрешения или многостраничные документы, лимит быстро достигается.

Ключевая переменная окружения: N8N_PAYLOAD_SIZE_MAX

Решающий рычаг называется N8N_PAYLOAD_SIZE_MAX. Она определяет максимальный размер payload в МиБ и, согласно официальной документации, по умолчанию установлена на 16. Чтобы повысить лимит, установите переменную на более высокое значение, например:

• `N8N_PAYLOAD_SIZE_MAX=64` для 64 МиБ
• `N8N_PAYLOAD_SIZE_MAX=128` для 128 МиБ

При установке через Docker добавьте переменную в свой Compose-файл или в окружение команды Docker run, при установке через npm задайте её перед запуском, например через `N8N_PAYLOAD_SIZE_MAX=64 n8n`. Важно: после установки переменной инстанс n8n необходимо перезапустить, чтобы изменение вступило в силу. Простой перезагрузки веб-интерфейса недостаточно.

Для загрузки файлов через формы существует также отдельная переменная N8N_FORMDATA_FILE_SIZE_MAX, которая, согласно той же документации, по умолчанию составляет 200 МиБ и специально регулирует размер файла внутри form-data payload, например когда веб-хук принимает загрузку файлов из формы. Поэтому если вы хотите целенаправленно разрешить более крупные вложения, проверьте обе переменные и согласуйте их между собой.

Почему установки переменной иногда недостаточно

Частая ловушка из сообщества n8n: переменная установлена корректно, но ошибка всё равно сохраняется. Причина почти всегда кроется в предшествующем инстансе, который перехватывает запрос ещё до того, как он вообще достигает n8n. В обсуждении сообщества об ошибках 413 при загрузке PDF через веб-хукподтверждается этот паттерн: не сам n8n, а расположенная перед ним конфигурация Nginx ограничивала запрос, хотя внутренний лимит n8n был значительно выше.

Поэтому проверяйте по порядку:

• Nginx в качестве обратного прокси:Директива `client_max_body_size` ограничивает размер тела запроса независимо от n8n. Значение вроде `client_max_body_size 100M;` в конфигурации сервера или location должно соответствовать лимиту n8n или быть более щедрым.
• Traefik или Cloudflare Tunnel:Здесь также существуют собственные верхние пределы для тел запросов, которые нужно настраивать отдельно.
• Docker-настройки с предшествующим балансировщиком нагрузки:Облачные балансировщики нагрузки часто имеют собственные, иногда более низкие, лимиты по умолчанию, которые действуют независимо от n8n.

Только когда все уровни, то есть прокси и сам n8n, настроены на достаточно высокий лимит, ошибка 413 надёжно исчезает. В более старом, уже устранённом случае с форума сообщества n8nпричина заключалась даже в ошибке более ранней версии n8n, которая блокировала payload уже начиная со 100 КБ, независимо от установленного лимита. Обновление до актуальной версии n8n надёжно устраняет и такие унаследованные проблемы.

Устанавливайте лимиты осознанно, а не максимизируйте их без разбора

Прежде чем рефлекторно устанавливать лимит на очень высокое значение, стоит кратко взглянуть на обратную сторону. Документация прямо указывает на то, что более высокий лимит payload требует больше оперативной памяти и больше вычислительной мощности и может повлиять на производительность всего инстанса. Тем, кто продуктивно работает со множеством параллельных воркфлоу, следует поэтому подстраивать лимит под реальную потребность, а не под теоретически возможное значение.

Несколько практических ориентиров:

• Устанавливайте значение настолько высоким, насколько необходимо, а не настолько высоким, насколько возможно. Для обработки PDF часто достаточно 32-64 МиБ, для видеоданных может потребоваться больше.
• Наблюдайте за потреблением памяти вашим инстансом после изменения, особенно при self-hosting с ограниченными ресурсами.
• По возможности комбинируйте большие лимиты payload с режимом файловой системы для бинарных данных, управляемым через N8N_DEFAULT_BINARY_DATA_MODE, вместо хранения крупных файлов в оперативной памяти. Согласно документации, n8n по умолчанию хранит бинарные данные в памяти в режиме «default», что при больших payload быстро приводит к нагрузке на память.

Тот, кто продуктивно эксплуатирует инстанс n8n и не хочет самостоятельно разбираться в каждой теме инфраструктуры, может передать настройку, мониторинг и устранение неполадок в рамках консультирования и сопровождения n8n от NordFlux. Вы сохраняете контроль над своими воркфлоу и данными, пока техническая тонкая настройка выполняется в фоновом режиме.

Часто задаваемые вопросы

Какая переменная окружения повышает лимит payload в n8n?

Переменная N8N_PAYLOAD_SIZE_MAXзадаёт максимальный размер payload в МиБ и, согласно документации n8n, по умолчанию составляет 16. Вы повышаете её, устанавливая переменную на более высокое значение и затем перезапуская инстанс.

Почему я всё ещё получаю ошибку 413, несмотря на повышение N8N_PAYLOAD_SIZE_MAX?

В большинстве таких случаев перед n8n находится ещё один лимит, например в конфигурации Nginx с `client_max_body_size`, в Traefik или в предшествующем балансировщике нагрузки. Сам n8n, возможно, уже пропускает запрос, но прокси блокирует его раньше. Поэтому проверяйте каждый уровень инфраструктуры по отдельности.

В чём разница между N8N_PAYLOAD_SIZE_MAX и N8N_FORMDATA_FILE_SIZE_MAX?

N8N_PAYLOAD_SIZE_MAX ограничивает общий размер запроса к n8n. N8N_FORMDATA_FILE_SIZE_MAX специально регулирует максимальный размер файла внутри form-data payload, например при загрузке файлов через веб-хук форму, и по умолчанию составляет 200 МиБ. Для чистой загрузки файлов через формы обычно актуальна именно эта вторая переменная.

Нужно ли перезапускать n8n после установки переменной?

Да. Переменные окружения, такие как N8N_PAYLOAD_SIZE_MAX, считываются при запуске процесса n8n. Перезагрузки веб-интерфейса недостаточно, инстанс, соответственно контейнер, необходимо перезапустить, чтобы новый лимит вступил в силу.

Есть ли недостатки при установке очень высокого лимита?

Да. Согласно документации, более высокий лимит payload увеличивает потребность в оперативной памяти и вычислительной мощности и может повлиять на производительность всего инстанса. Поэтому устанавливайте лимит осознанно, исходя из реальной потребности, а не произвольно на очень высокое значение.