Marzban на VPS: мультипротокольна панель Xray із підписками

Що ми налаштовуємо і навіщо

Marzban — адміністративна панель для Xray. Сам Xray відповідає за роботу мережевих вхідних підключень, маршрутизацію трафіку, облік користувачів і підтримувані протоколи. Marzban додає до нього зручний рівень керування: веб-інтерфейс, API, користувачів, ліміти трафіку, терміни дії, підписки, кілька нод і статистику.

Практичний сценарій має такий вигляд: у вас є VPS з публічною IP-адресою та домен. Ви встановлюєте Marzban, підключаєте TLS-сертифікат, створюєте inbound-конфігурації Xray і додаєте користувачів. Після цього користувач отримує персональне посилання на підписку. Він вставляє його в сумісний клієнтський застосунок, а застосунок автоматично отримує список підключень і оновлює його за змін.

Панель особливо зручна, якщо потрібно обслуговувати не одне ручне підключення, а кілька пристроїв або користувачів. Замість генерування окремих JSON-файлів і посилань вручну ви задаєте в панелі ім’я користувача, термін доступу, ліміт трафіку та кількість пристроїв. За потреби доступ можна зупинити однією кнопкою або через API.

Що працюватиме після налаштування

• Веб-панель адміністратора за адресою https://panel.example.com.
• Автоматичний TLS-сертифікат Let’s Encrypt через Caddy.
• Вбудована або задана вручну Xray-конфігурація з кількома inbound-підключеннями.
• Користувачі з UUID, лімітами трафіку, датою завершення дії та персональними subscription-посиланнями.
• Базовий захист хоста: SSH-ключі, UFW, Fail2ban, вимкнений вхід root через SSH.
• Автоматичний архів конфігурації та бази даних у зовнішнє S3-сховище або на інший сервер.

Які протоколи можна використовувати

Marzban не обмежує вас одним методом підключення: набір визначається конфігурацією Xray. Зазвичай на сервері розгортають кілька inbound-профілів для різних клієнтів і мережевих умов. На практиці часто застосовують VLESS із TLS-транспортами, Trojan із TLS і Shadowsocks. Конкретний вибір має відповідати вашому законодавству, правилам дата-центру та вимогам мережі, у якій працюватимуть клієнти.

Self-hosted або керований сервіс

У хмарному керованому сервісі не потрібно обслуговувати сервер, оновлювати систему та налаштовувати бекапи. Мінуси — менший контроль над даними, мережевою конфігурацією, доменом, доступними протоколами та журналами. Крім того, умови роботи сервісу можуть змінюватися без вашої участі.

Self-hosted Marzban на VPS потребує кількох годин початкового налаштування, але дає контроль над інфраструктурою. Ви обираєте регіон, IP-адресу, конфігурацію Xray, правила файрвола, спосіб резервного копіювання та політику доступу адміністраторів. Для власника VPS це зазвичай оптимальний баланс між гнучкістю і трудовитратами.

Не використовуйте панель як «відкритий проксі». Створюйте персональні облікові записи, вмикайте ліміти трафіку та регулярно видаляйте невикористовуваних користувачів. Це знижує ризик зловживань, компрометації та блокування IP-адреси.

Яка VPS-конфігурація потрібна для цього завдання

Сам Marzban майже не навантажує процесор. Основне навантаження створює Xray: шифрування, кількість одночасних з’єднань, обсяг трафіку, що проходить, і вибрані транспорти. Для особистого використання та невеликої команди важливіші стабільна мережа й хороший місячний ліміт трафіку, ніж велика кількість ядер.

Практичний стартовий варіант — 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe і порт 1 Гбіт/с. Він залишає запас для Docker, Caddy, журналів, оновлень і кількох десятків не надто активних користувачів. Можна взяти VPS із зазначеними характеристиками, але під час вибору будь-якого тарифу заздалегідь перевірте місячний ліміт трафіку, доступність IPv4, правила щодо мережевих сервісів і регіон розміщення.

