Ротация путей Client → Entry

Проблема #

Entry-нода — расходный узел с коротким жизненным циклом. При замене сервера меняется IP-адрес. Если клиент подключается напрямую к IP или по жестко заданному домену конкретного сервера, любая ротация Entry требует ручной выдачи новой ссылки каждому пользователю.

При масштабировании сети это становится операционной проблемой.

Привязка к домену, а не к серверу #

Пользователь подключается к домену, а не к IP-адресу конкретного сервера. Домен закреплен за ролью Entry в регионе — и может быть переназначен на новый IP при замене ноды.

Для пользователя смена Entry выглядит как кратковременный перерыв в подключении во время переключения DNS — не более.

serviceName как адрес эндпоинта #

Клиентский VLESS-трафик идёт не просто на домен, а на конкретный путь — serviceName. Nginx на Entry маршрутизирует запросы именно по этому пути:

https://<DOMAIN>/api.v2.rpc.<serviceName>  →  Xray
https://<DOMAIN>/*                          →  сайт-прикрытие

serviceName — случайная строка, уникальная для Entry-ноды. Наблюдатель, не знающий пути, не может отличить трафик от обращений к обычному сайту: все неизвестные запросы возвращают легитимный HTML.

При замене Entry новая нода наследует serviceName предыдущей — клиентские ссылки остаются рабочими.

Механизм подписки #

Вместо статической VLESS-ссылки клиент получает subscription URL — адрес эндпоинта, который в любой момент возвращает актуальную конфигурацию подключения.

https://<DOMAIN>/api/<UUID>

Клиент периодически обращается к этому адресу и автоматически обновляет профили подключения. При изменении serviceName или любого другого параметра — пользователь получит актуальную конфигурацию при следующем обновлении подписки, без каких-либо ручных действий.

Subscription-микросервис #

На каждой Entry-ноде развёртывается легковесный HTTP-микросервис — часть стандартной процедуры установки ноды. Nginx направляет запросы вида /api/<UUID> к нему:

location /api/ {
    proxy_pass http://127.0.0.1:<PORT>;
}

Микросервис:

1. Получает UUID из пути запроса.
2. Проверяет, что устройство с таким UUID существует и активно (по локальному клону registry).
3. Формирует VLESS-ссылку с актуальным serviceName для этой Entry.
4. Возвращает конфигурацию в формате, совместимом с клиентами (base64).

Данные берутся из локального клона registry — без обращений к внешним сервисам.

UUID как токен подписки #

UUID устройства выполняет двойную роль: это одновременно идентификатор в Xray (аутентификация VPN-подключения) и токен доступа к subscription-эндпоинту.

Разделять их нет смысла: компрометация subscription URL неизбежно раскрывает UUID из ответа микросервиса. Оба секрета имеют одинаковый уровень чувствительности и единый жизненный цикл — они создаются вместе при регистрации устройства и выводятся из оборота вместе при его архивировании.

Subscription URL не хранится на серверах — он существует только на устройстве пользователя и доставляется однократно при регистрации.

Что происходит при ротации serviceName #

1. Новый serviceName генерируется и записывается в registry.
2. Обновляются конфиги Nginx и Xray на Entry-ноде.
3. При следующем обращении клиента к /api/<UUID> микросервис возвращает ссылку с новым serviceName.
4. Клиент автоматически обновляет профиль.

Пользователь не вовлечён в процесс.

Что происходит при замене Entry-ноды #

1. Поднимается новый сервер.
2. Выполняется стандартная процедура развёртывания Entry: устанавливаются Nginx, Xray, subscription-микросервис. serviceName и конфигурации пользователей переносятся из registry.
3. DNS-запись домена переключается на новый IP.
4. В registry обновляется привязка домена к новому узлу.
5. Старая нода выводится из оборота.

Subscription URL пользователя не меняется — он содержит домен, а не IP.

Что происходит при компрометации устройства #

1. Устройство архивируется в registry — UUID выводится из конфига Xray на Entry.
2. Создаётся новое устройство с новым UUID.
3. Новый subscription URL доставляется пользователю через административный интерфейс.

Схема #

Сводная таблица #