Диагностика Docker в n8n: контейнеры, volumes и сеть ¶
Обновлено: 2026-05-29
Короткий ответ ¶
Если n8n не запускается в Docker, сначала не переустанавливайте контейнер, а сохраните логи и проверьте четыре зоны: статус контейнера, порт 5678, volume с данными и переменные окружения. Самые частые причины — занятый порт, ошибка прав на volume, неверный .env, недоступный PostgreSQL или потерянный N8N_ENCRYPTION_KEY. Без backup нельзя удалять volume и пересоздавать базу: так можно потерять workflows, credentials и executions.
Быстрая развилка по симптомам ¶
| Симптом | Вероятная причина | Первая команда |
|---|---|---|
| Restarting в docker ps | n8n падает при старте из-за env, базы или прав | docker compose logs --tail=150 n8n |
| UI не открывается | порт не опубликован, reverse proxy не проксирует, контейнер не healthy | docker compose ps |
| permission denied | volume принадлежит другому пользователю или сломались права | ls -la ./n8n_data |
| address already in use | порт 5678 уже занят другим процессом | ss -ltnp | grep 5678 |
| После обновления “пропали” данные | подключился новый пустой volume или другая база | docker compose config |
| Ошибка подключения к PostgreSQL | неверные DB_*, база не поднялась, сеть не совпадает | docker compose logs --tail=100 postgres |
Диагностику лучше делать в таком порядке: сначала зафиксировать состояние, потом читать логи, потом проверять compose, и только после этого менять конфигурацию.
Шаг 1. Зафиксируйте текущее состояние ¶
Перед любым исправлением сохраните вывод команд. Это помогает не потерять исходную причину, особенно если вы работаете на production-сервере.
date
docker compose ps
docker compose logs --tail=150 n8n
docker compose config > compose.rendered.yml
Если n8n подключён к PostgreSQL, отдельно посмотрите статус базы:
docker compose logs --tail=100 postgres
Не запускайте сразу docker compose down -v. Флаг -v удаляет volumes, а значит может уничтожить данные, если они хранились в volume.
Шаг 2. Контейнер в статусе Restarting ¶
Статус Restarting означает, что процесс n8n запускается, падает и Docker пытается поднять его снова. Причину почти всегда видно в последних строках логов:
docker compose logs --tail=200 n8n
Что искать в логах:
- ошибку чтения или расшифровки credentials;
- проблему подключения к PostgreSQL;
- ошибку прав на директорию
.n8n; - неправильное имя переменной окружения;
- конфликт режима queue без доступного Redis;
- ошибку миграции базы после обновления.
Если в логах есть проблема с базой, не чините её перезапуском n8n. Сначала проверьте сам контейнер PostgreSQL, имя сервиса, пароль, имя базы и Docker network.
Шаг 3. Порт 5678 занят или UI не открывается ¶
Если вы запускаете n8n локально или без reverse proxy, порт 5678 должен быть свободен. Проверка:
ss -ltnp | grep 5678
Если порт занят, найдите процесс и решите, что должно его использовать. Иногда на сервере уже работает старый контейнер n8n, а новый compose пытается занять тот же порт.
Для production с reverse proxy порт 5678 не обязан быть опубликован наружу. Тогда проверять нужно не внешний порт, а связь reverse proxy → контейнер n8n. Если HTTPS-домен отдаёт 502, откройте логи proxy и убедитесь, что он проксирует на правильное имя сервиса и порт внутри Docker network.
Шаг 4. Ошибка volume и прав ¶
Проблемы с правами часто появляются после переноса файлов с другого сервера, запуска контейнера от другого пользователя или ручного копирования backup. Симптомы: EACCES, permission denied, невозможность создать файл в .n8n.
Проверьте владельца и права:
ls -la
ls -la ./n8n_data
Не меняйте права “вслепую” командой chmod -R 777. Это быстро, но небезопасно. Сначала выясните, какой пользователь внутри контейнера пишет в директорию, и исправьте владельца аккуратно. Если данные важные, сделайте архив перед изменением:
tar -czf n8n-data-before-permissions-fix.tar.gz ./n8n_data
Шаг 5. После обновления пропали workflows или credentials ¶
Чаще всего данные не пропали, а n8n подключился к другому хранилищу. Например, изменился путь volume, имя Docker volume, DB_TYPE, параметры PostgreSQL или compose запустили из другой директории.
Проверьте финальную конфигурацию:
docker compose config
Сравните:
- имя проекта Docker Compose;
- путь volume;
DB_TYPE;DB_POSTGRESDB_HOST;- имя базы;
- значение
N8N_ENCRYPTION_KEY; - образ n8n и tag версии.
Если workflows видны, но credentials не работают, отдельно проверьте ключ шифрования. При смене N8N_ENCRYPTION_KEY n8n может видеть записи credentials, но не сможет их расшифровать.
Шаг 6. Проверка .env ¶
Большая часть странных ошибок Docker-инсталляции связана не с Docker, а с .env. Проблемы бывают такие: лишние кавычки, пробелы, старый домен, неправильный host базы, одинаковые порты, переменная написана с ошибкой.
Минимальный список для проверки:
N8N_HOST=n8n.example.ru
N8N_PROTOCOL=https
WEBHOOK_URL=https://n8n.example.ru/
N8N_EDITOR_BASE_URL=https://n8n.example.ru/
N8N_ENCRYPTION_KEY=...
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgres
EXECUTIONS_MODE=queue
QUEUE_BULL_REDIS_HOST=redis
После изменения .env пересоздайте контейнеры, чтобы переменные реально применились:
docker compose up -d --force-recreate
Что не делать ¶
Не удаляйте volume, пока не сделали backup. Не меняйте одновременно .env, compose и версию образа: после этого трудно понять, что помогло или сломало. Не копируйте чужой compose без проверки переменных. Не публикуйте логи с токенами, webhook URLs и payload клиентов.
Контрольный smoke-test после исправления ¶
Когда n8n поднялся, проверьте не только UI:
- Откройте редактор.
- Запустите простой manual workflow.
- Создайте или откройте тестовый credential.
- Выполните Webhook workflow через production URL.
- Перезапустите контейнеры.
- Проверьте, что workflow и credential остались на месте.
- Сохраните причину и фикс в changelog.
Если проблема повторится, у вас будет не набор догадок, а понятная история: симптом → лог → причина → исправление.
FAQ ¶
Можно ли просто удалить контейнер n8n и создать новый?
Контейнер можно пересоздавать, но volume и база должны сохраниться. Удаление контейнера обычно безопаснее, чем удаление volume.
Почему UI не открывается, хотя контейнер running?
Причина может быть в proxy, firewall, неправильном порт-маппинге или том, что n8n слушает внутри контейнера, но запрос снаружи до него не доходит.
Почему после обновления исчезли workflow?
Скорее всего, подключился другой volume или другая база. Проверьте docker compose config, имя проекта и параметры DB_*.
Что делать с ошибкой credentials после переноса?
Проверьте, совпадает ли N8N_ENCRYPTION_KEY со старой установкой. Без старого ключа credentials могут не расшифроваться.
Нужно ли использовать latest tag образа?
Для production лучше фиксировать версию образа и обновляться осознанно: backup → pull → restart → smoke-test.