Нода Remnawave: настройка remnanode, подключение к панели и защита от блокировок

Нода и панель Remnawave: кто за что отвечает

В Remnawave две сущности, и их постоянно путают:

• Панель (backend + dashboard) — управляет всем: пользователи, лимиты, генерация подписок, статистика. Трафик абонентов через панель не идёт.
• Нода Remnawave (remnanode) — контейнер, внутри которого работает Xray-core. Именно нода терминирует VLESS/Reality/XHTTP-соединения и выпускает трафик в интернет. Нод может быть много — по странам, нагрузке, тарифам.

Связь: панель по gRPC поверх mTLS пушит ноде актуальный Xray-конфиг и список пользователей, нода отдаёт статистику. Инициатор соединения — панель, она стучится на ноду (а не наоборот), аутентификация — по сертификату, который панель генерирует сама.

Практический вывод: панель держите на дешёвом сервере где угодно (её прячут за домен/reverse-proxy), а ноды ставьте там, где нужен «выход». Это разные машины с разными требованиями. Когда говорят «нода remnawave» или «remnawave node» — речь именно про этот выходной сервер с Xray, а не про админку.

Требования к серверу под ноду

Нода нетребовательна к CPU/RAM, но критична к сети и репутации IP.

Минимум под старт (ориентир до ~300–500 онлайн на ноду):

• 1–2 vCPU, 1–2 ГБ RAM, Debian 12 / Ubuntu 22.04+
• Docker + плагин compose
• Внешний IPv4, желательно не из известных VPN-подсетей
• Порты: порт связи с панелью (APP_PORT, по умолчанию 2222) и порты инбаундов (443 и т.п.)

Цифры онлайна ориентировочные: реальный потолок ноды упирается не в ядра, а в полосу и характер трафика (стриминг «съест» ноду быстрее, чем мессенджеры).

Качество ноды определяет сеть, а не железо:

• Аплинк и пиринг до аудитории — для РФ важна низкая задержка и стабильный маршрут.
• Репутация /24. Массовые VPS-хостеры часто уже в списках DPI. Проверяйте всю /24, а не один IP.
• Политика хостера — часть ДЦ режет порты или клиента по первой жалобе.

Подготовка ОС:

apt update && apt -y upgrade
curl -fsSL https://get.docker.com | sh

Firewall настроим на следующем шаге — порт 2222 разумно открывать не всему миру, а только IP панели.

Установка remnanode: контейнер за 5 минут

Установка сводится к запуску одного контейнера remnawave/node. Значение SSL_CERT вы получите при добавлении ноды в дашборде (следующий раздел) — пока можно подставить заглушку и перезапустить контейнер после генерации.

1. Каталог и .env:

mkdir -p /opt/remnanode && cd /opt/remnanode

APP_PORT=2222
# одна длинная строка из панели, целиком в кавычках
SSL_CERT="ВСТАВЬТЕ_ЗНАЧЕНИЕ_ИЗ_ПАНЕЛИ"

2. docker-compose.yml:

services:
 remnanode:
 image: remnawave/node:latest
 container_name: remnanode
 hostname: remnanode
 restart: always
 network_mode: host
 env_file:
 -.env

network_mode: host обязателен: Xray должен слушать реальные порты хоста без NAT-проброса, иначе Reality/XHTTP ведут себя непредсказуемо. Из-за host-режима ports: не указывают — контейнер и так слушает APP_PORT и порты инбаундов на хосте.

3. Запуск и проверка:

docker compose up -d
docker logs -f remnanode

При верном SSL_CERT в логах видно, что нода поднялась и ждёт панель. Инбаундов пока нет — это нормально, конфиг Xray приедет после привязки Config Profile.

Частая ошибка: SSL_CERT — это одна длинная строка (base64/JSON). Если при копипасте она разбилась на несколько строк или потеряла символы — нода не поднимется. Вставляйте целиком в одну строку в кавычках.

Подключение ноды к панели

Связываем ноду с панелью в дашборде: Nodes → Add Node.

1. Имя ноды и её внешний IP/адрес — по нему панель будет стучаться.
2. Порт — тот же, что APP_PORT в .env (по умолчанию 2222).
3. Панель генерирует SSL payload — копируете его в SSL_CERT на сервере ноды.
4. Выбираете Config Profile и активные инбаунды (следующий раздел).
5. Если подставляли сертификат после первого запуска — пересоздайте контейнер: docker compose up -d --force-recreate.

Теперь ограничьте доступ к порту ноды только IP панели — это заметно снижает поверхность атаки на remnanode:

ufw allow from <IP_ПАНЕЛИ> to any port 2222 proto tcp
ufw allow 443/tcp # рабочий инбаунд, открыт всем клиентам
ufw enable

