Описание
gRPC-transport — это альтернативный способ доставки VLESS или VMess вместо классического WebSocket. Появился в xray-core и v2ray-core примерно в 2021, после того как DPI-системы научились детектировать long-lived WS-сессии. Идея: HTTP/2 multiplexing позволяет нескольким логическим streams делить одно TLS-соединение, что выглядит для DPI как обычные gRPC-вызовы — те самые, через которые ходят Google API, Bloomberg Terminal и большая часть современной enterprise-инфраструктуры. Когда gRPC лучше WS: меньше overhead на handshake, multiplexing закрывает head-of-line blocking, HTTP/2 priority frames дают приоритеты на streams. Когда хуже: без CDN-прослойки длинные gRPC-streams к одному backend'у — необычный pattern (обычно gRPC живёт в фрейме «сервер-сервер» внутри дата-центра), и ТСПУ его может пометить. В связке с Cloudflare proxied subdomain — gRPC становится практически невидимым: CF принимает HTTPS, проксирует gRPC, ТСПУ видит только CDN-IP с легитимным TLS.
В России — частично
Работает с правильной настройкой через CDN (Cloudflare proxied). Без CDN — ТСПУ детектирует длинные gRPC streams к obvious VPN endpoints.
Где используется
Self-host через Cloudflare proxied subdomain — даёт CDN-IP + gRPC obfuscation одновременно.
Поддерживаемые реализации
- xray-core
- v2ray-core
- sing-box
плюсы
- + Низкий latency за счёт HTTP/2 multiplexing
- + Маскируется под обычный gRPC-трафик (Google APIs)
- + Идёт через 443 порт — нечего блочить без блокировки HTTPS
- + Хорошо ложится через CDN (Cloudflare, Fastly)
минусы
- − Требует TLS сертификата (бесплатно через Let's Encrypt, но один больше шаг)
- − Без CDN детектируется на streams >5 мин (длинные gRPC-сессии необычны)
- − Меньше встроенной anti-fingerprinting обвязки чем Reality