VLESS TCP XHTTP gRPC — это не три разных версии протокола, а разные способы передачи VLESS-трафика между клиентом и сервером.

Сам VLESS отвечает за соединение клиента с сервером Xray и идентификацию пользователя. TCP/RAW, XHTTP и gRPC определяют, как именно поток данных будет перенесён по сети.

От выбранного транспорта могут зависеть:

• • скорость;
  • задержка;
  • совместимость с провайдером;
  • возможность работы через CDN;
  • устойчивость к фильтрации;
  • нагрузка на сервер;
  • требования к клиенту;
  • сложность настройки.

При этом нельзя сказать, что один транспорт всегда быстрее или лучше остальных. Простой прямой TCP/RAW обычно даёт минимум накладных расходов. XHTTP предоставляет больше возможностей для работы через HTTP-инфраструктуру. gRPC остаётся рабочим HTTP/2-транспортом, но для новых конфигураций разработчики Xray рекомендуют переходить на XHTTP.

VLESS и транспорт — не одно и то же

Условно соединение можно представить так:

приложение → HAPP → VLESS → транспорт → сервер Xray → интернет

В этой схеме:

• • HAPP является клиентом;
  • VLESS отвечает за взаимодействие клиента и сервера;
  • TCP/RAW, XHTTP или gRPC переносят поток по сети;
  • TLS или другой защитный механизм отвечает за безопасность транспортного соединения.

Xray разделяет способ передачи и безопасность транспорта. Например, VLESS может использовать RAW, XHTTP или gRPC, а поверх выбранного транспорта отдельно применяется совместимый механизм защиты. Обе стороны соединения должны иметь согласованные параметры: если сервер ожидает XHTTP, а клиент пытается подключиться через gRPC, соединение не установится.

Обычному пользователю не нужно вручную комбинировать эти уровни. Готовый VLESS-ключ уже содержит необходимые параметры.

Почему TCP теперь называется RAW

В старых инструкциях, клиентах и панелях часто встречается название:

TCP

В актуальной документации Xray этот транспорт называется:

RAW

Разработчики переименовали прежний TCP transport в RAW, поскольку название TCP было неоднозначным. Новый термин подчёркивает, что Xray напрямую отправляет данные, обёрнутые протоколом VLESS, без дополнительного XHTTP-, gRPC- или WebSocket-слоя.

Поэтому на практике можно встретить:

• • VLESS TCP;
  • VLESS RAW;
  • type=tcp;
  • network=raw.

В пользовательских статьях выражение «VLESS через TCP» ещё долго будет оставаться привычным поисковым запросом. Но технически правильнее теперь говорить VLESS через RAW, уточняя, что раньше этот транспорт назывался TCP.

Что такое VLESS через TCP/RAW

RAW — наиболее прямой вариант передачи.

После установления нижележащего соединения Xray отправляет через него данные VLESS без дополнительной упаковки в HTTP-запросы или gRPC.

Упрощённая схема выглядит так:

HAPP → защищённое прямое соединение → Xray

Основные преимущества RAW:

• • минимальное количество дополнительных слоёв;
  • небольшие накладные расходы;
  • хорошая скорость;
  • низкая задержка;
  • сравнительно простая серверная конфигурация;
  • меньше компонентов, способных сломаться;
  • хорошая производительность при прямом доступе к серверу.

Основные ограничения:

• • обычный HTTP-CDN не сможет просто обработать такое соединение как веб-трафик;
  • доступность зависит от IP, домена, порта и маршрута до сервера;
  • при проблемах с прямым соединением меньше вариантов HTTP-маскировки и промежуточной доставки;
  • сервер должен быть доступен пользователю напрямую либо через совместимую сетевую схему.

RAW часто является хорошим выбором, когда прямое подключение работает стабильно и нет необходимости использовать CDN или HTTP-прокси между клиентом и сервером.

RAW действительно самый быстрый?

При одинаковом сервере, маршруте и защите RAW обычно имеет меньше дополнительных операций, чем HTTP-транспорты. Поэтому он способен показать хорошую скорость и небольшую задержку.

Но это не означает, что RAW всегда будет быстрее в реальной сети.

Например:

