n8n на сервере: частые ошибки и решения

MAATRIX

n8n редко ломается «весь сразу». Обычно причина одна и конкретная: том смонтирован не туда, ключ шифрования сгенерировался заново, прокси не передал X-Forwarded-Proto, база выполнений за три недели распухла до десяти гигабайт. Ниже — ошибки n8n, которые чаще всего доходят до поддержки: точный текст сообщений и правки в compose, .env и конфиге Nginx.

Сначала логи: где n8n говорит, что именно сломалось

Половина обращений «n8n не работает» закрывается за пять минут по логу:

docker compose logs -f --tail=200 n8n

Если сообщений мало, добавьте N8N_LOG_LEVEL=debug и N8N_LOG_OUTPUT=console,file — след останется и после перезапуска, файл ляжет в /home/node/.n8n/logs/n8n.log. Осторожно: на debug в лог попадают тела запросов с заголовками авторизации, так что после отладки верните info. Второй вопрос: как умирал контейнер.

docker inspect n8n --format '{{.State.Status}} exit={{.State.ExitCode}} oom={{.State.OOMKilled}} restarts={{.RestartCount}}'

Процесс мимо прокси проверяется через curl http://127.0.0.1:5678/healthz/readiness: адрес отдаёт 200, только когда есть соединение с базой. И зафиксируйте версию (n8n --version): ветка 1.x обновляется еженедельно, поведение переменных меняется, а latest в проде — сюрприз.

`EACCES: permission denied` и том, который оказался не тем

Классический старт:

Error: EACCES: permission denied, open '/home/node/.n8n/config'

Или EACCES: permission denied, mkdir '/home/node/.n8n', если каталога ещё нет. Причина: в официальном образе процесс идёт от пользователя node с UID 1000, а каталог для bind-mount создан на хосте от root.

sudo chown -R 1000:1000 /opt/n8n/data
docker compose up -d --force-recreate

Проверка изнутри — docker compose exec n8n id, должно быть uid=1000(node) gid=1000(node). Рядом в логе часто висит Permissions 0644 for n8n settings file /home/node/.n8n/config are too wide — не смертельно, но в этом файле лежит ключ шифрования, так что chmod 600 стоит сделать сразу.

Вторая половина темы — «пропали все сценарии». Данные не исчезают сами: либо их не было в постоянном томе, либо том другой. Compose формирует имя тома из имени каталога проекта: папку переименовали — получили пустой том, старый остался сиротой. Найти его помогают docker volume ls | grep -i n8n и docker volume inspect n8n_n8n_data.

Если в _data лежит database.sqlite больше пары сотен килобайт — данные живы, потерялась привязка. Лечится на остановленном стеке: docker compose down, sudo cp -a старого _data в новый, chown -R 1000:1000, подъём. И запомните команду, которая уносит всё безвозвратно: docker compose down -v удаляет тома вместе со стеком.

`Credentials could not be decrypted` — самая дорогая ошибка

Сценарии открываются, но в каждой ноде с подключением к сервису красным горит:

Credentials could not be decrypted. The likely reason is that a different encryption key was used to encrypt the data.

При первом запуске n8n генерирует случайный ключ и кладёт его в /home/node/.n8n/config. Сценарии хранятся в базе открыто, а учётные данные — токены, пароли, ключи API — зашифрованы им. Перенесли базу без файла config или пересоздали том — ключ новый, расшифровать нечем. На проекте с сорока подключениями это полтора-два часа ручной работы и поход за токенами.

Профилактика занимает минуту: сгенерируйте ключ через openssl rand -hex 32 и задайте его явно в .env как N8N_ENCRYPTION_KEY, чтобы он не жил только внутри тома.

Нюанс: если инстанс уже работал, свежий ключ подставлять нельзя — n8n сверяет переменную со значением в файле настроек, и при расхождении вы получите отказ старта или ту же ошибку. Сначала достаньте действующий ключ через docker compose exec n8n cat /home/node/.n8n/config (в ответе JSON вида {"encryptionKey":"a3f1..."}) и пропишите его. Дальше гигиена: chmod 600 .env, не коммитить, копию держать отдельно от дампов базы.

Ошибки за реверс-прокси: secure cookie, 413 и оборванный редактор