Коли VPS достатньо

VPS підходить майже для всіх стартових сценаріїв: особиста інфраструктура, маленька команда, тестування конфігурацій, до кількох десятків регулярно активних користувачів. У віртуального сервера простіше змінити тариф, швидко перевстановити ОС, створити снапшот і перенести сервіс в інший регіон.

Коли потрібен dedicated

Виділений сервер виправданий, якщо процесор стабільно завантажений шифруванням, ви обслуговуєте сотні активних клієнтів, запускаєте кілька нод на одній машині або критична передбачуваність продуктивності. Також dedicated корисний за потреби у великому диску, мережевому порту понад 1 Гбіт/с або особливих вимогах до мережевих фільтрів. Не переходьте на нього лише через кількість зареєстрованих користувачів: орієнтуйтеся на одночасні підключення, швидкість і реальні графіки CPU/RAM.

На що впливає локація сервера

Локація впливає на затримку, швидкість до цільових ресурсів, доступність IP-адрес і вартість трафіку. Якщо користувачі перебувають в одному регіоні, обирайте дата-центр із мінімальною затримкою до них. Для перевірки перед купівлею можна порівняти публічні looking glass, тестові IP або маршрути через mtr.

Не обирайте локацію лише за географією. Іноді сервер у сусідній країні має вдаліший піринг і помітно кращу реальну швидкість. Після запуску виміряйте затримку з кількох клієнтських мереж, а не лише з домашнього Wi-Fi.

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

Нижче використовується Ubuntu Server 24.04 LTS x86_64. На початок 2026 року це стабільна LTS-гілка з тривалою підтримкою та актуальними пакетами Docker. Починайте з чистого сервера, який має публічну IPv4-адресу та DNS-запис типу A для домену панелі.

До встановлення Marzban створіть DNS-записи. Мінімально потрібні panel.example.com для адмін-панелі та, за бажанням, sub.example.com для видачі підписок. На першому етапі можна використовувати один домен для обох призначень. Запис має вказувати на IPv4 сервера, а проксування на DNS-провайдері потрібно вимкнути, якщо воно заважає випуску TLS-сертифіката або роботі вибраного транспорту.

Підключення та оновлення системи

Увійдіть на сервер під користувачем root, якого надав провайдер, і негайно оновіть базову систему. Перезавантаження потрібне лише якщо оновилося ядро або система прямо повідомляє про необхідність restart.

apt update && apt full-upgrade -y
apt autoremove --purge -y
reboot

Після перезавантаження підключіться знову. Далі створіть окремого користувача-адміністратора. У прикладі використовується ім’я deploy; замініть його на своє.

adduser deploy
usermod -aG sudo deploy
install -d -m 700 -o deploy -g deploy /home/deploy/.ssh

Скопіюйте публічний SSH-ключ із локального комп’ютера. Виконуйте команду локально, а не на VPS. Після успішної перевірки нового входу не закривайте поточну root-сесію, доки не переконаєтеся, що ключ працює.

ssh-copy-id deploy@SERVER_IP
ssh deploy@SERVER_IP

Захист SSH

Відкрийте конфігурацію SSH і забороніть прямий вхід root, автентифікацію за паролем і порожні паролі. Спочатку переконайтеся, що користувач deploy дійсно має робочий ключ.

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

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

Перевірте синтаксис і застосуйте налаштування. Якщо команда sshd -t нічого не вивела, конфігурація коректна.

sudo sshd -t && sudo systemctl restart ssh
sudo systemctl status ssh --no-pager

Базові утиліти, UFW і Fail2ban

Встановіть інструменти діагностики, файрвол і захист від перебору SSH-паролів. Навіть за вимкненої парольної автентифікації Fail2ban корисний як додатковий рівень захисту та для майбутніх сервісів.

sudo apt install -y ca-certificates curl gnupg lsb-release \
  ufw fail2ban jq unzip nano htop tmux \
  dnsutils mtr-tiny chrony