• • прямой маршрут до RAW-сервера может быть плохим;
  • IP сервера может ограничиваться провайдером;
  • выбранный порт может работать нестабильно;
  • XHTTP через другой маршрут или CDN может оказаться доступнее;
  • сервер с RAW может быть перегружен;
  • XHTTP-профиль может находиться в более удачном дата-центре.

Протокол и транспорт — только часть соединения. Хороший маршрут XHTTP способен работать лучше плохого прямого RAW-маршрута.

Что такое VLESS через XHTTP

XHTTP — современный HTTP-транспорт Xray. Он появился как развитие SplitHTTP и объединяет несколько способов передачи данных через HTTP-инфраструктуру.

XHTTP может использовать разные HTTP-версии в зависимости от конфигурации:

• • HTTP/1.1;
  • HTTP/2;
  • HTTP/3.

Он также имеет несколько режимов передачи:

• • packet-up;
  • stream-up;
  • stream-one;
  • автоматический выбор режима.

Пользователю готового сервиса не нужно самостоятельно выбирать эти параметры. Нормальная конфигурация уже должна содержаться в ключе или подписке.

Главная идея XHTTP заключается в том, чтобы переносить VLESS-трафик в форме HTTP-соединений, которые могут проходить через поддерживаемые reverse proxy, CDN и другие промежуточные HTTP-системы.

Режим packet-up

В режиме packet-up восходящий трафик от клиента разделяется на отдельные HTTP-запросы, а нисходящий поток передаётся непрерывно.

Такой подход ориентирован на совместимость с промежуточными HTTP-системами, которые не умеют нормально передавать непрерывный восходящий поток.

Преимущества:

• • высокая совместимость с разными HTTP-посредниками;
  • возможность работы через инфраструктуру, которая буферизует запросы;
  • хорошая скорость загрузки данных к пользователю;
  • поддержка CDN-сценариев.

Возможный недостаток — дополнительные HTTP-запросы и несколько меньшая эффективность восходящего трафика. Для обычного просмотра сайтов и видео это не всегда критично, поскольку пользователи обычно скачивают значительно больше данных, чем отправляют.

Режим stream-up

В stream-up и восходящий, и нисходящий трафик могут передаваться потоково, но через отдельные направления.

Это снижает потери эффективности при отправке данных и делает режим подходящим для:

• • загрузки файлов;
  • облачной синхронизации;
  • видеозвонков;
  • активного исходящего трафика;
  • более симметричного использования канала.

Разработчики XHTTP указывают, что stream-up не требует отдельной gRPC-библиотеки, обладает дополнительными возможностями XHTTP и не подвергает нисходящий поток некоторым ограничениям, характерным для gRPC у отдельных CDN.

Режим stream-one

stream-one переносит двусторонний поток внутри одного HTTP-запроса.

Он ближе по логике к традиционному потоковому HTTP-транспорту и может использоваться в конфигурациях, где промежуточная инфраструктура поддерживает такой режим.

Для обычного пользователя разница между stream-up и stream-one не должна становиться предметом ручной настройки. Если сервис выдаёт готовый XHTTP-ключ, режим подбирается его администратором под сервер, reverse proxy и CDN.

Преимущества XHTTP

Основные преимущества XHTTP:

• • работа через различные HTTP-сценарии;
  • поддержка HTTP/1.1, HTTP/2 и HTTP/3;
  • возможность использования CDN и reverse proxy;
  • разные режимы восходящего потока;
  • отдельная передача upload и download;
  • встроенная система мультиплексирования XMUX;
  • возможность адаптации под особенности сети;
  • более современная замена части старых gRPC- и WebSocket-конфигураций.

XHTTP может быть особенно полезен, когда прямое соединение с сервером работает нестабильно или требуется использовать промежуточную HTTP-инфраструктуру.

Недостатки XHTTP

XHTTP сложнее RAW.

Для его работы могут иметь значение:

• • HTTP-версия;
  • path;
  • host;
  • SNI;
  • режим XHTTP;
  • настройки CDN;
  • reverse proxy;
  • поддержка потоковой передачи;
  • ограничения WAF;
  • версия Xray;
  • версия клиентского приложения.

Чем больше компонентов участвует в соединении, тем больше потенциальных точек отказа.

Например, XHTTP-профиль может не работать, если:

