Клиент подключается к одной ноде, а она сама выбирает выходную из пула по загрузке. Балансировка целиком на сервере — клиент о выходных нодах не знает.
← Все руководства · Нода XHTTP SelfSteal · Хост с автовыбором
vless://; адреса выходных нод знает только мост.
Обе схемы дают автовыбор, но платят за него разным. Выбирать стоит осознанно — они не взаимозаменяемы.
| Балансировщик у клиента | Нода-мост | |
|---|---|---|
| Где решение | в приложении пользователя | на сервере |
| Что нужно от клиента | поддержка Xray JSON | ничего — обычный vless:// |
| Кто знает адреса выходов | все пользователи | только мост |
| Смена состава выходов | переиздание подписок | правка конфига моста |
| Задержка | клиент → выход | клиент → мост → выход |
| Трафик моста | — | считается дважды: вход и выход |
| Единая точка отказа | нет | есть — упал мост, легли все |
Мост берут, когда важнее простота на стороне клиента и скрытность выходных нод. Клиентский балансировщик — когда важнее задержка и отказоустойчивость.
Их можно совместить. Сделать два-три моста и раздать их клиентским балансировщиком — тогда пропадает единая точка отказа, а адреса выходов по-прежнему знают только мосты. Цена — обе задержки складываются.
Вставь ссылки выходных нод, по одной в строке. На выходе — куски, которые нужно домешать в твой существующий конфиг моста. В Remnawave такого конвертера нет, поэтому он здесь.
Вставь ссылки выше и нажми «Собрать».
Куда что класть. Результат — объект с четырьмя ключами верхнего уровня, и каждый мешается в свой раздел:
outbounds — добавить к существующему массиву. Твои direct и block остаются на месте, конвертер их не дублируетburstObservatory — положить в корень конфига. Если он уже есть, допиши префикс в его subjectSelectorrouting.balancers — добавить к массиву балансировщиковrouting.rules — правило с balancerTag ставится последним, после всех блокирующих| Элемент | Требование |
|---|---|
| Нода-мост | Обычная нода Remnawave с рабочим инбаундом. К ней подключаются пользователи. Канал должен держать двойной объём трафика |
| Выходные ноды | Любые серверы, к которым можно подключиться по vless:// — ноды Remnawave, отдельные Xray, 3x-ui. Менять их настройки не нужно |
| Доступ для моста | Учётные данные на каждой выходной ноде. В Remnawave это отдельный пользователь, см. фазу 02 |
| Сеть | Мост должен доставать выходные ноды напрямую. Если они за фильтрами — проверь до начала |
Он терминирует соединение пользователя и открывает новое. Внутри моста трафик существует в расшифрованном виде — ровно как на любой обычной ноде, но теперь через одну машину идёт всё.
Держи мост под тем же контролем, что и остальные ноды, и не арендуй его там, где не арендовал бы выходную.
Мост подключается к выходным нодам как обычный клиент, значит ему нужны свои учётные данные. Отдельные — не переиспользуй чужие.
BRIDGEvless:// ссылки — по одной на каждую выходную нодуЧерез него пойдёт трафик всех твоих пользователей разом. Квота в 100 ГБ на пользователе BRIDGE означает, что цепочка встанет, когда суммарно через неё пройдёт 100 ГБ.
То же с датой окончания: истечёт — мост отключится от всех выходов одновременно, и выглядеть это будет как полный отказ сети.
Просто возьми vless:// из её панели — 3x-ui, Marzban, ручной Xray. Конвертеру всё равно, откуда ссылка.
На руках столько vless:// ссылок, сколько выходных нод. Каждую стоит проверить обычным клиентом — подключиться и убедиться, что интернет есть. Сломанную ссылку проще найти сейчас, чем потом внутри цепочки.
Конфиг моста остаётся твой — инбаунд, ключи, блокирующие правила не трогаем. Добавляем только то, чего в нём нет.
Вставь ссылки в конвертер выше, нажми «Собрать» и разложи результат по разделам существующего конфига. Что куда — написано под конвертером.
Роутинг Xray идёт сверху вниз до первого совпадения. Если в твоём конфиге уже есть правило-перехватчик — скажем, {"network": "tcp,udp", "outboundTag": "direct"} — оно сработает раньше, и балансировщик не получит ничего.
Старый перехватчик нужно заменить новым, а не дописать после. Блокирующие правила — приватные сети, bittorrent — остаются выше, они должны срабатывать до балансировщика.
| В ссылке | В аутбаунде |
|---|---|
uuid@host:port | settings.vnext[0] — адрес, порт, id пользователя |
type | streamSettings.network |
security | reality или tls |
sni · fp · pbk · sid · spx | realitySettings: serverName, fingerprint, publicKey, shortId, spiderX |
path · host · mode | xhttpSettings или wsSettings |
flow | users[0].flow — только для raw/tcp |
#подпись | игнорируется, тег берётся из префикса |
Правило-перехватчик отправляет в балансировщик всё подряд. Если в конфиге есть dns, запросы на резолв адресов выходных нод попадут туда же — замкнутый круг: чтобы отрезолвить выход, нужен выход.
На мосту этот блок лучше убрать совсем: пусть резолвит системным резолвером, мимо роутинга. Конвертер dns не генерирует намеренно.
Можно убрать резолв совсем. Замени в готовых аутбаундах address на IP выходной ноды, оставив serverName доменом. Reality проверяет SNI, а не адрес подключения, так что соединение не сломается — зато мост перестанет зависеть от DNS вообще.
docker logs --tail 50 remnanode ss -tlnp | grep :443
Ошибок разбора конфига нет, на 443 слушает rw-core.
Подключись клиентом к мосту и проверь внешний IP:
curl -s https://api.ipify.org
Должен вернуться IP выходной ноды, а не моста. Если пришёл IP моста — балансировщик до пула не достучался и трафик ушёл в fallbackTag.
Выключи ту выходную ноду, чей IP увидел, подожди до минуты и повтори curl. IP должен смениться на другой выход.
Повтори для каждой ноды по очереди — так проверяются все аутбаунды сразу, а не только тот, что выбрался первым.
Если при падении выходной ноды интернет пропадает на полминуты и только потом восстанавливается — дело в двух параметрах.
expected задаёт размер набора кандидатов, из которого балансировщик выбирает случайно. Поставишь его равным числу нод — кандидатами станут все, и выбор фактически станет случайным.
Последствие при отказе: пока наблюдатель не пометил упавшую ноду, часть новых соединений продолжает уходить на неё. При трёх нодах это примерно треть. Страницы грузятся наполовину, и выглядит это как «интернета нет», хотя две живые ноды работают.
Балансировщик будет держаться одной лучшей ноды и переключаться только когда она деградирует. Отказ тогда даёт чистое переключение, а не полосу частичных сбоев.
Поднимать выше единицы имеет смысл, только если нужно размазать нагрузку по выходам намеренно. За это платишь тем, что часть трафика всегда идёт не через лучшую ноду.
interval × sampling определяет, как быстро мёртвая нода выпадет из пула.
| interval | sampling | Одна потеря | Реакция на отказ |
|---|---|---|---|
| 30s | 6 | 17% | до 30 с — одной пробы хватает, но ждать её долго |
| 10s | 10 | 10% | около 20 с, и одиночная потеря пакета ноду не выбивает |
| 5s | 12 | 8% | около 10 с, но проб втрое больше |
Конвертер ставит interval: "10s", sampling: 10, timeout: "3s". При tolerance: 0.15 одна проваленная проба даёт 10% и прощается, две подряд дают 20% и нода выбывает — то есть примерно за 20 секунд, и от случайного джиттера это защищено.
Балансировщик решает, куда направить новое соединение. TCP-сессии, установленные к упавшей ноде до отказа, будут висеть, пока приложение не сдастся по своему таймауту — это не чинится настройками прокси.
Поэтому после переключения страница может висеть, а её перезагрузка уже работает. Судить о скорости восстановления стоит по новым запросам, а не по зависшей вкладке.
| Что | Насколько |
|---|---|
| Задержка | Складываются два плеча. Мост рядом с пользователями и выходы подальше — разумно; наоборот — нет |
| Трафик моста | Удваивается. 1 ТБ пользовательского трафика — 2 ТБ на счётчике моста |
| Пропускная способность | Потолок цепочки — канал моста, делённый на два |
| Отказоустойчивость | Мост — единая точка отказа. Выходы резервируются балансировщиком, мост ничем |
| Шифрование | Двойное: клиент→мост и мост→выход. Процессору моста это заметно на гигабитных скоростях |
Отсюда практическое правило: мост стоит брать с запасом по каналу и процессору, даже если выходные ноды слабые. Он работает за двоих буквально.
| Симптом | Что смотреть |
|---|---|
curl отдаёт IP моста | Пул пуст, сработал fallbackTag. Смотри логи моста при loglevel: warning и проверь ссылки поодиночке обычным клиентом |
| Нет интернета вообще | fallbackTag: "block" при пустом пуле. Временно поставь direct — если интернет появился с IP моста, причина в аутбаундах |
| При падении ноды интернет пропадает на полминуты | expected больше единицы: часть соединений уходит на мёртвую ноду, пока наблюдатель её не отбраковал. См. «Скорость переключения» |
| Работает через раз | То же самое: часть аутбаундов битая, а выбор случайный по всему набору кандидатов |
| Все выходы разом отвалились | Кончился трафик или срок у пользователя BRIDGE. Проверь его карточку в панели |
| Мост не стартует | Ошибка в JSON. docker logs remnanode покажет строку |
| Скорость вдвое ниже ожидаемой | Это не поломка, а свойство схемы. Смотри «Цена решения» |
| Конвертер ругается на ссылку | Ссылка обрезана при копировании либо это не vless://. Транспорты кроме raw, xhttp, ws и grpc конвертер не разбирает |
Конвертер разбирает ссылку по схеме параметров VLESS и собирает аутбаунд по структуре Xray-core. Поддерживаются транспорты raw/tcp, xhttp, ws и grpc с security none, tls и reality. Состояние чек-листа хранится только в этом браузере.