Marzneshin на VPS: управление узлами для обхода блокировок
Marzneshin - это переписанный с нуля наследник панели Marzban от той же команды Gozargah. Главное отличие от классического Marzban в том, что мультинодовая архитектура здесь не плагин, а основа дизайна: один центральный сервер управляет десятками выходных нод в разных странах. Это меняет правила игры при блокировках: когда РКН заносит один выходной IP в реестр, ваши пользователи просто переключаются на ноду в другой стране, не меняя подписку. Эта страница - о том, как развернуть Marzneshin на офшорном VPS, правильно разнести инбаунды по узлам и построить сеть, которую не уронит блокировка одного адреса.
Need this done for your project?
We implement, you ship. Async, documented, done in days.
Marzneshin как наследник Marzban: что изменилось
Marzban был самой популярной панелью управления Xray для раздачи доступа: подписки, лимиты трафика, сроки, мультипротокольные инбаунды. Но мультинодовость в нём пришивалась поверх изначально одноузловой модели, и при росте сети это упиралось в архитектурные ограничения. Команда Gozargah ответила новым проектом - Marzneshin, переписанным заново с расчётом на распределённую сеть с самого начала.
Ключевые отличия для тех, кто строит устойчивую к блокировкам инфраструктуру:
- Ноды - первоклассная сущность, а не аддон. Центральная панель и выходные ноды разделены изначально. Панель хранит пользователей, статистику и логику, ноды занимаются только проксированием трафика.
- Сервисы (services) вместо плоского списка инбаундов. Пользователь привязывается к сервису, а сервис - к набору инбаундов на разных нодах. Это и есть механизм разнесения по странам.
- gRPC-связь между панелью и нодами с взаимной TLS-аутентификацией по сертификатам - панель и ноды можно держать на разных VPS в разных юрисдикциях.
- Обновлённый REST API и веб-интерфейс, подписки в форматах для v2rayNG, sing-box, Clash и Hiddify.
Если у вас уже работает Marzban и одна нода вас устраивает - мигрировать ради миграции не нужно. Marzneshin раскрывается именно тогда, когда нод становится несколько и важна отказоустойчивость на уровне выходных IP.
Архитектура: одна панель, много выходных нод
Правильная топология для обхода блокировок выглядит так. Центральная панель Marzneshin стоит на отдельном VPS, который никогда не отдаёт пользовательский трафик наружу - на нём только база данных, API и веб-морда. Выходные ноды стоят на других VPS в разных странах и именно их IP видят и Xray-клиенты пользователей, и РКН.
[ Клиенты / подписки ]
|
( единая ссылка-подписка )
|
+-------------------+-------------------+
| | |
[ Нода FI ] [ Нода IS ] [ Нода RO ]
inbound 443 inbound 443 inbound 8443
Финляндия Исландия Румыния
\ | /
\ | /
+----- gRPC + mTLS -----+---------+
|
[ Панель Marzneshin ]
(отдельный VPS, без выхода)Смысл разделения: панель - это ваш центр управления и единственное место, где лежат данные пользователей. Если выходную ноду заблокируют или изымут, на ней нет ни списка клиентов, ни статистики - только Xray и сертификат для связи с панелью. А пользователь продолжает работать через оставшиеся ноды по той же самой ссылке-подписке.
Установка панели на офшорный VPS
Панель ставится на чистую систему (Debian 12 или Ubuntu 22.04+) с root-доступом. Официальный установочный скрипт ставит саму панель в Docker:
sudo bash -c "$(curl -sL https://github.com/marzneshin/Marzneshin/raw/master/script.sh)" @ installПосле установки создайте администратора и откройте панель. Доступ к веб-интерфейсу и API закрывайте сразу - наружу должен смотреть только реверс-прокси с TLS:
# создать первого администратора
marzneshin cli admin create --sudo
# статус и логи
marzneshin status
marzneshin logsМинимальная гигиена безопасности панели:
- Веб-панель - только за реверс-прокси с HTTPS (Caddy или Nginx) и, желательно, на нестандартном пути. Не публикуйте дашборд на голом порту.
- База данных по умолчанию SQLite; для сети из многих нод и тысяч пользователей переключитесь на MariaDB/MySQL ради конкурентной записи статистики.
- Регулярный бэкап тома с БД и сертификатами: панель - единая точка отказа всей сети, и её потеря болезненнее потери ноды.
Поскольку панель не отдаёт пользовательский трафик, её IP можно вообще не светить клиентам - они подключаются к нодам, а не к панели.
Подключение нод и разнесение инбаундов по странам
Нода - это отдельный VPS, на котором крутится только агент Marzneshin-node и Xray. Установка агента:
sudo bash -c "$(curl -sL https://github.com/marzneshin/marzneshin-node/raw/master/script.sh)" @ installДальше нода регистрируется в панели через раздел Nodes: вы указываете её адрес и порт gRPC, панель выдаёт пару сертификатов для взаимной TLS-аутентификации, и узел появляется онлайн. После этого создаются инбаунды - на каждой ноде свои:
- Нода в Финляндии: VLESS+Reality на 443 (низкая задержка до Москвы, прямой пиринг - лучший вариант для повседневной работы).
- Нода в Исландии: VLESS+Reality на 443 с другим dest (максимальная приватность юрисдикции, резерв на случай блокировки финского IP).
- Нода в Румынии: например, Hysteria2 на UDP-порту - другой протокол и другой транспорт, чтобы блокировка по TCP/443 не уронила сразу всё.
Затем эти инбаунды объединяются в сервис, а пользователь привязывается к сервису. В результате его единственная ссылка-подписка содержит конфиги сразу для всех трёх нод. Клиент (v2rayNG, sing-box, Hiddify) сам переключается между ними при недоступности одной из них.
Практическое правило разнесения: не складывайте все яйца в один протокол и одну страну. Если все ваши инбаунды - это VLESS+Reality на 443, то одно удачное для РКН правило фильтрации бьёт по всем нодам сразу. Микс из Reality (TCP/443) и Hysteria2 (UDP) на разных IP в разных юрисдикциях означает, что для полного отключения вашей сети противнику нужно заблокировать несколько разных векторов одновременно.
Устойчивость к блокировкам: почему важна география нод
Главная ценность мультинодовой схемы - не нагрузка, а отказоустойчивость по IP. Когда выходной адрес попадает в реестр блокировок, в одноузловой схеме у вас падает всё и всем нужно срочно перевыпускать конфиги. В Marzneshin вы просто отключаете проблемную ноду в панели или меняете на ней IP/порт - подписка пользователей не меняется, потому что в ней зашиты все ноды сразу.
Несколько рекомендаций по построению сети, переживающей блокировки:
- Минимум две страны. Финляндия для скорости плюс Исландия или Румыния как резерв в другой юрисдикции.
- Свежие, не засвеченные IP. Ноду имеет смысл ставить на IP, который раньше не числился в публичных VPN-реестрах - иначе он может прийти к вам уже частично заблокированным.
- Разные подсети и провайдеры. Две ноды в одном дата-центре в соседних /24 - слабая защита: блок по диапазону уберёт обе.
- Панель отдельно от нод. Держите центральный VPS подальше от боевых выходных IP - его компрометация дороже.
Для такой схемы нужны VPS вне российской юрисдикции, с чистыми IP и root-доступом. Наши офшорные VPS в Финляндии, Исландии и Румынии подходят и под панель, и под ноды: чистые выходные IP, не числившиеся в VPN-реестрах, мгновенный root после оплаты, регистрация только по email без KYC, оплата Bitcoin, Monero и USDT TRC-20. Финляндия даёт минимальный пинг до Москвы, Исландия - наилучшую приватность юрисдикции. Если нод и пользователей много и нужна стабильная производительность для центральной панели и статистики, рассмотрите выделенный сервер с гарантированными ядрами под панель и отдельные VPS под выходные ноды.
Похожие услуги
Privacy & anti-censorship guides
Why Anubiz Host
Ready to get started?
Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.