• • клиент слишком старый;
  • CDN блокирует используемые запросы;
  • reverse proxy неправильно передаёт поток;
  • path на клиенте и сервере не совпадает;
  • HTTP/2 или HTTP/3 настроены неправильно;
  • сервер и клиент используют несовместимые параметры.

Это не делает XHTTP плохим транспортом. Просто он требует более аккуратной серверной настройки.

Что такое VLESS через gRPC

gRPC-транспорт Xray основан на HTTP/2. Он позволяет переносить VLESS-соединение через инфраструктуру, поддерживающую gRPC и HTTP/2.

Схема может выглядеть так:

HAPP → HTTP/2 gRPC → Nginx или Caddy → Xray

gRPC имеет встроенное мультиплексирование: несколько логических потоков могут использовать одно HTTP/2-соединение.

Поэтому при gRPC не рекомендуется дополнительно включать старый mux.cool. Это может создать лишнюю вложенную мультиплексацию и ухудшить работу.

Преимущества gRPC

gRPC долгое время был популярным вариантом благодаря следующим особенностям:

• • использование HTTP/2;
  • встроенное мультиплексирование;
  • поддержка Nginx и Caddy;
  • возможность работы через совместимые reverse proxy;
  • понятная серверная инфраструктура;
  • большое количество существующих конфигураций и инструкций;
  • поддержка многими Xray-клиентами.

Если gRPC-профиль уже работает стабильно, нет необходимости срочно отказываться от него только из-за появления XHTTP.

Недостатки gRPC

У gRPC есть несколько важных ограничений.

Для нормальной работы необходимо:

• • правильно настроить HTTP/2;
  • указать корректный домен или ServerName;
  • согласовать serviceName;
  • правильно настроить grpc_pass или аналогичную передачу в reverse proxy;
  • учитывать ограничения конкретного CDN;
  • не включать лишний mux.

Официальная документация Xray также указывает, что gRPC:

• • не поддерживает обычное указание Host тем же способом, что некоторые другие HTTP-транспорты;
  • не поддерживает fallback к другим сервисам;
  • может быть подвержен активному зондированию;
  • для новых конфигураций рекомендуется заменять на XHTTP.

Почему XHTTP заменяет gRPC

XHTTP вобрал в себя многие полезные свойства HTTP-транспортов и добавил дополнительные возможности:

• • разные режимы upload;
  • потоковый download;
  • разделение направлений;
  • собственное мультиплексирование XMUX;
  • padding заголовков;
  • работа через H2 и H3;
  • более гибкие сценарии с CDN;
  • отсутствие необходимости в отдельной gRPC-библиотеке для режима stream-up.

В официальной документации gRPC уже размещена рекомендация перейти на XHTTP. Это не означает, что gRPC удалён или немедленно устарел. Скорее XHTTP теперь является предпочтительным направлением развития Xray для новых HTTP-конфигураций.

Сравнение TCP/RAW, XHTTP и gRPC

Что лучше по скорости

В идеальных условиях RAW обычно имеет преимущество по простоте и накладным расходам.

Но реальная скорость зависит от:

• • маршрута;
  • сервера;
  • дата-центра;
  • загрузки канала;
  • провайдера;
  • транспорта;
  • TUN;
  • клиента;
  • времени суток.

XHTTP способен показать отличную скорость, особенно при удачной настройке H2/H3 и reverse proxy. Но встроенное мультиплексирование может влиять на синтетические многопоточные тесты.

Разработчики XHTTP отдельно отмечают, что его стандартные настройки XMUX ориентированы не только на максимальную цифру Speedtest, но и на стабильное переиспользование и периодическую смену соединений.

Поэтому нельзя сравнивать RAW и XHTTP только по одному многопоточному тесту.

Что лучше по пингу

RAW часто показывает небольшую дополнительную задержку, поскольку использует более прямую схему.

XHTTP и gRPC добавляют HTTP-уровень и могут использовать мультиплексирование. Однако оно способно уменьшить количество повторных установок соединения для множества небольших запросов.

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

Важнее проверить:

• • ping до нужного сервиса;
  • jitter;
  • потери;
  • задержку под нагрузкой;
  • реальную работу приложений.

Что лучше для YouTube

