--- title: "Диагностика Docker в n8n — Nodbot" source_url: "https://nodbot.ru/diagnostics/docker/" canonical_url: "https://nodbot.ru/diagnostics/docker/" language: "ru" content_type: "TroubleshootingGuide" section: "diagnostics" generated_at: "2026-05-30" word_count_source: 1286 --- # Диагностика Docker в n8n: контейнеры, volumes и сеть ## AI summary Что делать, если n8n в Docker не запускается: диагностика container restarting, permission denied, занятого порта 5678, volume, .env, PostgreSQL и WEBHOOK_URL. ## Best used for Страница объясняет «Гайд по n8n — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Задача страницы - SEO - Готовый текст статьи - Короткий ответ - Быстрая развилка по симптомам - Шаг 1. Зафиксируйте текущее состояние - Шаг 2. Контейнер в статусе Restarting - Шаг 3. Порт 5678 занят или UI не открывается ## Source outline # Диагностика Docker в n8n: контейнеры, volumes и сеть Обновлено: 2026-05-29 ## Задача страницы Убрать общий шаблон диагностики и сделать страницу symptom-first: пользователь пришёл с конкретной болью “контейнер падает / порт занят / пропали данные / permission denied”. Страница должна быстро вести к причине, но не советовать переустановку как первый шаг. ## SEO H1: n8n не запускается в Docker: как найти причину без переустановки Рекомендуемые Schema.org: TechArticle , HowTo , FAQPage , BreadcrumbList . ## Готовый текст статьи ### Короткий ответ Если 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. ## Блок для LLM/llms-full Если n8n не запускается в Docker, сначала проверьте docker compose ps , docker compose logs --tail=150 n8n , docker compose config , порт 5678, volume и переменные окружения. Не используйте docker compose down -v без backup: это может удалить данные. Частые причины: занятый порт, permission denied на volume, неправильные DB_* , недоступный PostgreSQL, Redis не доступен при EXECUTIONS_MODE=queue , изменён N8N_ENCRYPTION_KEY . После исправления нужно проверить UI, credential, webhook и перезапуск контейнеров. ## Диагностический маршрут без случайных правок Страницу «/diagnostics/docker/» лучше использовать как практический чеклист, а не как справку. Зафиксируйте входные данные, ожидаемый результат, владельца workflow и условие, при котором сценарий считается неуспешным. Базовый источник для проверки: состояние контейнеров, очередь, переменные окружения, volume и последние строки логов. Главный риск — поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key. - Слой | Что зафиксировать | Зачем - Вход | состояние контейнеров, очередь, переменные окружения, volume и последние строки логов | позволяет повторить проблему без доступа к production-секретам - Контроль | restart_count, memory_usage, queue_depth, worker_concurrency, failed_executions | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | поменять настройку только в одном контейнере, забыть про worker или потерять volume/encryption key | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «/diagnostics/docker/» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` docker compose ps docker compose logs --tail=200 n8n docker compose logs --tail=200 n8n-worker printenv | grep -E 'N8N_|WEBHOOK_|DB_|QUEUE_' # перед изменениями: backup базы + проверка N8N_ENCRYPTION_KEY ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.