gRPC-транспорт: что это

Автор: Екатерина Лебедева, редактор раздела knowledge base
Проверил:: Артём Волков
Проверено:: 28 сентября 2026
Опубликовано:: 27 сентября 2026, обновлено 28 сентября 2026
Версия гайда:: 1.0

Коротко

gRPC-транспорт передаёт трафик VLESS, VMess или Trojan внутри потоков HTTP/2 — того же протокола, что использует одноимённый фреймворк Google. В Happ он включается параметром type=grpc и именем сервиса serviceName в ссылке сервера.

gRPC — транспорт Xray-core, построенный на HTTP/2: вместо отдельного соединения он открывает поток внутри HTTP/2-канала и опознаётся по имени сервиса serviceName, которое играет роль пути. Такой трафик может пройти через любой прокси или балансировщик, который умеет пересылать HTTP/2, включая Nginx с соответствующей настройкой. У транспорта нет запасного «сайта» на случай ошибки: если serviceName или другие параметры не совпали с настройкой сервера, соединение просто не устанавливается. Happ поддерживает gRPC для VLESS, VMess и Trojan — эти протоколы указаны с ним в документации.

gRPC — транспорт Xray-core, который передаёт трафик VLESS, VMess или Trojan внутри потока HTTP/2, опознавая соединение по имени сервиса — параметру serviceName. Название совпадает с одноимённым open-source фреймворком Google, на протоколе которого построен транспорт.

Суть транспорта

gRPC — открытый протокол удалённого вызова процедур, который разработала и опубликовала компания Google. Он построен поверх HTTP/2 и обычно применяется для связи между серверами. Xray-core использует ту же технологию как транспорт: трафик VLESS, VMess или Trojan идёт внутри потока gRPC, а значит — внутри HTTP/2-соединения.

Каждое соединение gRPC в Xray-core опознаётся по параметру serviceName — строке, которая играет ту же роль, что путь у веб-сервера. Клиент открывает поток с этим именем, а сервер связывает его с настроенным протоколом. Если имя не совпадает с тем, что ждёт сервер, соединение не устанавливается.

Поскольку HTTP/2 изначально спроектирован для нескольких параллельных запросов в одном соединении, у gRPC-транспорта уже есть собственная многопотоковость. Документация Xray отдельно отмечает, что добавлять сверху ещё и Mux не нужно: два механизма мультиплексирования работают избыточно и не дают выигрыша.

Параметры и особенности

Кроме serviceName, документация Xray описывает у gRPC-транспорта настройки, которые обычно задаёт администратор сервера, а не пользователь Happ:

Параметр	За что отвечает
`serviceName`	Имя сервиса — аналог пути, связывает соединение с нужным протоколом на сервере
`multiMode`	Экспериментальный режим передачи, который в части сценариев ускоряет соединение
`idle_timeout`	Через сколько секунд бездействия сервер проверяет соединение
`permit_without_stream`	Разрешает проверки соединения даже без активного потока данных

У транспорта нет запасного варианта ответа на случай ошибки — так называемого fallback, который есть, например, у некоторых схем на TLS с обычным веб-сайтом. Если параметры клиента и сервера разошлись, gRPC просто не даёт соединения, а не показывает постороннюю страницу.

Как это выглядит в Happ

Документация Happ перечисляет gRPC как транспорт для трёх протоколов: VLESS, VMess и Trojan. Для каждого из них в ссылке достаточно двух параметров транспорта:

Ссылка

vless://00000000-0000-0000-0000-000000000000@example.com:443?type=grpc&serviceName=grpc&security=tls&sni=example.com#Example

Happ передаёт type=grpc и serviceName в Xray-core без изменений, поэтому от пользователя не требуется отдельных настроек — только точная ссылка или подписка от администратора сервера. Если сервис на сервере называется иначе, чем указано в ссылке, Happ не сможет подключиться, а при проверке пинга через прокси покажет «Тайм-аут».

Для Trojan через gRPC чаще всего дополнительно нужен корректный сертификат TLS: транспорт не заменяет проверку сервера, а лишь меняет способ доставки уже защищённых данных. При ошибках на этом этапе Happ показывает ошибку TLS-рукопожатия.

Чем gRPC отличается от WebSocket и XHTTP

Все три транспорта решают одну задачу — передать трафик Xray-core через инфраструктуру, рассчитанную на веб-протоколы, — но опираются на разные механизмы.

