Remnawave: панель управления VLESS/Reality для нескольких серверов

Что мы настраиваем и зачем

Remnawave — self-hosted панель управления прокси-инфраструктурой на базе Xray. Она решает проблему, которая появляется сразу после перехода от одного вручную настроенного сервера к нескольким: пользователи, ключи, лимиты, подписки, настройки нод и статистика перестают помещаться в одном конфигурационном файле.

Вместо ручного редактирования JSON-конфигов Xray администратор получает веб-панель и API. В ней создаются пользователи, выдаются subscription URL, назначаются ограничения по трафику и сроку действия, а серверы-исполнители подключаются как ноды. Панель хранит состояние в PostgreSQL, а ноды применяют полученную конфигурацию и обслуживают клиентские подключения.

В этой статье используется типичная архитектура из трёх ролей:

• Control plane: VPS с Remnawave, PostgreSQL, Redis и Caddy. Он содержит панель, API, учётные записи и метаданные.
• Edge-ноды: VPS в одной или нескольких локациях, где запускается агент ноды и Xray Core.
• Клиенты: приложения с поддержкой VLESS и подписок, получающие актуальную конфигурацию через URL подписки.

VLESS — современный протокол учётных данных в экосистеме Xray. Reality используется вместе с VLESS для организации защищённого транспорта без необходимости выпускать TLS-сертификат на каждом публичном входящем порту ноды. Тем не менее административная панель не должна быть доступна по HTTP: HTTPS нужен для защиты паролей, токенов и ссылок подписок.

Что будет работать после настройки

После прохождения всех шагов у вас появится домен панели, например panel.example.com, защищённый TLS-сертификатом. В панели вы создадите администратора, добавите одну или несколько нод, создадите тестового пользователя и получите подписку. Добавление следующего сервера не потребует копирования базы данных или ручной синхронизации пользователей: достаточно установить агент ноды и привязать его токеном.

Такой подход удобен для команды разработчиков, личной инфраструктуры с несколькими регионами, небольшого сообщества или тестовой среды. Он также упрощает замену ноды: если сервер недоступен или должен быть выведен из эксплуатации, пользователей можно переназначить на новые ноды через панель.

Self-hosted и облачные панели

Self-hosted вариант оправдан, когда важны контроль, независимость от внешней панели, собственные правила хранения данных и возможность использовать ноды у разных хостеров. Обратная сторона — необходимость следить за обновлениями и иметь рабочий план восстановления.

Используйте инфраструктуру только в соответствии с законодательством страны размещения серверов, условиями провайдера и правилами сетей, через которые проходит трафик. Не публикуйте административную панель без HTTPS и не оставляйте API доступным без аутентификации.

Какой VPS-конфиг нужен под эту задачу

Нагрузка на панель Remnawave и нагрузка на выходные ноды отличаются. Панель хранит пользователей, статистику, настройки и API-состояние; ей обычно важнее стабильный диск и резерв RAM для PostgreSQL. Нодам важнее пропускная способность сети, качество маршрутизации, CPU для шифрования и достаточный лимит трафика.

Минимальные ресурсы для панели

Для управляющего сервера практичный стартовый вариант — 2 vCPU, 4 GB RAM, 40 GB NVMe и сеть 1 Гбит/с. Такой запас позволяет одновременно запускать Docker, PostgreSQL, Redis, Caddy и панель, не сталкиваясь с OOM при обновлениях или миграциях базы. Как один из нейтральных вариантов можно взять VPS с указанными характеристиками, но важнее проверить лимит трафика, доступность IPv4 и возможность открыть TCP-порты 80 и 443.

Ресурсы для одной ноды VLESS/Reality

Для ноды с десятками активных пользователей обычно достаточно 1–2 vCPU и 1–2 GB RAM, если на сервере не работают другие тяжёлые службы. При высокой суммарной скорости, большом числе одновременных соединений или интенсивном использовании видеотрафика выбирайте 2–4 vCPU, 2–4 GB RAM и порт 1 Гбит/с. Xray обычно не требует большого диска: 20 GB достаточно, если логи ротируются и на сервере нет локального архива статистики.

Не оценивайте сервер только по числу зарегистрированных пользователей. Критичнее количество одновременных клиентов, средняя скорость и месячный объём трафика. Например, 30 пользователей, которые подключаются эпизодически, могут потреблять меньше ресурсов, чем пять постоянных пользователей с интенсивными загрузками.

Когда нужен dedicated, а не VPS

