# Закрепление ноды, адреса и SNI за пользователем на стороне backend

**URL:** https://f.docs.rw/t/topic/786
**Category:** Предложения
**Created:** 2026-09-28T00:02:46Z
**Posts:** 4

## Post 1 by @Gh1 — 2026-09-28T00:02:46Z

Предлагаю добавить в backend Remnawave механизм постоянных персональных назначений: возможность закрепить за пользователем определённую ноду, адрес подключения (IP/домен) или SNI-маршрут. Хотелось бы управлять этим из панели, а применять назначения при генерации подписки независимо от используемой страницы подписки и способа её получения.

## Общий пул и сохранение выбора

Администратор создаёт общий пул допустимых подключений, а backend выбирает подходящий элемент и сохраняет привязку к UUID пользователя. При последующих обновлениях пользователь получает свежую подписку, но с тем же назначением, без случайной смены ноды на каждом запросе.

Для начала было бы достаточно случайного распределение в процентном соотношении, backend выбирает элемент при первом получении подписки и сохраняет результат

В дальнейшем можно добавить выбор ближайшей ноды или входного сервера по GeoIP, распределение по весам и лимитам, предпочтения по странам, ручное назначение. Алгоритм первоначального выбора при этом должен быть отделён от сохранения привязки.

## Независимые назначения и плейсхолдеры

Важно предусмотреть независимое закрепление входного адреса. Например, пользователь подключается через `msk.example.com`, а SNI `fi-04.example.com` указывает на заранее настроенный маршрут (если есть балансировщик); смена входа на `spb.example.com` не должна автоматически менять закреплённый выход.

Одним из вариантов реализации могли бы стать общие пулы и персональные плейсхолдеры в Hosts/Templates: backend подставляет адрес, порт и SNI из сохранённого назначения. Это предложение нового механизма, а не требование конкретного синтаксиса переменных.

Выбирать желательно целую совместимую запись подключения, а не независимо случайные address и SNI. Назначение должно учитывать учётные данные и TLS/REALITY-параметры, чтобы подстановка не создавала неработающую конфигурацию.

## Дальнейшее развитие

Можно предусмотреть несколько независимых назначений одного пользователя: разные хосты В панели было бы удобно видеть текущий выбор, менять его вручную, устанавливать пин и явно запускать перераспределение.

Главная идея: **backend хранит назначения и формирует персонализированную подписку, а subscription-page только отображает результат**. Закрепление при этом означает сохранение выбранной ноды или маршрута, а не гарантию выделенного внешнего IP.

---

## Post 2 by @morningstar2808 — 2026-09-28T00:11:04Z

Что за бред я сейчас прочитал?

Это галлюцинации нейросети?

---

## Post 3 by @Gh1 — 2026-09-29T11:21:48Z

Значит читай внимательней, если не понимаешь

Во первых балансировка через xray кривая, во-вторых закрепление ноды или цепочек нод (или балансировщика и ноды) полезно для распределения нагрузки, отслеживания сетевых проблем и проблем конкретного пользователя, а также полезно при ограничения и сильных антифрод системах (gemini например).

Проблема балансировки нагрузку особенно на крупных проектах реальна, и одним балансировщиком на стороне xray или haproxy не справиться

---

## Post 4 by @Gh1 — 2026-09-29T11:27:39Z

Сейчас нет удобной возможности закрепить за людьми ноду, либо куча профилей и хостов, либо через haproxy. Но haproxy не сможет vless + reality закрепить за конкретным юзером, а cgnat сломает балансировку на больших объемах, нет никакого контроля

нет возможности нормально в группы обьеденить (например по странам) ноды, но при этом конкретному пользователю выдавать конкретную ноду из пула. И все что можно придумать либо костыльные надстройки, либо рандомить выдачу, либо балансировать по dns (плохо опять же)