Второй по частоте класс: n8n работает, ломается стык с Nginx или Caddy. Узнаваемое сообщение на логине:

Your n8n server is configured to use a secure cookie, however you are either visiting this via an insecure URL, or using Safari.

n8n ставит cookie сессии с флагом Secure, а вы зашли по http://IP:5678 — браузер её не сохраняет, логин крутится по кругу. Лечение — домен и HTTPS; костыль N8N_SECURE_COOKIE=false допустим, только пока n8n доступен с localhost или из VPN. И при терминации HTTPS на прокси добавьте N8N_PROXY_HOPS=1: без неё клиентом считается сам прокси, лимиты по частоте считаются по одному адресу на всех, а в логах вместо реальных IP светится 172.18.0.1.

location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 3600s;
    client_max_body_size 100m;
}

Блок закрывает три болячки сразу:

• Upgrade и Connection — «Connection lost» в редакторе: статус выполнения идёт по WebSocket, без них вкладка отваливается через минуту. Если прокси всё равно режет — N8N_PUSH_BACKEND=sse.
• proxy_read_timeout 3600s — сценарии длиннее минуты: на дефолтных 60 секундах Nginx рвёт соединение, и выполнение выглядит зависшим.
• client_max_body_size 100m — 413 Request Entity Too Large при дефолте Nginx в 1 МБ. Второй потолок в самом n8n: N8N_PAYLOAD_SIZE_MAX=64 вместо 16.

Отдельная ловушка: публикация порта в Docker обходит ufw. Строка - "5678:5678" открывает порт в интернет, и ufw deny 5678 его не закроет. Публикуйте на петлю — - "127.0.0.1:5678:5678", проверка ss -tlnp | grep 5678. Фаервол всё равно нужен: ufw allow 22/tcp, ufw allow 80,443/tcp, ufw enable. Если триггеры так и не получают запросов, дело в адресах вебхуков: n8n не принимает webhook.

База и диск: `SQLITE_BUSY`, распухшие выполнения, `No space left on device`

Установка на SQLite работает отлично, пока сценариев меньше десятка. Дальше они идут параллельно, и в логе появляется SQLITE_BUSY: database is locked: SQLite допускает только одну запись одновременно. Временно помогают DB_SQLITE_POOL_SIZE=5 и N8N_CONCURRENCY_PRODUCTION_LIMIT=5, но это подпорка.

Вторая беда — объём: n8n сохраняет полный набор входных и выходных данных каждой ноды по каждому выполнению. На инстансе с 30 активными сценариями и примерно 5000 выполнений в сутки файл database.sqlite вырос с 4 МБ до 9,6 ГБ за три недели, а df -h показал 96% занятости диска. Свои цифры — docker compose exec n8n du -sh /home/node/.n8n/database.sqlite. Лечится прунингом, который включают в первый день, а не после аварии:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=168
EXECUTIONS_DATA_SAVE_ON_SUCCESS=none
N8N_DEFAULT_BINARY_DATA_MODE=filesystem

Компромисс честный: с SAVE_ON_SUCCESS=none посмотреть «что прилетело вчера в удачном запуске» не выйдет, зато ошибки пишутся полностью. Режим filesystem выносит бинарные данные в каталог binaryData — крупнейший выигрыш на вложениях и PDF. Но SQLite не отдаёт место обратно: файл останется прежнего размера, пока не сожмёте его вручную на остановленном сервисе и с копией.

docker compose down
cd /var/lib/docker/volumes/n8n_n8n_data/_data
sudo cp database.sqlite /root/n8n-db.bak
sudo sqlite3 database.sqlite 'VACUUM;'
sudo chown 1000:1000 database.sqlite
docker compose up -d

Когда параллельных выполнений стабильно больше пяти, пора на PostgreSQL: postgres:16-alpine рядом в compose плюс DB_TYPE=postgresdb и переменные DB_POSTGRESDB_*. Автоматической миграции из SQLite нет: экспорт через n8n export:workflow --backup и export:credentials --backup, после смены базы — import:workflow --separate и import:credentials с тем же ключом. История выполнений не переедет. Смежное: место на диске VPS.

Расписание, Code-нода и task runners