Відкрийте лише SSH, HTTP і HTTPS. Порт панелі Marzban 8000 назовні відкривати не потрібно: Caddy звертатиметься до нього локально. Порти Xray-inbound додаються окремо після того, як ви визначите конфігурацію.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Перевірте синхронізацію часу. Некоректний час ламає TLS, токени та діагностику з’єднань.

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

Якщо ви керуєте сервером через нестандартний SSH-порт, спочатку додайте правило UFW для нового порту та перевірте нове підключення. Лише після цього видаляйте правило для стандартного порту 22.

Встановлення ПЗ — покроково

Marzban поширюється як Docker-образ, а офіційний скрипт встановлення створює каталог, завантажує Compose-конфігурацію та запускає сервіс. Станом на 2026 рік переважно використовувати Docker Engine 27 або новіший і Docker Compose Plugin v2. У production-середовищі не покладайтеся на тег latest, який неможливо перевірити: після успішного запуску зафіксуйте конкретний образ, протестований на вашій машині.

Крок 1. Встановлення Docker Engine з офіційного репозиторію

Видаліть конфліктні старі пакети Docker, якщо вони присутні. Це запобігає конфлікту між пакетами Ubuntu та офіційним Docker Engine.

sudo apt remove -y docker.io docker-compose docker-compose-v2 \
  docker-doc podman-docker containerd runc 2>/dev/null || true

Додайте ключ і репозиторій Docker для Ubuntu 24.04. Команда автоматично використовує архітектуру системи та кодову назву поточного релізу.

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

Встановіть Docker Engine, CLI, containerd і сучасний Compose Plugin. Після встановлення увімкніть сервіс, щоб контейнери запускалися після перезавантаження VPS.

sudo apt install -y docker-ce docker-ce-cli containerd.io \
  docker-buildx-plugin docker-compose-plugin
sudo systemctl enable --now docker
sudo docker version
sudo docker compose version

Додайте користувача deploy до групи Docker. Після цього потрібно вийти з SSH-сесії та підключитися знову, щоб групи застосувалися. Пам’ятайте: членство в групі docker фактично надає привілеї root на сервері.

sudo usermod -aG docker deploy
exit

Крок 2. Встановлення Marzban

Підключіться знову користувачем deploy. Офіційний установчий скрипт Marzban створює робочий каталог /opt/marzban, завантажує Docker Compose і готує сервіс. Перед запуском корисно переглянути завантажуваний скрипт у браузері або через curl, особливо на production-сервері.

ssh deploy@SERVER_IP
curl -fsSL https://github.com/Gozargah/Marzban-scripts/raw/master/marzban.sh \
  -o /tmp/marzban.sh
less /tmp/marzban.sh

Якщо вміст відповідає офіційному репозиторію проєкту, запустіть встановлення. Скрипт запросить sudo-пароль користувача та завантажить потрібні контейнери.

bash /tmp/marzban.sh install

Після встановлення перевірте склад контейнерів. Назви можуть дещо відрізнятися між випусками, але контейнер панелі Marzban має бути запущений, а в логах не повинно бути циклічних помилок.

cd /opt/marzban
sudo docker compose ps
sudo docker compose logs --tail=100 marzban

Крок 3. Створення першого адміністратора

Marzban не повинен мати публічно відомих облікових даних адміністратора. Створіть окремі довгі логін і пароль через CLI всередині контейнера. Не використовуйте для панелі той самий пароль, що й для користувача Linux, пошти або реєстратора домену.

cd /opt/marzban
sudo docker compose exec marzban marzban cli admin create \
  --sudo

Команда в інтерактивному режимі запитає ім’я користувача та пароль. Згенерувати безпечний пароль можна локально або на сервері.

openssl rand -base64 32

Крок 4. Перевірка локального інтерфейсу

До підключення Caddy переконайтеся, що застосунок слухає локальний порт. У типовій установці Marzban використовує порт 8000. Якщо команда не показує порт, що прослуховується, або контейнер постійно перезапускається, перейдіть до розділу troubleshooting, а не публікуйте панель в інтернеті.