Для YouTube важнее стабильная скорость загрузки, чем минимальный ping.

RAW подойдёт, если прямой маршрут быстрый и стабильный.

XHTTP может оказаться лучше, если:

• • прямой IP работает нестабильно;
  • используется качественный CDN-маршрут;
  • сервер имеет хороший канал до Google;
  • выбран подходящий HTTP-режим.

gRPC тоже способен нормально воспроизводить видео, но при использовании CDN нужно учитывать возможные ограничения gRPC-трафика.

Выбирать стоит по реальному воспроизведению, заполнению буфера и перемотке, а не по названию транспорта.

Что лучше для Telegram и Discord

Для текстовых сообщений подойдёт любой исправно настроенный транспорт.

Для файлов, звонков и Discord важны:

• • стабильность;
  • UDP на уровне приложений;
  • низкий jitter;
  • отсутствие потерь;
  • корректный TUN;
  • серверный outbound.

Не следует считать, что gRPC передаёт только «gRPC-трафик приложений» или что XHTTP работает только с сайтами. Внутри VLESS могут переноситься соединения разных приложений.

Но если нижележащий транспорт работает поверх TCP/HTTP/2, потери пакетов на сети способны вызывать ожидание повторной передачи. На нестабильном мобильном интернете это может быть заметнее в голосовой связи.

Что лучше для игр

Для игр RAW часто является логичным первым вариантом благодаря простоте и низким накладным расходам.

Но транспорт не исправит:

• • плохой маршрут;
  • далёкий игровой сервер;
  • слабый Wi-Fi;
  • перегруженный домашний канал;
  • потери у провайдера.

XHTTP или gRPC могут дать лучший результат, если через них меняется маршрут или используется более доступная инфраструктура.

Проверять нужно непосредственно внутри игры. Минимальный ping до самого VLESS-сервера не гарантирует минимальную задержку до игрового узла.

Можно ли использовать CDN

RAW обычно предполагает прямой доступ к Xray или работу через транспортный reverse proxy, который не обрабатывает соединение как обычный HTTP-запрос. Обычный веб-CDN не сможет просто принять RAW-VLESS как стандартный сайт.

XHTTP разработан именно с учётом HTTP-посредников и разных CDN-сценариев.

gRPC также может передаваться через инфраструктуру с поддержкой HTTP/2 и gRPC, но не каждый CDN или тариф поддерживает такую схему.

Важно понимать:

• • поддержка HTTPS ещё не означает поддержку gRPC;
  • поддержка HTTP/2 ещё не гарантирует корректную потоковую передачу;
  • CDN может ограничивать длительность соединений;
  • WAF может блокировать нестандартные запросы;
  • некоторые провайдеры требуют отдельного включения gRPC;
  • XHTTP тоже не гарантированно работает через любой CDN.

Серверную конфигурацию нужно проверять на конкретной инфраструктуре.

Почему нельзя изменить transport вручную в ключе

Пользователь может увидеть в VLESS-ссылке параметр вроде:

type=tcp

или:

type=grpc

или:

type=xhttp

Но простой замены одного слова на другое недостаточно.

На сервере должен существовать соответствующий inbound с правильными:

• • transport;
  • портом;
  • path;
  • serviceName;
  • TLS-параметрами;
  • SNI;
  • reverse proxy;
  • CDN;
  • правилами firewall.

Если заменить grpc на xhttp только в клиентском ключе, сервер продолжит ожидать gRPC и соединение не установится.

Transport меняется на сервере и клиенте одновременно.

Что делать пользователю HAPP

Для обычного пользователя алгоритм простой:

1. 1. Получить готовый ключ или подписку.
   2. Добавить её в HAPP.
   3. Не редактировать transport вручную.
   4. Выбрать профиль.
   5. Включить подключение.
   6. Проверить сайты и приложения.
   7. При наличии нескольких вариантов сравнить их в одинаковой сети.

Если XHTTP-профиль не импортируется или не подключается, обновите HAPP. XHTTP активно развивается, поэтому старый клиент может не поддерживать новые параметры профиля.

HAPP позволяет импортировать готовые VLESS-конфигурации, а его документация содержит отдельные функции, связанные с XHTTP-профилями.

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

Для честного теста желательно использовать:

