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

Усунення несправностей + 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. На їхній основі масштабуйте саме ноди, а не панель керування без потреби.