sudo ss -ltnp | grep 8000
curl -I http://127.0.0.1:8000

Відповідь може бути 200, 302, 401 або 404 залежно від версії інтерфейсу та маршруту. Головне — отримати HTTP-відповідь від локального процесу, а не помилку підключення.

Конфігурація Marzban, Xray і HTTPS

У цьому розділі панель залишається доступною лише локально на 127.0.0.1:8000, а зовнішній HTTPS приймає Caddy. Така схема не потребує відкривати порт Marzban назовні, спрощує випуск сертифіката та дає змогу централізовано задати HTTP-заголовки.

Перевірка файлів Marzban

Після встановлення перевірте вміст каталогу. Як правило, тут знаходяться docker-compose.yml, .env, каталог даних і шаблон конфігурації Xray. Не публікуйте файл .env у Git, хмарних нотатках або месенджерах: у ньому можуть бути облікові дані та адреса бази даних.

cd /opt/marzban
sudo ls -la
sudo find . -maxdepth 2 -type f | sort
sudo chmod 600 .env

Відкрийте файл середовища та перевірте ключові параметри. Назви змінних можуть дещо відрізнятися в конкретному релізі Marzban, тому не видаляйте автоматично згенеровані рядки. Нижче наведено орієнтир для вбудованої SQLite-бази та локального Uvicorn-сервера.

sudo nano /opt/marzban/.env

# Панель доступна лише локальному reverse proxy
UVICORN_HOST=127.0.0.1
UVICORN_PORT=8000

# Локальна SQLite-база підходить для одного сервера
SQLALCHEMY_DATABASE_URL=sqlite:////var/lib/marzban/db.sqlite3

# Шлях до конфігурації Xray усередині контейнера
XRAY_JSON=/var/lib/marzban/xray_config.json

# Не зберігайте паролі та токени у відкритому репозиторії
# SUDO_USERNAME і SUDO_PASSWORD задаються через CLI або змінні середовища

Якщо інсталяційний Compose-файл публікує 8000:8000 на всі інтерфейси, замініть публікацію порту на localhost. Перед редагуванням зробіть копію файлу. У деяких версіях Marzban використовується режим host network; тоді обмеження виконується через UVICORN_HOST=127.0.0.1.

cd /opt/marzban
sudo cp docker-compose.yml docker-compose.yml.bak
sudo nano docker-compose.yml

services:
  marzban:
    ports:
      - "127.0.0.1:8000:8000"

Не вставляйте цей фрагмент поверх усього файлу: він показує лише потрібну секцію. Збережіть інші volumes, environment, restart policy та налаштування образу, створені інсталятором. Після зміни перевірте YAML і перезапустіть стек.

cd /opt/marzban
sudo docker compose config > /dev/null
sudo docker compose up -d
sudo docker compose ps
curl -I http://127.0.0.1:8000

Встановлення Caddy

Caddy автоматично отримує та продовжує сертифікати Let’s Encrypt, якщо домен вказує на сервер, а порти 80 і 443 доступні ззовні. Встановіть Caddy з офіційного репозиторію. Перед цим переконайтеся, що інший вебсервер не займає порт 80 або 443.

sudo apt install -y debian-keyring debian-archive-keyring \
  apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | \
  sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | \
  sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update && sudo apt install -y caddy

Створіть Caddyfile. Замініть домен, адресу електронної пошти для сповіщень Let’s Encrypt і за потреби список дозволених IP-адрес. Обмеження за IP — корисний захист панелі, якщо у вас статичний домашній IP або VPN-вихід.

sudo nano /etc/caddy/Caddyfile

{
    email [email protected]
}