Связь есть, если в списке нод индикатор зелёный (online), видны аптайм и версия Xray-ядра. Если нода «серая»:

• порт 2222 открыт именно со стороны панели (firewall/security group хостера);
• SSL_CERT совпадает с тем, что панель показала для этой конкретной ноды;
• docker logs remnanode — ошибки сертификата или отказ подключения видны сразу;
• время синхронно (timedatectl) — рассинхрон ломает TLS-хендшейк mTLS.

Config Profile и инбаунды: где реально живёт конфиг Xray

В Remnawave v2.x конфигурация Xray вынесена в Config Profile — переиспользуемый JSON с секцией inbounds, который назначается на одну или несколько нод. Поменяли профиль — изменения разъехались по всем привязанным нодам, без правки каждой вручную.

Цепочка связей:

• Config Profile содержит inbounds (например, vless-reality на 443, vless-xhttp).
• Нода привязывается к профилю; вы отмечаете, какие инбаунды на ней активны.
• Host (запись в подписке) ссылается на конкретный inbound — из этого генерируется VLESS-ссылка для клиента.

Минимальный практичный набор — Reality на 443 (маскируется под чужой TLS) и, при обходе через фронт, XHTTP.

Важный нюанс XHTTP за CDN: если фронт ходит на ноду GET-транспортом (многие CDN не пропускают POST), режим packet-up нужно задать явно — иначе классический симптом «в одном клиенте работает, в другом нет». Подробный разбор XHTTP за CDN — в отдельном материале блога, здесь фиксируем сам факт.

После сохранения профиля панель сама пушит конфиг на ноду. Xray на ноде править руками не нужно и вредно — при следующей синхронизации ваши правки затрёт панель. Вся конфигурация — только через Config Profile.

Почему ноду в дата-центре блокируют — и почему смена IP не спасает

Типичный сценарий: всё настроено, нода online, клиенты подключаются — а через время в регионе с жёстким DPI всё встаёт. Дело обычно не в конфиге, а в IP ноды.

Механика:

• IP ноды принадлежит подсети хостинг-провайдера.
• Когда провайдер связи или ТСПУ переходит на белые списки — пропускается трафик только к «разрешённым» подсетям (банки, госсервисы, крупные CDN), остальное режется по умолчанию, — IP среднего VPS-хостера в белый список не входит.
• В этот момент не важно, Reality у вас или XHTTP: соединение до IP ноды не устанавливается в принципе. Reality маскирует *содержимое*, но не меняет *адрес назначения*.

Почему привычные меры дают лишь передышку:

• Сменить IP/подсеть — работает до следующей волны, новую подсеть тоже отсекут.
• Домен вместо IP — не помогает: режется сетевой доступ к адресу, куда домен резолвится.
• Больше нод — масштабирует проблему, а не решает.

Модель белых списков внедряется неравномерно по регионам и операторам, точных публичных списков «разрешённых» подсетей нет — оценки строятся по наблюдениям. Но принцип устойчив: при белых списках блокируется сам факт исходящего соединения к «неразрешённому» адресу в ДЦ. Значит, устойчивость надо искать не на уровне ноды, а на уровне того, через какой адрес клиент до неё дотягивается.

Как защитить ноду: фронт через whitelisted-CDN

Логичный ответ на белые списки — поставить перед нодой посредника, чей IP уже в белом списке. Практически это фронт через CDN на whitelisted-подсетях.

Схема:

• Клиент подключается не к IP ноды в ДЦ, а к адресу CDN-фронта (белый IP, который DPI пропускает).
• CDN проксирует трафик (например, XHTTP поверх TLS) на вашу ноду.
• Для DPI это соединение к разрешённому адресу; реальный IP ноды пользователю не нужен.

Что меняется:

• Нода перестаёт быть точкой отказа по IP — даже при известном и заблокированном адресе клиенты ходят через фронт.
• Reality/XHTTP на ноде остаются как есть — меняется только «последняя миля» до клиента.
• Требования к IP ноды снижаются — важнее стабильный аплинк, чем «идеально чистый» адрес.

Честные оговорки (детали зависят от CDN):

• многие CDN не пропускают POST → транспорт вырождается в GET → для XHTTP обязателен явный mode packet-up;
• не любой «CDN» реально сидит на whitelisted-подсетях — проверяйте конкретные /24, а не маркетинг;
• перепродажа чужого CDN по трафику дороже собственной дистрибуции.

Это задача класса whitelist-CDN для VPN-операторов: фронт на белых IP + проксирование на вашу ноду. Разбор XHTTP за CDN и панели за CDN — в отдельных материалах; здесь важен принцип: сервер/нода в ДЦ блокируется легко, устойчивость даёт фронт через whitelisted-CDN.