Честный разговор о n8n: почему ваша автоматизация тормозит, когда проект растет.

Знакомая ситуация? Ты установил n8n, настроил первый воркфлоу — всё летает. Радуешься, подключаешь новых ботов, добавляешь парсинг, отправку отчетов... И тут начинается ад.

n8n показывает, что узел выполняется вечно. Жмешь "Остановить" — и через несколько секунд воркфлоу успешно завершается, хотя интерфейс всё это время висел. Сам процесс останавливается без проблем. Вопрос не в том, как его остановить, а в том, почему фронтенд виснет. Узлы Merge, HTTP Request или IMAP Email перестают отвечать. В логах потом вылезает ошибка 431 или вечное "checkpoint starting" в логах.

Поздравляю. Ты перерос стандартные настройки.

Смотрим логи через Docker Desktop:

  1. Откройте Docker.

  2. Containers.

  3. имя_проекта-n8n-1.

  4. Нажмите на название — откроется окно

Альтернатива — через терминал, если нет Docker Desktop:

Логи через консоль (для продвинутых):

bash
docker logs -f название_контейнера

Название контейнера можно узнать командой  docker ps


Почему так происходит

Когда ты только начал, твои запросы весили килобайты. А теперь Merge пытается склеить 5000 строк из CSV, IMAP качает тяжелые письма с базами, а HTTP Request возвращает гигантский JSON.

n8n написан на Node.js. По умолчанию он задушен лимитами как студент в общежитии:

  • Лимит заголовков — 16 KB. (Ошибка 431 — твой коллега.)

  • Лимит тела запроса — 16 MB. (Привет, зависание на Merge.)

  • Лимит между runner'ами — тоже маленький.

Причем фронтенд виснет красиво — бесконечное отображение выполнения узла пока не кликнешь кнопку «Стоп», а процесс на бэкенде УЖЕ завершился. Просто браузер не получил ответ, потому что заголовки запроса на остановку раздуло.

Как лечить. Рабочий чеклист (делать именно в этом порядке)

docker-compose.yml в секцию environment для сервиса n8n:

yaml

environment:
  # ЛЕЧИМ ОШИБКУ 431 И ЗАВИСАНИЕ ПРИ ОСТАНОВКЕ
  - NODE_OPTIONS=--max-http-header-size=65536
 
  # ЛЕЧИМ ЗАВИСАНИЕ MERGE И HTTP REQUEST (увеличиваем до 256 MB)
  - N8N_PAYLOAD_SIZE_MAX=268435456
 
  # ЛЕЧИМ ПАДЕНИЕ РАННЕРОВ ПРИ БОЛЬШИХ ДАННЫХ
  - N8N_RUNNERS_MAX_PAYLOAD=268435456

Важный момент про IMAP. Если виснет узел получения почты, дело часто не в n8n, а в вашем сервере. Добавьте N8N_IMAP_RECONNECT_THRESHOLD=60 и используйте узел "Email Read Imap" с флагом MARK_AS_SEEN=FALSE, пока не отладите.

Что делать, если не помогло (или не хочется копаться в настройках)

Набольших проектах не ждите чудес от стандартного Merge. Сделайте обходной маневр прямо в воркфлоу:

  1. Перед Merge поставьте узел Aggregate. Он пожмет данные в пакеты по 100-200 штук. Merge будет склеивать не 10 000 строк, а 100 пакетов.

  2. Никогда не отправляйте в HTTP Request огромный массив за раз. Используйте SplitOut → обработали 50 элементов → отправили → повторили.

  3. В узле IMAP включите LIMIT = 50 писем за раз. Дешевле пробежаться 10 раз по 50 писем, чем один раз по 500 и схватить таймаут.

Один из логов в вашей системе (checkpointcomplete: wrote 137 buffers) говорит, что PostgreSQL работает отлично. Проблема не в базе. Проблема в трубе между браузером и раннером.

Итог (запомнить из поста)

  • Зависает на фронтенде, хотя бэкенд отработал → увеличивайте max-http-header-size через NODE_OPTIONS.

  • Mergeили HTTP Request виснет на ровном месте → увеличивайте N8N_PAYLOAD_SIZE_MAX.

  • Проект вырос → переходите с Merge на связку Aggregate + Split Out.

Это не баги n8n. Это просто "день взросления" вашей автоматизации. Правильно крутите гайки — и ваш сервер перестанет вешать воркфлоу.