panel.example.com {
    encode zstd gzip

    @admin {
        path /dashboard /api/admin /docs /openapi.json
    }

    reverse_proxy 127.0.0.1:8000

    header {
        -Server
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "strict-origin-when-cross-origin"
    }

    log {
        output file /var/log/caddy/marzban-access.log
        format json
    }
}

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
sudo systemctl enable --now caddy
sudo systemctl status caddy --no-pager

curl -I https://panel.example.com
sudo journalctl -u caddy -n 100 --no-pager
sudo ufw status numbered

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "vless-main",
      "listen": "0.0.0.0",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "certificates": [
            {
              "certificateFile": "/var/lib/marzban/certs/fullchain.pem",
              "keyFile": "/var/lib/marzban/certs/privkey.pem"
            }
          ]
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

curl -fsS "https://panel.example.com/sub/USER_SUBSCRIPTION_TOKEN" | head
sudo docker compose -f /opt/marzban/docker-compose.yml logs --tail=100 marzban
sudo docker stats --no-stream

curl -4 https://ifconfig.me/ip ; echo
sudo ss -lntup
sudo docker compose -f /opt/marzban/docker-compose.yml logs --tail=200

Резервні копії та обслуговування

Резервна копія Marzban потрібна не для відновлення Docker-образів, а для відновлення стану: бази користувачів, лімітів, токенів, конфігурації Xray, змінних середовища та TLS-налаштувань reverse proxy. Якщо втратити лише контейнер, він створюється повторно. Якщо втратити базу, доведеться заново створювати користувачів і видавати нові subscription-посилання.

Що включати до резервної копії

• /opt/marzban — Compose-файли, .env, дані та шаблони Xray.
• SQLite-файл бази, якщо використовується SQLite; зазвичай він розташований усередині каталогу даних Marzban.
• Дамп PostgreSQL, якщо ви винесли БД в окремий контейнер або сервер.
• /etc/caddy/Caddyfile — конфігурація HTTPS reverse proxy.
• /var/lib/caddy — сертифікати та стан Caddy, якщо ви хочете швидке відновлення.
• Список відкритих портів та інструкції з відновлення, збережені окремо від сервера.

Не зберігайте єдину копію на тому самому VPS. Видалення віртуальної машини, збій диска, злам root-акаунта або помилкова команда rm знищать і сервіс, і локальний архів. Хороша схема — зашифрована restic-резервна копія в S3-сумісне сховище, Backblaze B2 або на окремий VPS через SFTP.

Встановлення restic і підготовка репозиторію

Нижче наведено приклад із S3-сумісним сховищем. Не вставляйте значення ключів у shell history без потреби. Краще зберігати їх у файлі з правами 600.

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

export RESTIC_REPOSITORY="s3:https://s3.example.net/marzban-backups"
export RESTIC_PASSWORD="CHANGE_TO_A_LONG_UNIQUE_BACKUP_PASSWORD"
export AWS_ACCESS_KEY_ID="S3_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="S3_SECRET_KEY"

Ініціалізуйте порожній репозиторій один раз. Якщо команда завершилася успішно, restic створить службову структуру у вказаному bucket.

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

Скрипт резервного копіювання

Перед копіюванням SQLite бажано короткочасно зупинити контейнер або створити узгоджену копію бази. Для невеликого сервера безпечніше зробити коротку паузу Marzban: користувачі з уже запущеними з'єднаннями можуть ненадовго втратити можливість змінювати підписку, але резервна копія буде цілісною. Якщо у вас PostgreSQL, використовуйте pg_dump замість копіювання файлів бази.

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

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

BACKUP_DIR="/var/backups/marzban"
STAMP="$(date +%F-%H%M%S)"

mkdir -p "$BACKUP_DIR"

cd /opt/marzban
docker compose stop marzban

tar --xattrs --acls -czf "$BACKUP_DIR/marzban-$STAMP.tar.gz" \
  /opt/marzban \
  /etc/caddy/Caddyfile \
  /var/lib/caddy 2>/dev/null || true

docker compose start marzban

source /root/.config/restic/marzban.env
restic backup "$BACKUP_DIR" --tag marzban --tag "$(hostname)"
restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