Транспорт	Протокол-основа	Параметр пути
gRPC	HTTP/2	`serviceName`
WebSocket	HTTP/1.1 с заголовком Upgrade	`path`
XHTTP	HTTP/1.1, HTTP/2 или HTTP/3	`path`

WebSocket поддерживает практически любой веб-сервер и прокси без дополнительной настройки. gRPC требует, чтобы весь путь трафика — сервер, обратный прокси, балансировщик — правильно работал с HTTP/2, иначе соединение обрывается на полпути. XHTTP занимает промежуточное положение: он не привязан к одной версии HTTP и подбирает поведение под конкретную схему защиты канала.

Выбор транспорта не затрагивает сам протокол: UUID или пароль клиента, адрес назначения и проверка сервера остаются такими же, как без gRPC. Подробности о протоколах, которые используют этот транспорт в Happ, — на страницах VLESS и Trojan.

Главное

gRPC-транспорт передаёт данные внутри HTTP/2-потока и опознаёт соединение по параметру serviceName, который работает как путь у WebSocket.
В Happ параметр type=grpc и serviceName доступны для VLESS, VMess и Trojan — документация перечисляет gRPC у всех трёх протоколов.
HTTP/2 сам по себе умеет вести несколько потоков в одном соединении, поэтому документация Xray не рекомендует добавлять поверх gRPC ещё и Mux.
У транспорта нет запасного ответа на случай ошибки: неверный serviceName приводит к разрыву соединения, а не к показу постороннего сайта.
gRPC проходит только через прокси и балансировщики, которые умеют пересылать HTTP/2, — это условие обычно настраивает администратор сервера.

Частые вопросы

Что означает параметр serviceName в ссылке с gRPC?

serviceName — имя сервиса внутри HTTP/2-соединения, которое сервер использует, чтобы принять именно этот поток трафика. Оно работает похоже на path у WebSocket: клиент и сервер должны использовать одинаковое значение, иначе Xray-core на сервере не свяжет входящее соединение с нужным протоколом. Значение задаёт администратор сервера, а пользователь просто переносит его из выданной ссылки или подписки.

Чем gRPC отличается от WebSocket по сути передачи?

WebSocket — отдельная технология поверх одного HTTP-запроса с заголовком Upgrade, рассчитанная на одно постоянное соединение. gRPC работает внутри HTTP/2 и использует его встроенную многопотоковость: несколько логических потоков могут идти в одном HTTP/2-соединении. Для клиента разница видна только в параметрах ссылки — type=grpc и serviceName вместо type=ws, path и host.

Нужно ли включать Mux вместе с gRPC?

Обычно нет. HTTP/2, на котором построен gRPC, уже умеет вести несколько потоков в одном соединении, и документация Xray отдельно отмечает, что совмещать gRPC с Mux избыточно: получаются два механизма мультиплексирования одновременно. Если провайдер не указал иное, оставляйте Mux выключенным для серверов на gRPC.

Почему gRPC иногда не работает через прокси провайдера интернета или офиса?

Транспорту нужен прокси или балансировщик, который целиком поддерживает протокол HTTP/2 и умеет пересылать его потоки. Часть корпоративных прокси и старых сетевых устройств работает только с HTTP/1.1 и обрывает такие соединения. В этом случае помогает транспорт WebSocket или XHTTP: они рассчитаны на более широкий круг промежуточных серверов.

Поддерживает ли Happ gRPC для всех протоколов?

Документация Happ указывает gRPC как транспорт для VLESS, VMess и Trojan. Для Shadowsocks, SOCKS5 и Hysteria2 такой транспорт не описан: Shadowsocks и SOCKS5 работают поверх обычного TCP и UDP, а Hysteria2 использует свой протокол на основе QUIC.

Что произойдёт, если в serviceName опечатка?

Сервер не сможет сопоставить входящий HTTP/2-поток с нужным протоколом и не ответит на запрос. Happ в этом случае покажет тайм-аут при проверке пинга или не сможет установить соединение при подключении. Сверьте serviceName в ссылке посимвольно с тем, что указал администратор сервера, — значение чувствительно к регистру.

Упомянутые темы

Разделы по теме

Источники

Документация Xray: транспорт gRPC — обращение 28 сентября 2026
Документация Happ: примеры ссылок и параметры — обращение 28 сентября 2026