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

MAATRIX

Node-RED — удобный способ собрать автоматизацию из блоков без единой строчки кода, но именно эта простота на клиенте оборачивается неочевидными проблемами на сервере: контейнер падает после рестарта, флоу пропадают при обновлении, MQTT-узлы висят серым цветом «disconnected», а веб-интерфейс через reverse proxy открывается белым экраном. Ниже — конкретные причины и рабочие решения для типовых ситуаций, с которыми сталкиваются при развёртывании Node-RED на VPS, отдельно от связки с Home Assistant.

Node-RED не запускается или сразу падает

Первое, что стоит проверить — логи контейнера или процесса, а не гадать по симптомам.

# если Node-RED в Docker
docker logs -f nodered --tail 100

# если запущен как systemd-сервис
sudo journalctl -u nodered -n 100 --no-pager

Частые причины падения:

• Нехватка памяти. Node-RED сам по себе лёгкий, но с десятком палет и большими флоу процесс Node.js может упираться в лимит контейнера. Если в логах JavaScript heap out of memory или контейнер убивается OOM killer (docker inspect nodered --format '{{.State.OOMKilled}}' покажет true), поднимайте лимит памяти или память сервера.
• Битый файл настроек. После неудачного обновления палеты settings.js может остаться синтаксически некорректным. Проверка:

node -c /data/settings.js

Если синтаксис в порядке, но Node-RED всё равно не стартует — временно переименуйте settings.js и запустите с настройками по умолчанию, чтобы исключить конфиг как причину.

• Конфликт версий палет. Обновление одной ноды может потянуть несовместимую версию зависимости. Смотрите package.json в ~/.node-red/ (или /data в контейнере) — если там разнобой версий, помогает чистая переустановка палет:

cd /data
rm -rf node_modules package-lock.json
npm install

Docker-контейнер стартует, но сразу перезапускается по кругу

Классика — политика restart: unless-stopped в связке с падением на старте создаёт бесконечный цикл рестартов, а в docker ps контейнер мелькает статусом Restarting. Отличить зависание от циклического краша:

docker events --filter container=nodered --since 10m

Если события die идут каждые несколько секунд — проблема в конфигурации, а не в ресурсах. Общий подход к диагностике падающих контейнеров разобран в статье про частые причины, когда контейнер не запускается — там больше про сам Docker, здесь — специфика Node-RED.

Типичная причина именно для Node-RED — повреждённый файл flows_cred.json (зашифрованные креды флоу) при потере или смене переменной credentialSecret в settings.js. Если секрет менялся вручную или контейнер пересоздали без сохранения переменной окружения, Node-RED не может расшифровать креды и падает при парсинге флоу. Решение — либо вернуть прежний credentialSecret, либо (если credentials не критичны) удалить flows_cred.json и пересоздать чувствительные поля в узлах заново.

Пропадают флоу после перезапуска или обновления

Самая обидная ошибка: настроили десяток автоматизаций, перезапустили контейнер — а флоу пустые. Причина почти всегда одна: данные Node-RED хранятся не в volume, а внутри слоя контейнера.

Неправильно (данные исчезнут при пересоздании контейнера):

services:
  nodered:
    image: nodered/node-red:latest
    ports:
      - "1880:1880"

Правильно — том с явным путём на хосте:

services:
  nodered:
    image: nodered/node-red:latest
    container_name: nodered
    restart: unless-stopped
    ports:
      - "1880:1880"
    environment:
      - TZ=Europe/Moscow
    volumes:
      - /srv/nodered/data:/data

После первого запуска проверьте, что файл /srv/nodered/data/flows.json действительно появился на хосте, а не только внутри контейнера:

ls -la /srv/nodered/data/

Если используете именованный volume вместо bind-mount, узнать его реальное расположение можно через:

docker volume inspect nodered_data

И обязательно включите бэкапы этого каталога — flows.json, flows_cred.json и settings.js вместе дают полное состояние инстанса. Общие принципы бэкапа docker volume (расписание, ротация, куда складывать архивы) описаны в статье про бэкап docker volume на сервере — те же приёмы применимы и к каталогу данных Node-RED.

MQTT-узлы не подключаются или показывают "disconnected"

Серый или красный статус под MQTT-узлом почти всегда указывает на одну из трёх вещей: неверный адрес брокера, закрытый порт или проблема с сетью Docker.