• • один сервер;
  • один дата-центр;
  • один портовой диапазон;
  • одинаковую защиту;
  • одно устройство;
  • одну сеть;
  • одну версию клиента;
  • одинаковую маршрутизацию.

Затем для каждого профиля проверить:

• • скорость загрузки;
  • скорость отправки;
  • ping;
  • jitter;
  • потери;
  • YouTube;
  • Telegram;
  • Discord;
  • нужные игры;
  • работу утром и вечером.

Если RAW находится в Нидерландах, XHTTP в Турции, а gRPC в Германии, сравнение покажет в первую очередь разницу маршрутов и серверов, а не транспортов.

Когда выбрать TCP/RAW

TCP/RAW подходит, если:

• • прямой сервер доступен;
  • соединение работает стабильно;
  • нужен простой профиль;
  • важны небольшие накладные расходы;
  • не требуется CDN;
  • нужен хороший ping;
  • сервер и маршрут не блокируются;
  • важна простая диагностика.

Для многих пользователей это отличный основной вариант.

Когда выбрать XHTTP

XHTTP стоит выбирать, если:

• • нужна современная HTTP-конфигурация;
  • используется CDN или reverse proxy;
  • прямое соединение работает нестабильно;
  • требуется гибкость H1/H2/H3;
  • нужны разные режимы передачи;
  • провайдер по-разному обрабатывает прямой и HTTP-трафик;
  • сервис уже настроил и протестировал XHTTP;
  • нужен современный вариант вместо gRPC или WebSocket.

При наличии качественно настроенного сервера XHTTP может быть хорошим основным транспортом.

Когда выбрать gRPC

gRPC имеет смысл оставить, если:

• • профиль уже работает стабильно;
  • серверная инфраструктура построена вокруг gRPC;
  • reverse proxy корректно настроен;
  • CDN нормально поддерживает gRPC;
  • используемые клиенты совместимы;
  • миграция не даёт практического преимущества.

Для новой серверной конфигурации разумнее сначала рассмотреть XHTTP, поскольку именно его теперь рекомендует документация Xray.

Нужно ли переходить с рабочего gRPC на XHTTP

Обычному пользователю самостоятельно переходить не нужно.

Если сервис выдаёт рабочий gRPC-ключ и все приложения работают, можно продолжать им пользоваться.

Миграция оправдана, если:

• • gRPC регулярно обрывается;
  • CDN ограничивает поток;
  • возникают проблемы совместимости;
  • сервис официально предлагает новый XHTTP-профиль;
  • XHTTP показывает лучший результат;
  • администратор обновляет серверную схему.

Не нужно вручную переделывать ключ или требовать XHTTP только потому, что он новее. Качество конкретной реализации важнее названия.

Короткий выбор

Упрощённо можно ориентироваться так:

• • нужна простота и прямое подключение — TCP/RAW;
  • нужен современный HTTP-транспорт или CDN — XHTTP;
  • есть рабочая существующая инфраструктура — gRPC можно оставить;
  • создаётся новая HTTP-конфигурация — лучше рассмотреть XHTTP;
  • пользователь получил готовый ключ — использовать рекомендованный сервисом transport.

Итог

VLESS через TCP, XHTTP или gRPC использует один протокол, но разные способы переноса данных между клиентом и сервером.

TCP, который в актуальной документации Xray называется RAW, является самым прямым вариантом. Он отличается простой схемой, небольшими накладными расходами и хорошей производительностью, но обычно требует прямой доступности сервера.

XHTTP — современный и гибкий HTTP-транспорт. Он поддерживает разные режимы, HTTP/1.1, HTTP/2 и HTTP/3, reverse proxy, CDN-сценарии и собственное мультиплексирование XMUX. Для новых HTTP-конфигураций именно XHTTP становится предпочтительным вариантом.

gRPC работает поверх HTTP/2 и остаётся пригодным для существующих настроек. Но он имеет больше ограничений, а документация Xray рекомендует для новых конфигураций переходить на XHTTP.

Обычному пользователю не нужно выбирать transport вручную или редактировать VLESS-ссылку. Надёжнее получить готовый профиль, импортировать его в HAPP и сравнить доступные серверы по реальной скорости, стабильности и работе нужных приложений.