В предыдущей статье мы разобрали классические «узкие места» n8n, которые приводят к зависанию интерфейса: увеличили лимит заголовков до 64 KB (прощай, ошибка 431 Request Header Fields Too Large), подняли лимит тела запроса до 256 MB (Merge-ноды перестали вешать вкладку) и настроили обмен данными между runner'ами. Казалось бы, проблема решена. Но при запуске тяжёлых или долгоиграющих воркфлоу интерфейс всё равно «фризится», а в консоли браузера появляется новая ошибка:

 Failed to load resource: the server responded with a status of 504 (Gateway Timeout)

Разбираем, что скрывается за этой ошибкой, почему увеличение лимитов тут бессильно, и как перевести n8n в асинхронный режим Queue Mode без головной боли. На реальных граблях, с логами и готовыми командами.

Что такое 504 Gateway Timeout в контексте n8n?

HTTP-статус 504 означает, что промежуточный сервер (reverse proxy, балансировщик или даже внутренний сетевой стек Docker) не получил ответ от backend'а в отведённое время (обычно 60–100 секунд).

В нашем случае запрос шёл на эндпоинт получения статуса выполнения:

/rest/ph/i/v0/e/?ip=0&_=1777561304012&ver=1.372.5...

Это polling-запрос, который UI n8n отправляет, чтобы узнать, завершился ли воркфлоу.

Почему это происходит?

По умолчанию n8n выполняет воркфлоу синхронно в основном процессе. Пока нода ждёт ответа от внешнего API, обрабатывает массив из 50k строк или выполняет длительный HTTP Request, главный контейнер n8n полностью занят. UI отправляет запрос, ждёт ответа, не получает его → прокси/Docker рвёт соединение → 504 → интерфейс блокируется в ожидании.

Увеличение NODE_OPTIONS, N8N_PAYLOAD_SIZE_MAX и N8N_RUNNERS_MAX_PAYLOAD решает проблему переполнения памяти и обрезки данных, но не убирает синхронную блокировку Event Loop. Нужно менять архитектуру выполнения.

Решение: режим очереди (Queue Mode)

Официальная рекомендация n8n для стабильной работы при параллельных или долгих запусках — вынести выполнения в фоновые воркеры через Redis.

Архитектура после изменений:

Сервис
Роль
n8n (main)
UI, API, вебхуки, планировщик. Не выполняет воркфлоу.
n8n-worker
Забирает задачи из Redis и выполняет их. Может быть запущен в нескольких репликах.
redis
Брокер очередей. Хранит задания и статусы.
postgres
Хранение настроек, credentials, истории.


Ключевые изменения в docker-compose.yml:

 
# Добавляем Redis
redis:
  image: redis:alpine
  restart: always
  command: redis-server --save 60 1 --loglevel warning
  volumes:
    - redis_/data
  networks:
    - n8n-network

# Добавляем воркер
n8n-worker:
  image: docker.n8n.io/n8nio/n8n:latest
  restart: unless-stopped
  command: ["worker"]  # ← важно!
  environment:
    - EXECUTIONS_MODE=queue
    - QUEUE_BULL_REDIS_HOST=redis
    - QUEUE_BULL_REDIS_PORT=6379
    - DB_TYPE=postgresdb
    - DB_POSTGRESDB_HOST=postgres
    - DB_POSTGRESDB_PORT=5432
    - DB_POSTGRESDB_DATABASE=n8n
    - DB_POSTGRESDB_USER=n8n
    - DB_POSTGRESDB_PASSWORD=n8n_secure_password
    - N8N_DEFAULT_BINARY_DATA_MODE=filesystem
  volumes:
    - n8n_storage:/home/node/.n8n
    - "D:/n8n-/home/node/.n8n-files"
  depends_on:
    - postgres
    - redis
  networks:
    - n8n-network

# В основном n8n добавляем:
environment:
  - EXECUTIONS_MODE=queue
  - QUEUE_BULL_REDIS_HOST=redis
  - QUEUE_BULL_REDIS_PORT=6379
depends_on:
  - postgres
  - redis


С какими ошибками столкнулись и как их диагностировали

Переход на Queue Mode редко проходит «в один клик». Вот реальные грабли, на которые мы наступили, и как их обошли.