find "$BACKUP_DIR" -type f -mtime +2 -delete

Перевірте скрипт вручну перед автоматизацією. Після виконання має з'явитися snapshot у restic, а контейнер Marzban повинен знову бути у стані Up.

sudo /usr/local/sbin/backup-marzban.sh
sudo bash -c 'source /root/.config/restic/marzban.env && restic snapshots'
sudo docker compose -f /opt/marzban/docker-compose.yml ps

Автоматичний запуск через cron

Запускайте резервне копіювання вночі щодня. Cron підходить для простого одиночного завдання; якщо серверів багато, зручніше перейти на systemd timer, Ansible або централізовану систему резервного копіювання.

sudo crontab -e

25 3    /usr/local/sbin/backup-marzban.sh >> /var/log/backup-marzban.log 2>&1

Щонайменше раз на квартал виконуйте тестове відновлення на окремій тимчасовій машині. Резервну копію, яку ніколи не перевіряли відновленням, не можна вважати робочою. Для перегляду вмісту архіву використовуйте restic restore у тестовий каталог, не перезаписуючи production-файли.

Оновлення Marzban і системи

Для одного VPS оновлюйте Marzban у maintenance window: попередьте користувачів, зробіть резервну копію, завантажте образ, перезапустіть контейнер і перевірте логи. Це безпечніше, ніж оновлювати вночі навмання через cron. Автоматичне застосування security-updates для Ubuntu допустиме, але major-оновлення Docker, Marzban і Xray краще контролювати вручну.

cd /opt/marzban
sudo /usr/local/sbin/backup-marzban.sh
sudo docker compose pull
sudo docker compose up -d
sudo docker image prune -f
sudo docker compose logs --tail=100 marzban

За наявності кількох нод застосовуйте rolling-оновлення: спочатку оновіть одну найменш завантажену ноду, перевірте підключення та метрики, потім оновлюйте решту. Не оновлюйте одночасно панель, усі Xray-ноди, ОС і схему бази даних: у разі проблеми буде неможливо швидко визначити причину.

Troubleshooting і FAQ

Чому панель не відкривається через HTTPS і Caddy пише помилку отримання сертифіката?

Спочатку перевірте DNS: dig +short panel.example.com A має повернути IP вашого VPS. Потім переконайтеся, що порти 80 і 443 відкриті в UFW та в мережевому файрволі провайдера. Перевірте, чи не запущений інший вебсервер: sudo ss -ltnp | grep -E ':80|:443'. У логах journalctl -u caddy часто прямо зазначено причину: неправильний DNS, закритий порт, rate limit або конфлікт сервісів.

Чому Caddy повертає 502 Bad Gateway?

Помилка 502 означає, що Caddy працює, але не може підключитися до Marzban. Перевірте контейнер: sudo docker compose -f /opt/marzban/docker-compose.yml ps. Потім виконайте curl -I http://127.0.0.1:8000 на самому VPS. Якщо відповіді немає, вивчіть логи контейнера та перевірте значення UVICORN_HOST/UVICORN_PORT у .env. Після виправлень застосуйте docker compose up -d і перезавантажте Caddy.

Чому контейнер Marzban постійно перезапускається?

Виконайте sudo docker compose logs --tail=200 marzban. Поширені причини: синтаксична помилка в .env, пошкоджений YAML Compose, недоступний файл Xray JSON, конфлікт порту або нестача місця на диску. Перевірте вільне місце командою df -h і пам'ять через free -h. Перед зміною конфігурації відновіть резервну копію файла, наприклад docker-compose.yml.bak, потім запускайте docker compose config для перевірки.

Користувач імпортував subscription URL, але підключення не працюють. Що перевіряти?