Dedicated-сервер имеет смысл, когда узел постоянно нагружен близко к пропускной способности порта, требуется предсказуемая производительность CPU, нужны 5–10 Гбит/с, повышенный лимит трафика или гарантированный сетевой профиль. Он также уместен для крупной ноды с несколькими сотнями одновременных клиентов.

Для панели dedicated обычно не нужен: база и API потребляют существенно меньше ресурсов, чем передача пользовательского трафика. Рациональная схема — небольшая надёжная панель на отдельном VPS и более производительные ноды там, где это оправдано статистикой.

Как выбрать локацию

Локация панели влияет на задержку при управлении нодами, но почти не влияет на пользовательскую скорость: полезный трафик идёт через edge-ноды. Выбирайте для панели регион с устойчивым доступом к вашим нодам и предсказуемой поддержкой домена.

Локации нод выбирают по задержке до пользователей, качеству маршрутов, лимиту трафика, политике допустимого использования и наличию IPv4. Не размещайте все ноды у одного оператора и в одной стране, если для вас важна отказоустойчивость. Минимально разумная географическая схема — панель в одном регионе и две ноды в разных дата-центрах.

Подготовка сервера

Далее предполагается чистый VPS с Ubuntu Server 24.04 LTS x86_64. На 2026 год это удобная LTS-база для Docker-инфраструктуры: она получает обновления безопасности, содержит актуальное ядро и хорошо поддерживается большинством образов. Если вы используете Debian 12 или 13, логика шагов та же, но имена пакетов могут незначительно отличаться.

Сначала войдите на сервер под пользователем root по паролю, который выдал провайдер. Сразу создайте отдельного администратора: постоянная работа под root увеличивает последствия ошибки в команде или компрометации SSH-ключа.

Создание пользователя и ключевой доступ SSH

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
nano /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh

Вставьте в authorized_keys содержимое вашего публичного SSH-ключа, например строку, начинающуюся с ssh-ed25519. Проверьте вход во втором окне терминала, не закрывая текущую root-сессию:

ssh deploy@SERVER_IP

Только после успешного входа отключайте парольную аутентификацию root. Откройте конфигурацию SSH:

sudo nano /etc/ssh/sshd_config.d/99-hardening.conf

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
X11Forwarding no
MaxAuthTries 3

Проверьте синтаксис и перезапустите SSH. Если команда проверки возвращает ошибку, не перезапускайте службу до исправления файла.

sudo sshd -t && sudo systemctl restart ssh

Обновление системы и базовые инструменты

Выполните обновление до установки Docker. После обновления ядра перезагрузите VPS, если система сообщает о необходимости.

sudo apt update && sudo apt full-upgrade -y
sudo apt install -y ca-certificates curl gnupg git jq nano unzip \
  ufw fail2ban chrony logrotate
sudo reboot

После перезагрузки снова подключитесь под пользователем deploy. Проверьте синхронизацию времени: корректное время необходимо для TLS-сертификатов, токенов и журналов.

timedatectl status
chronyc tracking

Firewall и Fail2ban

На сервере панели нужно открыть SSH, HTTP и HTTPS. Не публикуйте PostgreSQL, Redis и внутренние Docker-порты. Если вы меняете SSH-порт, сначала откройте новый порт и убедитесь, что можете подключиться.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp comment 'SSH'
sudo ufw allow 80/tcp comment 'HTTP for ACME'
sudo ufw allow 443/tcp comment 'HTTPS panel'
sudo ufw enable
sudo ufw status verbose

Fail2ban на Ubuntu уже содержит базовый фильтр SSH. Создайте локальную настройку с разумным временем блокировки:

sudo tee /etc/fail2ban/jail.d/sshd.local >/dev/null <<'EOF'
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1h
EOF

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Если панель будет принимать соединения от нод по отдельному API-порту, не открывайте его для всего интернета. Либо используйте защищённый HTTPS-адрес панели и токен ноды, либо добавьте точечные правила UFW с IP-адресами нод. Конкретный механизм зависит от версии Remnawave и выбранного режима подключения.

Установка ПО — пошагово

На 2026 год практичный способ запуска Remnawave — Docker Engine и Docker Compose Plugin. Контейнеризация изолирует PostgreSQL, Redis, панель и reverse proxy, а обновление сводится к скачиванию новых образов и перезапуску Compose-стека.

Ниже используются Docker Engine 28.x и Docker Compose v2.x. Точные минорные версии меняются регулярно, поэтому после установки обязательно проверьте фактические версии командами docker version и docker compose version. Для production не фиксируйте критичные сервисы на неподдерживаемых образах latest без процесса тестирования.

Установка Docker Engine

Добавьте официальный репозиторий Docker для Ubuntu 24.04 и установите движок, CLI, Buildx и Compose Plugin.

sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
  sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \
  https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin

Разрешите пользователю deploy управлять Docker без sudo и переподключитесь к SSH-сеансу. Это изменение фактически даёт пользователю административные права на сервер, поэтому не добавляйте в группу docker обычных пользователей.

sudo usermod -aG docker deploy
exit

ssh deploy@SERVER_IP
docker version
docker compose version
docker run --rm hello-world

Создание каталога проекта

Храните все файлы панели в одном каталоге с предсказуемыми правами. В примере используется /opt/remnawave. Владельцем будет пользователь deploy, а доступ к файлу секретов получит только он.

sudo mkdir -p /opt/remnawave/{data,backups,caddy}
sudo chown -R deploy:deploy /opt/remnawave
cd /opt/remnawave
umask 077

Получение официальной конфигурации проекта

Remnawave развивается активно, поэтому имена переменных и состав контейнеров могут меняться между релизами. Перед развёртыванием используйте официальный репозиторий проекта и его файл .env.example как источник истины. Не копируйте Compose-файлы из случайных Telegram-сообщений или старых видеороликов.

cd /opt
sudo git clone https://github.com/remnawave/backend.git remnawave-source
sudo chown -R deploy:deploy /opt/remnawave-source
cd /opt/remnawave-source
git tag --sort=-version:refname | head -n 10

Выберите последний стабильный релизный тег, а не случайную ветку разработки. В примере ниже переменная задаётся вручную: замените значение на тег, отображённый предыдущей командой. Такой подход позволяет воспроизводимо обновляться и откатываться.

export REMNAWAVE_VERSION="v0.0.0"
git checkout "$REMNAWAVE_VERSION"
find . -maxdepth 3 -type f \( -name 'compose.yml' -o -name '.env.example' \) -print

cd /opt/remnawave-source
cp .env.example /opt/remnawave/.env
find . -maxdepth 3 -iname 'compose.yml' -print

cp docker-compose.yml /opt/remnawave/compose.yml
cd /opt/remnawave
chmod 600 .env
nano .env

docker compose --env-file .env -f compose.yml config > /tmp/remnawave-resolved.yml
less /tmp/remnawave-resolved.yml

Бэкапы и обслуживание

Бэкап панели — не копирование одного Docker-контейнера. Критические данные находятся в PostgreSQL, а возможность расшифровать или подключить систему после восстановления зависит от файла .env, ключей приложения и Compose-конфигурации. Резервная копия без секретов может оказаться бесполезной.

Что нужно сохранять

• Логический дамп PostgreSQL: пользователи, ноды, настройки, статистика и подписки.
• Файл /opt/remnawave/.env с паролями и ключами приложения.
• compose.yml, Caddyfile и дополнительные конфигурационные файлы.
• Данные Caddy из /opt/remnawave/data/caddy: сертификаты можно перевыпустить, но их бэкап ускоряет восстановление.
• Документ с DNS-записями, списком нод, открытыми портами и версией Remnawave.

Не рассчитывайте на snapshot VPS как на единственный бэкап. Snapshot полезен перед крупным обновлением, но хранится у того же провайдера и не заменяет регулярную копию в другом месте.

Локальный дамп PostgreSQL

Сначала найдите точное имя PostgreSQL-сервиса в Compose. В примере он называется postgres. Команда создаёт сжатый дамп в каталоге backup.

cd /opt/remnawave
docker compose ps
mkdir -p backups
docker compose exec -T postgres pg_dump \
  -U "$POSTGRES_USER" \
  -d "$POSTGRES_DB" \
  --format=custom \
  | gzip > "backups/remnawave-$(date +%F-%H%M).dump.gz"

Проверьте, что файл не пустой. Для первой проверки полезно выполнить восстановление на отдельном тестовом сервере, а не просто убедиться, что архив создан.

ls -lh backups/
gzip -t backups/remnawave-.dump.gz

Автоматический бэкап с restic

Restic поддерживает шифрование на стороне клиента и S3-совместимые хранилища. Это удобно, потому что внешний storage получает уже зашифрованные данные. Создайте отдельный bucket и отдельные ключи доступа только для бэкапов; не используйте ключи от основного облачного аккаунта с полными правами.

Установите restic:

sudo apt install -y restic
sudo install -d -m 700 /root/.config/restic
sudo nano /root/.config/restic/remnawave.env
sudo chmod 600 /root/.config/restic/remnawave.env

Файл окружения не храните в Git и заполните реальными значениями вашего S3-совместимого хранилища:

export RESTIC_REPOSITORY="s3:https://s3.example.net/remnawave-backups"
export RESTIC_PASSWORD="REPLACE_WITH_LONG_UNIQUE_BACKUP_PASSWORD"
export AWS_ACCESS_KEY_ID="REPLACE_WITH_BACKUP_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="REPLACE_WITH_BACKUP_SECRET_KEY"

Инициализируйте репозиторий один раз. Пароль RESTIC_PASSWORD нужно хранить отдельно от VPS: если он потерян, расшифровать архивы нельзя.

sudo bash -c 'source /root/.config/restic/remnawave.env && restic init'

Создайте скрипт, который делает дамп базы, архивирует конфигурацию, отправляет данные в restic и применяет политику хранения.

sudo nano /usr/local/sbin/backup-remnawave.sh
sudo chmod 700 /usr/local/sbin/backup-remnawave.sh

#!/usr/bin/env bash
set -euo pipefail

APP_DIR="/opt/remnawave"
BACKUP_DIR="${APP_DIR}/backups"
STAMP="$(date +%F-%H%M%S)"

source /root/.config/restic/remnawave.env

mkdir -p "${BACKUP_DIR}"

cd "${APP_DIR}"

docker compose exec -T postgres pg_dump \
  -U "${POSTGRES_USER}" \
  -d "${POSTGRES_DB}" \
  --format=custom | gzip > "${BACKUP_DIR}/postgres-${STAMP}.dump.gz"

tar -C "${APP_DIR}" -czf "${BACKUP_DIR}/config-${STAMP}.tar.gz" \
  .env compose.yml Caddyfile data/caddy 2>/dev/null || true

restic backup "${BACKUP_DIR}" --tag remnawave --tag postgres
restic forget --prune \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

find "${BACKUP_DIR}" -type f -mtime +3 -delete

Запускайте скрипт ежедневно в период низкой нагрузки. Cron удобен для небольшой инфраструктуры:

sudo crontab -e

17 3   * /usr/local/sbin/backup-remnawave.sh >> /var/log/backup-remnawave.log 2>&1

Проверьте запуск вручную и содержимое репозитория:

sudo /usr/local/sbin/backup-remnawave.sh
sudo bash -c 'source /root/.config/restic/remnawave.env && restic snapshots'
sudo tail -n 100 /var/log/backup-remnawave.log

Обновления без потери данных

Для одной панели лучше использовать maintenance window. Обновление backend может включать миграцию базы данных, поэтому сначала создайте проверенный бэкап, прочитайте release notes и зафиксируйте текущую версию. Не обновляйте backend и все ноды одновременно, если не проверили совместимость релизов.

cd /opt/remnawave
sudo /usr/local/sbin/backup-remnawave.sh
docker compose ps
docker compose pull
docker compose up -d
docker compose logs --tail=100
docker compose ps

Для нескольких нод используйте rolling-подход: обновите панель, затем одну малонагруженную ноду, проверьте создание тестового пользователя и подключение, после чего обновляйте остальные ноды по одной. Перед обновлением ноды временно исключайте её из выдачи новых конфигураций или дождитесь снижения числа активных сессий.

Раз в месяц проверяйте место на диске, состояние Docker, размер PostgreSQL и срок действия TLS-сертификата:

df -h
docker system df
docker compose exec -T postgres psql -U "$POSTGRES_USER" -d "$POSTGRES_DB" \
  -c "SELECT pg_size_pretty(pg_database_size(current_database()));"
sudo fail2ban-client status sshd
docker compose logs caddy --tail=50

Troubleshooting + FAQ

Почему Caddy не получает сертификат и в логах есть ошибка ACME?

Сначала проверьте DNS: запись A домена панели должна вести на текущий публичный IPv4 VPS. Затем убедитесь, что порты 80 и 443 открыты одновременно в UFW и во внешнем firewall провайдера. Ошибка часто возникает из-за старой AAAA-записи: ACME-проверка пытается использовать IPv6, который не настроен на сервере. Проверьте dig A и dig AAAA, после чего посмотрите docker compose logs caddy.

Панель открывается по IP, но не работает по домену. Что проверить?

Проверьте, совпадает ли APP_URL с фактическим HTTPS-доменом, и перезапустите Compose после изменения .env. В Caddyfile домен должен быть указан без схемы https:// и без лишнего пути. Убедитесь, что reverse proxy направлен на корректное имя backend-сервиса и его внутренний порт. Команда docker compose config поможет увидеть итоговую конфигурацию и обнаружить нераскрытые переменные окружения.

Контейнер backend постоянно перезапускается. Как найти причину?