1. TLS handshake timeout при скачивании redis:alpine

Симптом: docker compose up -d падает с ошибкой сети.

Диагностика: Test-NetConnection registry-1.docker.io -Port 443 возвращает False.

Причина: Сетевой стек WSL2 «завис» или DNS/прокси блокируют доступ к Docker Hub.

Лечение:

powershell

>wsl --shutdown
# Перезапустите Docker Desktop полностью
docker compose up -d

Если не помогло: проверьте корпоративный прокси, антивирус с сетевым экраном или VPN. В Docker Desktop: Settings → Resources → Proxies.


2. Воркер в цикле Restarting (1)

Симптом: docker compose ps показывает Restarting (1) 30 seconds ago.

Диагностика: docker compose logs n8n-worker --tail 20

Вывод:

Error: Command "n8n" not found
Error: Command "n8n" not found

Причина: В docker-compose.yml указали command: ["n8n", "worker"]. Но Docker-образ n8n уже имеет ENTRYPOINT ["n8n"]. Передача n8n как аргумента ломает запуск.

Лечение: Изменить на command: ["worker"].


3. YAML ломается из-за inline-комментария

Симптом: Переменные после определённой строки игнорируются, воркер не видит БД или Redis.

Диагностика: Проверка docker compose exec n8n env показывает отсутствие части переменных.

Причина: В YAML списки (environment:) не поддерживают комментарии в той же строке.

yaml

# Ломает парсинг:
- N8N_FILESYSTEM_ALLOW_WRITE=/data/shared  # Разрешаем запись
#  Работает:
# Разрешаем запись в папку для бинарных данных
- N8N_FILESYSTEM_ALLOW_WRITE=/home/node/.n8n-files

Лечение: Вынести комментарии на отдельную строку или удалить.

4. Несовпадение путей для бинарных данных

Симптом: Worker запускается, но падает при сохранении файлов или не видит credentials.

Причина: N8N_FILESYSTEM_ALLOW_WRITE=/data/shared не совпадал с примонтированным томом "D:/n8n-data:/home/node/.n8n-files".

Лечение: Синхронизировать путь переменной с внутренним путём контейнера:

yaml

- N8N_FILESYSTEM_ALLOW_WRITE=/home/node/.n8n-files

Как проверить, что Queue Mode работает

Не верьте на слово. Проверяйте по чек-листу:

Проверка
Команда / Действие
Ожидаемый результат
Статус контейнеров
docker compose ps
Все 4 сервиса в статусе Up
Готовность воркера
docker compose logs n8n-worker --tail 10
n8n worker is now ready
Активный режим
docker compose exec n8n env | findstr EXECUTIONS_MODE
EXECUTIONS_MODE=queue
UI не зависает
Запустите воркфлоу с нодой Wait (10 sec)
Страница остаётся отзывчивой во время выполнения
Очередь не пуста
docker compose exec redis redis-cli llenbull:jobs:waiting
Число задач растёт при запуске, затем падает до 0


Итог: что мы получили

  1. Интерфейс больше не блокируется при долгих выполнениях. Основной процесс n8n остаётся лёгким.
  2. Параллельные запуски не конкурируют за CPU/RAM одного контейнера.
  3. Отказоустойчивость: если воркер упадёт, задача вернётся в Redis и будет выполнена другим воркером.
  4. Масштабируемость: достаточно добавить ещё один n8n-worker с теми же переменными, чтобы увеличить throughput.

Важно для production: если за n8n стоит Nginx/Traefik/Cloudflare, не забудьте увеличить таймауты прокси:

nginx

proxy_read_timeout 300s;
proxy_connect_timeout 300s;
proxy_buffering off;

Queue Mode снимает нагрузку с UI, но сам прокси всё равно может рвать соединения при долгих вебхуках.

Переход на Queue Mode — это не «костыль», а рекомендуемая архитектура для любых нагрузок выше средних. Лимиты решают проблему объёмов данных, очередь решает проблему времени выполнения. Используем вместе — получаем стабильный n8n без зависаний и 504.

Если столкнулись с другими ошибками при настройке — делитесь. Разберём логи и найдём решение.