Сценарий по расписанию срабатывает не в 9:00, а в 12:00, и кажется, что n8n сломан. На деле контейнер живёт в UTC, и нужны обе переменные:

GENERIC_TIMEZONE=Europe/Moscow
TZ=Europe/Moscow

TZ задаёт системную зону контейнера: метки в логах и результат new Date() в Code-ноде. GENERIC_TIMEZONE — зону планировщика, то есть нод Schedule Trigger и Cron. Поставите одну — получите рассинхрон; проверка docker compose exec n8n date. Нюанс переезда: у сценария есть своя настройка пояса в Settings, и она перекрывает GENERIC_TIMEZONE — если по чужому времени ходит один сценарий из тридцати, дело в его настройках.

Следующее по частоте — предупреждение в логе на сборках ветки 1.7x и новее:

Running n8n without task runners is deprecated. Please set N8N_RUNNERS_ENABLED=true

В свежих сборках это уже не предупреждение: Code-нода без раннера не выполняется. Включается через N8N_RUNNERS_ENABLED=true и N8N_RUNNERS_MODE=internal. Честная плата — память: раннер стартует отдельным процессом и добавляет 150–250 МБ RSS, и на 2 ГБ инстанс ловит exit=137 именно после его включения.

Третья типичная ошибка в Code-ноде — Cannot find module 'axios'. Внешние модули запрещены по умолчанию и разрешаются списком NODE_FUNCTION_ALLOW_EXTERNAL=axios,cheerio, встроенные — через NODE_FUNCTION_ALLOW_BUILTIN=crypto,fs. Но переменная только снимает запрет: модуль должен быть в образе, а npm install внутри контейнера живёт до первого обновления. Обычно пакет и не нужен — HTTP Request-нода делает то же самое. Из той же серии: process.env в Code возвращает пустоту, открывается через N8N_BLOCK_ENV_ACCESS_IN_NODE=false — но там лежат пароль базы и ключ шифрования.

Если сценарии всё равно застревают в статусе выполнения — это другая история: почему workflow зависает.

Какой сервер взять под n8n в MAATRIX

Половина ошибок выше конфигурационные, но exit=137, SQLITE_BUSY и «кончился диск» упираются в железо.

Минимум: 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe. На 1 vCPU и 2 ГБ n8n стартует и живёт, если сценариев несколько и они лёгкие. Но связка n8n + PostgreSQL + Caddy в простое занимает 700–900 МБ, task runner добавляет до 250 МБ, и первое же параллельное выполнение с вложениями по 20–30 МБ даёт oom=true. Четыре гигабайта — рабочая точка, а не запас: сколько RAM нужно для n8n.

Комфортно: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Нужно при нескольких тысячах выполнений в сутки, тяжёлых нодах с ИИ или файлами и режиме очереди: EXECUTIONS_MODE=queue, Redis и пара воркеров рядом.

По диску: образы Docker занимают около 3 ГБ, PostgreSQL с прунингом — единицы гигабайт, binaryData растёт по факту вложений. С прунингом 40 ГБ хватает надолго, без него закладывайте 1,5–2 ГБ в неделю. Важнее лишнего ядра: KVM-виртуализация, а не контейнерная (Docker внутри LXC приносит сюрпризы с cgroup и памятью), и адекватный сосед по гипервизору — в vmstat 1 5 колонка st стабильно больше 5% значит, что процессорное время отбирают.

По локации для n8n логичен UK, Лондон: 15–35 мс до европейских API вроде Stripe, HubSpot и Google Workspace, понятный GDPR-контур и статический белый IP под вайтлисты контрагентов. Если основная нагрузка — зарубежные ИИ-сервисы, берите US, Нью-Йорк с чистыми IP. Если через сценарии идут персональные данные россиян и вы работаете по 152-ФЗ — только RU.

Сервер в любой локации выдаётся с root и статическим IP, оплата — картой российского банка, по СБП, криптой или токеном MAAT. Разворачивать удобнее с чистого листа по инструкции по установке n8n на VPS, а сразу после установки включите то, что дороже всего чинить задним числом: суточный снапшот тома и отдельно сохранённый N8N_ENCRYPTION_KEY.

Частые вопросы