Начните с docker compose logs --tail=200 backend. Наиболее частые причины — неверный пароль PostgreSQL, не завершившийся запуск базы, пропущенная обязательная переменная окружения или миграция, несовместимая со старой схемой БД. Проверьте состояние базы через docker compose ps и логи сервиса PostgreSQL. Не удаляйте volumes в попытке «починить» запуск: это удалит пользователей и настройки. Сначала сохраните дамп базы и сравните .env с официальным примером вашей версии.

Нода создана, но в панели остаётся offline. Что делать?

Проверьте URL панели в переменной ноды: он должен начинаться с https:// и использовать домен с действующим сертификатом. Убедитесь, что registration token скопирован без пробелов и относится именно к этой ноде. Посмотрите логи контейнера ноды и проверьте исходящий доступ с ноды на TCP 443 панели командой curl -I https://panel.example.com. Если между серверами есть строгие правила firewall, разрешите исходящие HTTPS-соединения с ноды и входящий 443 на панели.

Пользователь импортировал подписку, но подключение не устанавливается. Что проверить?

Проверьте, назначен ли пользователю активный inbound и online-нода. Затем убедитесь, что inbound-порт открыт в UFW на ноде и не занят другой службой: используйте ss -lntup. Посмотрите логи ноды во время попытки подключения; они покажут, дошёл ли трафик до Xray. Также проверьте срок действия пользователя, лимит трафика и корректность системного времени. Не меняйте вручную UUID, Reality-ключи или параметры inbound в контейнере ноды: источником конфигурации должна оставаться панель.

Какой VPS-конфиг минимально подойдёт?

Для тестовой панели с одной-двумя нодами минимально подойдёт VPS с 1 vCPU, 2 GB RAM, 25 GB SSD или NVMe и сетью от 100 Мбит/с. Для реальной эксплуатации лучше сразу выбрать 2 vCPU, 4 GB RAM и 40 GB NVMe, потому что PostgreSQL, Docker и обновления потребляют дополнительную память. Для каждой небольшой ноды достаточно 1 vCPU, 1–2 GB RAM и 20 GB диска, но пропускную способность и месячный лимит трафика выбирайте по реальному использованию.

Что выбрать — VPS или dedicated для этой задачи?

Для панели управления почти всегда достаточно VPS: она не передаёт основной пользовательский трафик и обычно ограничена работой базы данных, API и статистики. VPS подходит и для малых или средних нод с десятками активных клиентов. Dedicated выбирайте для крупной edge-ноды с постоянной высокой нагрузкой, требованием к 1–10 Гбит/с, большим объёмом трафика или предсказуемой производительности CPU. Практичная стратегия — панель на VPS, а dedicated добавлять только после подтверждённой нагрузки по метрикам.

Можно ли держать панель и первую ноду на одном сервере?

Для лабораторной среды или личного использования это допустимо и снижает стоимость. Однако такой сервер становится единой точкой отказа: при проблемах с сетью, нагрузкой или обновлением одновременно пропадут панель и пользовательские подключения. Кроме того, высокая скорость на ноде может замедлить PostgreSQL и веб-интерфейс. Для production лучше отделить control plane от edge-ноды хотя бы на два VPS. Это также упрощает миграцию и диагностику.

Как восстановить панель после потери VPS?

Создайте новый VPS, установите Docker и разверните тот же совместимый релиз Remnawave. Восстановите .env, Compose-файлы и затем PostgreSQL из дампа. Важно использовать те же секреты приложения, иначе часть зашифрованных данных может стать недоступной. После восстановления переключите DNS на новый IP, дождитесь выпуска TLS-сертификата и проверьте подключение нод. Регулярно тестируйте эту процедуру на отдельной машине: бэкап считается рабочим только после успешного восстановления.

Выводы и следующие шаги

Теперь у вас есть базовая self-hosted инфраструктура Remnawave: защищённая панель с HTTPS, PostgreSQL, резервным копированием и возможностью подключать несколько VLESS/Reality-нод. Главный принцип эксплуатации — отделять панель управления от выходных серверов и не хранить секреты в открытом виде.

1. Добавьте вторую ноду в другом дата-центре и проверьте, что пользователи получают актуальную подписку после изменения назначения.
2. Настройте внешний мониторинг доступности панели, срока TLS-сертификата, загрузки диска и статуса нод.
3. Сделайте тестовое восстановление PostgreSQL и конфигурации на отдельном VPS до первого крупного обновления.

По мере роста нагрузки собирайте фактические метрики одновременных соединений, трафика, CPU и RAM. На их основе масштабируйте именно ноды, а не управляющую панель без необходимости.