Life After 3X-UI [RU]

docs/learn/life-after-3x-ui.md

@@ -0,0 +1,389 @@
+---
+sidebar_position: 3
+title: Жизнь после 3X-UI
+---
+
+# Как жить с Remnawave после перехода с 3X-UI?
+
+Этот небольшой гайд направлен на то, чтобы вы смогли понять **ключевые архитектурные отличия Remnawave** от панели **3X-UI** (и её форков), а также перестроить мышление после перехода на новую модель управления.
+
+<!-- truncate -->
+
+---
+
+## Как это выглядело в 3X-UI
+
+После установки **3X-UI** вам обычно не требуется никаких дополнительных настроек.  
+Типичный сценарий работы:
+
+1. Устанавливается панель  
+2. Создаётся инбаунд (host / inbound)  
+3. Внутри инбаунда создаётся пользователь  
+4. Копируется ссылка — клиент может подключаться  
+
+На старте такой подход кажется простым, понятным и удобным.
+
+Однако есть важный нюанс: в 3X-UI пользователь создаётся **внутри конкретного инбаунда**.  
+Если одному пользователю требуется доступ к нескольким инбаундам, его нужно вручную создавать в каждом из них отдельно.
+
+Это не всегда заметно сразу, но начинает создавать неудобства по мере роста конфигурации и количества серверов.
+
+### Почему так работает?
+
+Потому что ядро **XRAY уже встроено в панель 3X-UI**.  
+Устанавливая 3X-UI, вы сразу получаете:
+
+- панель управления  
+- ядро XRAY  
+- конфигурацию и обработку трафика в одном месте  
+
+С одной стороны — это просто и доступно.  
+С другой — именно здесь скрыта основная проблема.
+
+---
+
+## Основная проблема архитектуры 3X-UI
+
+Проблемы начинаются, когда вам нужно:
+
+- несколько серверов  
+- разные локации (EU, RU, US и т.д.)  
+- масштабирование проекта  
+- разделение нагрузки  
+
+В этот момент у вас практически нет гибких вариантов.
+
+Единственное решение:  
+установить **полную копию 3X-UI на каждый сервер**.
+
+### Чем это плохо
+
+- на каждой ноде разворачивается целая панель  
+- пользователи дублируются  
+- конфигурации нужно синхронизировать вручную  
+- обновления превращаются в боль  
+- любая ошибка масштабируется вместе с инфраструктурой  
+
+Формально это работает,  
+но каждая новая нода = новая головная боль.
+
+---
+
+## Какое решение предлагает Remnawave?
+
+Решение довольно простое:  
+**разделить ответственность компонентов**.
+
+---
+
+## Архитектурный подход Remnawave
+
+Remnawave полностью изолирует:
+
+### Панель
+
+Панель отвечает только за управление:
+
+- пользователи  
+- инбаунды  
+- хосты  
+- подписки  
+- статистика и учёт трафика  
+
+### Ноды
+
+Ноды отвечают только за обработку трафика:
+
+- ядро XRAY  
+- сетевые подключения  
+- реальный выход в интернет  
+
+Именно это является ключевым отличием Remnawave и других панелей, которые не являются форками 3X-UI.
+
+---
+
+## Что вы видите после установки Remnawave
+
+После установки Remnawave в браузере перед вами **просто панель управления**.
+
+Внутри панели **нет ядра XRAY**.
+
+Это означает:
+
+- какие бы конфиги XRAY вы ни редактировали,  
+- как бы ни пытались подключиться напрямую —  
+
+подключения не будет, потому что подключаться просто некуда.
+
+И это нормально.
+
+---
+
+## Что нужно сделать дальше?
+
+Нужно развернуть дополнительный компонент —  
+**Remnawave Node (Remnanode)**.
+
+Именно в ноде:
+
+- находится ядро XRAY  
+- принимаются подключения клиентов  
+- обрабатывается весь трафик  
+
+Панель управляет,  
+ноды работают.
+
+---
+
+## Можно ли ставить панель и ноду вместе?
+
+Технически — да.
+
+Но:
+
+- это плохая практика  
+- это небезопасно  
+- это ломает саму идею архитектуры  
+
+Учитесь разделять:
+
+- административные ресурсы  
+- публично доступные ресурсы  
+
+Если всё же очень нужно, существуют установочные скрипты, которые позволяют развернуть панель и ноду на одном сервере за несколько кликов, иногда даже с готовым конфигом.
+
+---
+
+## Термины Remnawave: хосты, инбаунды, пользователи
+
+### Какая перед нами задача?
+
+Дать клиенту:
+
+- один сервер  
+  **или**  
+- список серверов  
+
+к которым он сможет подключаться из своего приложения.
+
+---
+
+## Как это устроено в Remnawave
+
+Конечный пользователь получает **URL**, который называется **подпиской**.
+
+В подписке:
+
+- содержится список хостов  
+- именно к ним клиент и подключается  
+
+---
+
+## Инбаунды
+
+Инбаунд — это сущность из конфигурации ядра XRAY.
+
+Обычно он включает:
+
+- протокол  
+- методы шифрования  
+- network / security  
+- sniffing и другие параметры  
+
+В актуальной версии Remnawave инбаунды больше не создаются «руками» в интерфейсе ноды.  
+Панель работает через **Профили конфигураций (Config Profiles)**, которые описывают полный конфиг Xray для группы нод, включая список инбаундов.
+
+Основные моменты:
+
+- инбаунды определяются внутри профиля конфигурации  
+- панель считывает инбаунды из профиля и отображает их как доступные сущности  
+- при изменении профиля пересобирается список инбаундов, а перезапускаются только ноды, использующие этот профиль  
+
+Рекомендуется изучить официальную документацию XRAY, чтобы уверенно работать с этой частью.
+
+---
+
+## Хосты
+
+Когда у вас есть готовый инбаунд,  
+к нему создаётся **хост**.
+
+В хосте указывается:
+
+- адрес (IP или домен)  
+- порт (обычно соответствует порту инбаунда)  
+- инбаунд, к которому он привязан  
+
+Важно: в адресе указывается **нода**, а не панель.  
+Если нода и панель находятся на одном сервере — тогда да, адрес совпадает.
+
+Хост — это финальная сущность, которую:
+
+- видит пользователь  
+- использует клиентское приложение  
+- реально использует для подключения  
+
+---
+
+## Профили конфигураций (Config Profiles)
+
+В Remnawave все инбаунды объединены в **Профили конфигураций**.
+
+Профиль конфигурации:
+
+- содержит полный конфиг ядра Xray (inbounds, outbounds, routing и т.д.)  
+- может быть назначен нескольким нодам  
+- определяет, какие инбаунды вообще доступны для этих нод  
+
+Главные эффекты:
+
+- вы редактируете конфиг один раз на уровне профиля, а не на каждой ноде  
+- при изменении профиля перезапускаются только ноды, которые его используют  
+
+На уровне ноды вы выбираете:
+
+- какой профиль конфигурации она использует  
+- какие инбаунды из этого профиля будут активны именно на этой ноде  
+
+Профиль задаёт «множество возможных» инбаундов, а нода включает только нужные ей.
+
+---
+
+## Внутренние сквады: доступ пользователей к инбаундам
+
+### Что такое внутренние сквады
+
+**Внутренние сквады (Internal Squads)** — это группы доступа для пользователей.  
+Если профили конфигураций описывают поведение нод, то внутренний сквад описывает, **какие инбаунды доступны конкретным пользователям**.
+
+Внутренний сквад позволяет:
+
+- выбрать любые инбаунды из доступных профилей конфигураций  
+- задать, к каким протоколам, локациям и серверам получат доступ участники сквада  
+
+Один пользователь может одновременно состоять в нескольких внутренних сквадах, что даёт гибкую модель прав.
+
+---
+
+### Как внутренняя логика заменяет старую систему
+
+Раньше доступ пользователя к нодам и инбаундам задавался напрямую через связки вида «пользователь → инбаунд/нода».  
+Это было плохо масштабируемо и неудобно при большом количестве пользователей и конфигураций.
+
+Теперь используется двухступенчатая модель:
+
+1. **Ноды ↔ Профили конфигураций**  
+   - профиль определяет набор инбаундов и общую логику работы Xray  
+   - нода выбирает профиль и активные инбаунды из этого профиля  
+
+2. **Пользователи ↔ Внутренние сквады ↔ Инбаунды**  
+   - сквад определяет набор инбаундов, доступных участникам  
+   - пользователь получает доступ ко всем инбаундам, включённым во все сквады, в которых он состоит  
+
+В результате:
+
+- вы больше не привязываете пользователя вручную к конкретной ноде или инбаунду  
+- вы мыслите группами: «обычные пользователи», «премиум», «тестеры», «RU», «EU» и т.д.  
+- чтобы изменить права, достаточно отредактировать сквад или членство пользователя в нём  
+
+---
+
+### Практические сценарии внутренних сквадов
+
+Примеры:
+
+- **Regular**  
+  - ограниченный набор инбаундов (пара стабильных RU/EU серверов)  
+  - все новые пользователи автоматически попадают сюда  
+
+- **Premium**  
+  - расширенный набор инбаундов (больше локаций, отдельные быстрые ноды, экспериментальные маршруты)  
+  - при апгрейде тарифа пользователя просто добавляют в этот сквад  
+
+- Сквады по регионам  
+  - отдельные сквады для специфичных стран/регионов  
+  - один пользователь может одновременно быть, например, в скваде EU и Premium  
+
+Такой подход превращает изменение логики доступа в несколько кликов по сквадам, без массовой ручной правки связок «пользователь–инбаунд».
+
+---
+
+## Пользователи и подписки
+
+Когда:
+
+- создан профиль конфигурации и нужные инбаунды  
+- нодам назначены профили и включены нужные инбаунды  
+- для этих инбаундов созданы хосты  
+- настроены внутренние сквады с нужными инбаундами  
+- пользователь добавлен в один или несколько сквадов  
+
+можно выдавать пользователю подписку.
+
+При создании пользователя:
+
+- ему назначаются один или несколько внутренних сквадов  
+- автоматически формируется подписка, которая включает только те хосты и инбаунды, к которым у него есть доступ через эти сквады  
+
+Подписка — это ссылка, которую нужно вставить в совместимое приложение (например, **Happ**).  
+После этого пользователь видит все доступные ему хосты и может к ним подключаться.
+
+---
+
+## Отличия подписок: Remnawave vs 3X-UI
+
+### Remnawave
+
+Remnawave выдаёт **одну универсальную подписку**, которая:
+
+- автоматически подстраивается под клиент  
+- формируется под нужное ядро  
+- работает без дополнительных действий со стороны пользователя  
+
+Поддерживаются:
+
+- XRAY (JSON / links)  
+- Sing-box  
+- Mihomo (Clash Meta)  
+- Stash  
+
+Пользователю не нужно выбирать тип подписки.
+
+---
+
+### 3X-UI
+
+В 3X-UI:
+
+- существуют разные ссылки:  
+  - обычная base64-подписка  
+  - JSON-подписка  
+- отсутствует выдача подписок под Sing-box  
+- нет поддержки Mihomo  
+
+Пользователь должен сам понимать:
+
+- какую ссылку  
+- в какое приложение  
+- и зачем вставлять  
+
+Это создаёт лишнюю сложность и для пользователя, и для администратора.
+
+---
+
+## Итог
+
+**Remnawave**:
+
+- построен на разделении ролей (панель ↔ ноды)  
+- использует **Профили конфигураций** для управления конфигами Xray и инбаундами  
+- использует **Внутренние сквады** как основную модель управления доступом пользователей  
+- хорошо масштабируется и не требует дублирования панелей  
+- выдаёт универсальные подписки и поддерживает современные клиенты и ядра  
+
+**3X-UI**:
+
+- удобен на старте  
+- архитектурно ограничен  
+- плохо масштабируется  
+- становится проблемным при росте проекта