1. Адрес брокера. Если Node-RED и MQTT-брокер (например, Mosquitto) в разных Docker-сетях или на разных хостах, localhost внутри контейнера Node-RED указывает сам на себя, а не на хост. Используйте имя сервиса из docker-compose (если оба в одной сети) или реальный IP/домен хоста:

# в одном docker-compose проекте с сетью по умолчанию
mqtt://mosquitto:1883

# если брокер на хосте, а Node-RED в контейнере
mqtt://host.docker.internal:1883

host.docker.internal штатно работает на Docker Desktop, а на Linux-сервере его нужно явно прокинуть в docker-compose:

extra_hosts:
  - "host.docker.internal:host-gateway"

1. Закрытый порт 1883/8883 в файрволе. Проверка с сервера:

sudo ss -tulnp | grep 1883
nc -zv 127.0.0.1 1883

Если порт слушается, но снаружи недоступен — смотрите правила ufw/iptables, особенно если брокер и Node-RED физически на разных серверах.

1. Анонимный доступ отключён. Начиная с Mosquitto 2.x анонимные подключения по умолчанию запрещены. В логах брокера будет Client <id> disconnected due to protocol error или отказ в авторизации. Быстрая проверка конфигурации:

docker exec -it mosquitto cat /mosquitto/config/mosquitto.conf | grep -E "allow_anonymous|listener"

Для продакшена правильнее не включать анонимный доступ, а завести пользователя и указать логин/пароль прямо в MQTT-узле Node-RED — это безопаснее и не требует открытого брокера для всех.

Веб-интерфейс не открывается через reverse proxy

Если Node-RED напрямую по http://ip:1880 работает, а через домен с Traefik или Nginx Proxy Manager — белый экран, ошибки WebSocket в консоли браузера или зависшая загрузка — дело почти всегда в WebSocket-соединении. Редактор Node-RED и вкладки Dashboard активно используют Socket.IO/WebSocket для живого обновления, и обратный прокси должен явно пропускать апгрейд протокола.

Для Nginx это отдельные заголовки в location-блоке:

location / {
    proxy_pass http://127.0.0.1:1880;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 3600s;
}

Обратите внимание на proxy_read_timeout — Node-RED держит долгоживущие WebSocket-соединения, и стандартный таймаут в 60 секунд будет рвать редактор при простое.

Для Traefik как reverse proxy для Docker WebSocket работает "из коробки" через провайдер Docker, если правильно настроены лейблы и точка входа — подробный разбор конфигурации в статье Traefik как reverse proxy для Docker. Если вместо Traefik рассматриваете Nginx Proxy Manager, сравнение подходов есть в статье Traefik или Nginx Proxy Manager — что выбрать для сервера.

Отдельно проверьте settings.js — если задан httpAdminRoot или requireHttps, а прокси терминирует TLS сам, несовпадение схемы (http/https) может ломать редирект после логина.

Дашборд (Node-RED Dashboard) не отображает виджеты или показывает пустую страницу

Node-RED Dashboard (пакет node-red-dashboard или новый @flowfuse/node-red-dashboard) — отдельное веб-приложение поверх Node-RED, и его типичные проблемы отличаются от проблем самого редактора:

• Пустая страница по /ui. Проверьте, что в флоу вообще есть хотя бы один tab/group в конфигурации дашборда — без них страница действительно будет пустой, это не баг.
• Виджеты не обновляются в реальном времени. Снова WebSocket — если прокси настроен только для / (редактор), но не пробрасывает апгрейд для /ui, обновления перестают приходить. Убедитесь, что настройки WebSocket в reverse proxy применяются ко всему домену, а не к конкретному location.
• Конфликт версий двух пакетов дашборда одновременно. Установка нового @flowfuse/node-red-dashboard рядом со старым node-red-dashboard в одном инстансе иногда приводит к дублированию узлов в палитре и непредсказуемому поведению. Если мигрировали на новую версию — удалите старый пакет через Manage Palette, а не просто добавьте новый поверх.

Высокая нагрузка на CPU/диск от логов и debug-узлов

Отдельная категория проблем — не падения, а деградация производительности со временем:

Для логов Docker минимальная защита от переполнения диска:

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Применяется на уровне демона (/etc/docker/daemon.json) или отдельно для сервиса в docker-compose через секцию logging.

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