Перевірте окремо три рівні: subscription URL, inbound Xray і клієнт. Спочатку відкрийте посилання через curl: воно має повернути конфігурації, а не HTML-сторінку помилки. Потім переконайтеся, що потрібний порт inbound прослуховується через ss -lntup і дозволений UFW. Насамкінець перевірте домен, SNI, UUID, TLS-сертифікат і системний час клієнта. Почніть з одного простого inbound і одного тестового користувача.

Чому трафік користувача не враховується або ліміт не вимикає доступ?

Спочатку перевірте, що користувач підключається саме через inbound, яким керує Marzban, а не через старий вручну запущений Xray-процес. Перегляньте логи та статистику в панелі після нового підключення. Помилка часто виникає, якщо JSON Xray відредагований вручну та втратив шаблон клієнтів Marzban. Не змінюйте структуру користувацьких об'єктів без розуміння шаблонів панелі. Після зміни конфігурації створіть нового тестового користувача і перевірте його окремо.

Яка VPS-конфігурація мінімально підійде?

Мінімум для особистого використання — 1 vCPU, 2 ГБ RAM, 20 ГБ SSD/NVMe, публічний IPv4 і порт від 100 Мбіт/с. Такий сервер підходить для кількох пристроїв і 1–10 не надто активних користувачів. Для комфортнішої експлуатації краще почати з 2 vCPU і 4 ГБ RAM: з'явиться запас для Docker, логів, Caddy, оновлень і короткочасних піків навантаження. Найважливіше перевірити ліміт трафіку та якість мережі.

Що вибрати — VPS чи dedicated для цього завдання?

Для більшості встановлень Marzban обирайте VPS: він дешевший, швидше розгортається, легко масштабується за тарифом і підходить для десятків активних користувачів. Dedicated потрібен за стабільно високого навантаження CPU, сотень одночасних клієнтів, кількох нод на одному сервері, вимог до великого диска або порту понад 1 Гбіт/с. Ухвалюйте рішення за метриками: якщо CPU тримається вище 70%, зростає latency і з'являються втрати швидкості, час розглядати виділений сервер або горизонтальне масштабування.

Чи можна відкрити панель на порту 8000 напряму?

Технічно можна, але для production це погана практика. Прямий HTTP-доступ передає пароль адміністратора без захисту, а відкритий порт спрощує сканування й атаки. Залиште Marzban на 127.0.0.1:8000, а назовні публікуйте лише Caddy через HTTPS на 443. Якщо потрібен тимчасовий доступ для діагностики, використовуйте SSH-тунель: ssh -L 8000:127.0.0.1:8000 deploy@SERVER_IP, потім відкрийте локальну адресу в браузері.

Як відновити Marzban після перенесення на новий VPS?

Встановіть Docker, Marzban і Caddy на новому сервері, але не створюйте нових користувачів поверх старої бази. Скопіюйте архів із restic у тимчасовий каталог, зупиніть Marzban, відновіть /opt/marzban і Caddyfile, встановіть коректні права, потім запустіть Compose. Після зміни IP оновіть DNS і дочекайтеся поширення запису. Перевірте панель, subscription URL, сертифікат і тестове підключення до остаточного вимкнення старого VPS.

Висновки та наступні кроки

Тепер у вас є Marzban на VPS з Docker, захищеним SSH, HTTPS-панеллю, базовою мережевою фільтрацією та автоматичним резервним копіюванням. Панель дає змогу централізовано створювати користувачів Xray, видавати підписки та контролювати строки дії або ліміти трафіку.

1. Додайте один-два додаткові inbound-профілі лише після тестування базової конфігурації на реальному клієнті.
2. Налаштуйте моніторинг CPU, RAM, диска, доступності HTTPS і дати останньої успішної резервної копії.
3. У разі зростання навантаження винесіть PostgreSQL і Xray-ноди на окремі сервери, зберігши Marzban як центральну панель керування.

Регулярно перевіряйте логи, тестуйте відновлення з резервної копії та оновлюйте компоненти у заплановане вікно обслуговування. Це важливіше за складну конфігурацію: стабільний, документований і відновлюваний сервер надійніший за набір неперевірених налаштувань.