3x-ui: VLESS-gRPC-Reality (скрытый резерв)

gRPC — транспорт поверх HTTP/2 с мультиплексом: несколько логических потоков живут внутри одного соединения. Для DPI это обычный HTTP/2-трафик, каких в интернете большинство.

Зачем он нужен, если уже есть VLESS-TCP-Reality: это второй, непохожий профиль подключения на той же ноде. Когда основной Reality начинают резать (или он попадает под точечную блокировку по паттерну), клиент переключается на gRPC и продолжает работать — без смены сервера и без переустановки у клиентов.

📖 Незнакомые слова? Все термины простыми словами есть в Словаре терминов.

Панель ещё не стоит? См. «3x-ui с нуля» и «первый inbound VLESS-Reality».

Шаг 1: транспорт gRPC

Inbounds → Add Inbound, на Basics протокол vless и свободный порт (например 2087). Затем вкладка Stream → Transmission: gRPC.

Вкладка Stream с транспортом gRPC: Service Name, Authority, Multi Mode — **Stream → Transmission: gRPC**. Полей всего три, и по-настоящему важно одно — `Service Name`.

Все поля транспорта:

Поле	Что ставить	Зачем
Service Name	своё имя, например `grpcapi`	Аналог пути в HTTP. Должно совпадать у сервера и клиента
Authority	пусто	Заголовок `:authority`. Нужен, только если впереди фронт, который его проверяет
Multi Mode	выкл	Мультиплекс нескольких потоков. Включайте, только если упираетесь в скорость

Service Name — это ваш «пароль на входе». Xray отвечает только на запросы с этим именем, остальное отбрасывается. Не берите grpc, vpn, proxy: имя должно выглядеть как обычный внутренний сервис — api, sync, push, telemetry.

Шаг 2: Reality сверху

Вкладка Security → Reality. Дальше всё так же, как в базовой статье: ключи, Short IDs и SpiderX панель генерирует сама, руками задаются только Target и SNI (домен-донор).

⚠️ Донор берите другой, не тот, что на основном Reality-inbound. Смысл резерва в том, чтобы два профиля не выглядели одинаково: разные порты, разные SNI, разный транспорт. Иначе то, что положит основной вход, положит и резерв.

Итог должен выглядеть так — inbound с бейджами vless · GRPC · Reality:

Список inbound: gRPC-Reality рядом с остальными протоколами — gRPC-inbound на порту 2087 живёт рядом с основным Reality и остальными протоколами на той же ноде.

Как использовать резерв правильно

Резерв работает, только если у клиента есть оба профиля.

Заведите клиента и привяжите и к основному Reality-inbound, и к gRPC (в 3x-ui 3.6 клиент — отдельная сущность, привязок может быть несколько).
Выдайте ссылку-подписку: меню inbound (три точки) → Export All URLs — Subscription. В приложении клиента появятся оба профиля.
В клиентском приложении (Hiddify, v2rayNG) включается автовыбор — при обрыве основного он сам уходит на gRPC.

Так переключение переживается без вашего участия и без сообщений «у меня перестало работать».

Когда gRPC лучше основного Reality

Мобильные операторы с агрессивным DPI. HTTP/2-мультиплекс выглядит обыденнее длинного TCP-соединения.
Нестабильная связь. Мультиплекс переживает потери мягче, чем один поток.
Точечная блокировка паттерна. Резать HTTP/2 целиком слишком дорого — сломается пол-интернета.

Грабли

Service Name не совпал у сервера и клиента — соединение не поднимется вообще. В 3x-ui ссылку формирует панель, поэтому не правьте её вручную.
Тот же SNI, что на основном Reality. Резерв перестаёт быть резервом.
Multi Mode включён без нужды. Даёт лишний паттерн трафика и выигрыш заметен редко.
gRPC за CDN. Возможен, но капризен: многие фронты не пропускают HTTP/2 в нужном виде. Для CDN берите «XHTTP».

Что дальше

Транспорт под CDN: «3x-ui: VLESS-XHTTP».
Резерв на UDP, когда TCP душат: «3x-ui: Hysteria2».
Честный TLS на своём домене: «3x-ui: VLESS-TCP-TLS».