XHTTP или WebSocket для VLESS: чем отличаются и что выбрать

Если в настройках VLESS встречаются варианты:

XHTTP;
WebSocket;
RAW;
gRPC;
HTTPUpgrade,

возникает логичный вопрос:

XHTTP или WebSocket — что лучше выбрать?

Несколько лет WebSocket был одним из самых популярных способов передачи VLESS через:

HTTPS;
CDN;
Nginx;
reverse proxy.

Он понятный, давно поддерживается клиентами и до сих пор способен прекрасно работать.

Но в современных версиях Xray появился XHTTP — значительно более гибкий HTTP-транспорт.

Он умеет использовать:

HTTP/1.1;
HTTP/2;
HTTP/3;
QUIC;
packetized upload;
streaming upload;
streaming download;
multiplexing;
отдельные пути upload и download.

Более того, актуальная документация Project X сейчас прямо рекомендует переходить с WebSocket на XHTTP из-за характерных признаков WebSocket-трафика, в частности использования ALPN = http/1.1.

Но означает ли это, что каждый работающий WebSocket нужно срочно удалять?

Нет.

Разберёмся, чем отличаются оба транспорта и какой вариант разумнее использовать сегодня.

Короткий ответ

Если вы создаёте новую VLESS-конфигурацию и:

используете современный Xray;
клиенты поддерживают XHTTP;
контролируете серверную инфраструктуру;

то в большинстве случаев стоит начинать именно с XHTTP.

Он современнее и значительно гибче.

WebSocket всё ещё может быть разумным вариантом, если:

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

То есть:

новая конфигурация → чаще XHTTP.

старый стабильный WebSocket → мигрировать можно планово, а не аварийно.

Сначала разберёмся: XHTTP и WebSocket — это не VLESS

Это важно.

VLESS — proxy-протокол.

XHTTP и WebSocket — транспортный слой.

Упрощённо:

Приложение
↓
VLESS
↓
XHTTP / WebSocket
↓
TLS / другое transport security
↓
Интернет

Project X разделяет:

proxy protocol;
transport method;
transport security.

В актуальной конфигурации Xray среди transport methods доступны:

RAW;
XHTTP;
mKCP;
gRPC;
WebSocket;
HTTPUpgrade;
Hysteria.

Поэтому правильнее говорить:

VLESS поверх XHTTP

или:

VLESS поверх WebSocket.

Transport клиента и сервера должны совпадать

Если сервер настроен:

VLESS + XHTTP

клиент не может сам решить:

попробую WebSocket.

И наоборот.

Project X прямо указывает, что transport method на двух сторонах соединения должен быть совместим: если одна сторона использует WebSocket, другая тоже должна ожидать WebSocket.

Поэтому менять type=ws на type=xhttp внутри готового VLESS-ключа бессмысленно, если сервер не был перенастроен.

Что такое WebSocket

WebSocket — стандартный протокол для постоянного двунаправленного соединения поверх HTTP.

Первоначально клиент отправляет HTTP-запрос с просьбой переключить соединение:

HTTP
↓
Upgrade: websocket
↓
WebSocket connection

После успешного upgrade соединение становится постоянным двунаправленным каналом.

Xray использует этот канал для передачи proxy-трафика.

Почему WebSocket стал популярным для VLESS

Потому что он хорошо вписывался в обычную web-инфраструктуру.

Например:

Client
↓
HTTPS
↓
CDN
↓
Nginx
↓
Xray WebSocket

WebSocket можно маршрутизировать:

по домену;
по HTTP path;
через reverse proxy.

Project X прямо отмечает, что WebSocket-соединения могут проксироваться через HTTP-серверы вроде Nginx и маршрутизироваться через VLESS fallback path.

Это делало WebSocket очень удобным для серверов, где на одном 443 порту одновременно находились:

сайт;
HTTPS;
Xray.

Типичная WebSocket-схема

Например:

https://example.com/
→ обычный сайт

а:

https://example.com/vless
→ WebSocket
→ Xray

Nginx смотрит на path и передаёт нужный запрос Xray.

Просто и понятно.

Какие параметры обычно есть у WebSocket

В Xray WebSocket transport использует, среди прочего:

path;
host;
custom headers;
heartbeat;
PROXY protocol на inbound.

Актуальная документация также отмечает поддержку X-Forwarded-For, позволяющего reverse proxy передать исходный адрес клиента.

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

path

Например:

/vless

Главная проблема WebSocket сегодня

Project X теперь прямо пишет:

рекомендуется переключиться на XHTTP.

Причиной названы заметные характеристики трафика WebSocket, включая:

ALPN = http/1.1

Это не означает:

каждый WebSocket завтра перестанет работать.

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

Почему HTTP/1.1 здесь вообще имеет значение

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

Например:

http/1.1;
h2;
h3.

Текущая Xray-реализация WebSocket имеет характерное использование HTTP/1.1.

Получается более специфичный сетевой профиль.

XHTTP способен использовать уже несколько HTTP generations и разные режимы передачи.

Что такое XHTTP

XHTTP — современный HTTP-транспорт Xray, выросший из более ранней идеи SplitHTTP.

Первоначальная концепция была довольно интересной:

upload и download не обязаны передаваться одинаковым способом.

Например, upload можно дробить на обычные HTTP POST-запросы, а download держать как длинный streaming response.

Позже транспорт сильно расширился.

В официальном обсуждении Xray разработчики описывают современный XHTTP как систему, которая получила:

split upload/download;
streaming upload;
HTTP/3 через CDN;
header padding;
XMUX;
несколько режимов работы.

Почему XHTTP оказался намного сложнее WebSocket

WebSocket по сути пытается создать один двунаправленный канал.

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

Основные режимы:

packet-up;
stream-up;
stream-one.

А режим:

auto

позволяет Xray выбрать подходящий вариант автоматически.

Разберём их отдельно.

Что такое packet-up

packet-up — наиболее совместимый режим XHTTP.

В нём upload разбивается на отдельные HTTP POST-запросы.

Упрощённо:

Upload:
POST
POST
POST
POST

а download идёт отдельным streaming GET:

GET
↓
длинный поток данных

Именно такая архитектура была основой SplitHTTP.

Зачем дробить upload на POST

Причина — совместимость с HTTP middleware.

Некоторые:

CDN;
reverse proxy;
HTTP middleware

не умеют нормально передавать произвольный streaming upload.

Но обычные HTTP POST-запросы они принимать умеют прекрасно.

Поэтому XHTTP может представить upload как последовательность обычных HTTP requests.

А download остаётся потоковым

Это особенно важно.

Если бы XHTTP ждал полного ответа целиком, скорость загрузки была бы ужасной.

Вместо этого сервер начинает отдавать данные сразу.

То есть:

Client ← continuous HTTP response ← Server

Официальное описание XHTTP как раз подчёркивает идею streaming download, которая позволяет сохранять нормальную скорость скачивания даже при packetized upload.

Почему packet-up считается самым совместимым

Потому что обычные HTTP:

POST

и:

GET

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

В официальном quick-start XHTTP разработчики прямо советуют:

если конкретный CDN или reverse proxy не пропускает другие варианты, использовать packet-up — это наиболее совместимый режим.

Есть ли у packet-up недостаток

Да.

Upload приходится:

разбивать;
оборачивать в HTTP POST;
отправлять несколькими requests.

Теоретически это менее эффективно, чем полностью streaming upload.

Но Xray активно оптимизировал этот режим, и текущая реализация заметно быстрее ранних SplitHTTP-вариантов. Официальное описание отмечает, что после оптимизаций производительность packet-up приблизилась к stream-up, особенно в сценариях HTTP/3 через CDN.

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

Большинство типичных задач имеют асимметричный трафик.

Например:

YouTube

много download, мало upload.

Браузинг

основная масса данных идёт от сайта к клиенту.

Streaming

аналогично.

Поэтому даже более дорогой packetized upload может быть приемлемым.

Что такое stream-up

Следующий режим:

stream-up

Здесь upload тоже становится потоковым.

Упрощённо:

Client
↓ continuous upload stream
Server

а download при этом идёт отдельным запросом.

Получается:

Upload connection   → Server
Download connection ← Server

То есть направления разделены, но оба работают потоково.

Зачем нужен stream-up

Он позволяет избавиться от части overhead packet-up.

Особенно это полезно при:

больших upload;
двустороннем трафике;
более требовательных приложениях.

При этом XHTTP сохраняет отдельный download channel.

Почему stream-up похож на gRPC

Потому что потоковый HTTP/2 upload очень близок по возможностям к тому, что раньше часто делалось через gRPC.

Современный XHTTP даже использует по умолчанию gRPC-like header для stream-up/stream-one.

Но сам XHTTP не требует полноценной gRPC-библиотеки.

Чем stream-up отличается от старого gRPC transport Xray

В официальном описании XHTTP разработчики выделяют несколько преимуществ:

не требуется gRPC library;
отдельный GET download не зависит от ограничений CDN на gRPC download;
есть header padding;
XMUX;
разделение upload/download;
дополнительные XHTTP-настройки.

Поэтому текущая документация Xray также рекомендует переходить с gRPC transport на XHTTP.

Что такое stream-one

stream-one — наиболее похожий на обычное полноценное двунаправленное streaming-соединение режим.

Клиент делает один POST:

POST /path/

и внутри него работают:

streaming upload;
streaming download.

Упрощённо:

Client ⇄ Server

через один HTTP request.

Зачем нужен stream-one

Это более компактная схема.

Нет необходимости:

дробить upload;
создавать отдельный GET для download.

Но совместимость с некоторыми middleware может быть хуже.

stream-one или stream-up

Если infrastructure нормально поддерживает двунаправленный HTTP streaming, stream-one выглядит очень естественно.

Но stream-up может быть более совместим с:

CDN;
reverse proxy.

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

Что делает mode=auto

В большинстве случаев вручную выбирать режим вообще не требуется.

XHTTP имеет:

mode: auto

и современный Xray сам выбирает подходящий вариант в зависимости от конфигурации.

На текущей реализации логика клиента учитывает:

TLS/H2;
используемую transport security;
наличие отдельного download channel;
другие условия.

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

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

если оператор уже подготовил XHTTP-профиль, не нужно вручную переключать packet-up / stream-up / stream-one без причины.

XHTTP поддерживает HTTP/1.1, HTTP/2 и HTTP/3

Это одно из фундаментальных отличий от WebSocket в текущем Xray.

XHTTP способен работать поверх:

В текущей реализации при TLS обычным выбором является HTTP/2, а при специально выбранном ALPN h3 XHTTP может использовать HTTP/3 через QUIC.

Что такое HTTP/2 в этом контексте

HTTP/2 позволяет несколько логических streams использовать внутри одного транспортного соединения.

Это значительно отличается от старой модели HTTP/1.1.

XHTTP использует эту возможность для multiplexing.

А HTTP/3

HTTP/3 работает поверх QUIC/UDP.

У него нет TCP head-of-line blocking на уровне transport connection в той же форме, что у H2/TCP.

Кроме того, QUIC поддерживает connection migration, что потенциально полезно при смене сети.

XHTTP умеет работать через H3 и даже проходить через поддерживающие HTTP/3 CDN.

Значит XHTTP всегда нужно ставить H3?

Нет.

Это распространённая ошибка.

HTTP/3 не является:

режимом «быстрее».

Он зависит от:

UDP;
провайдера;
маршрута;
CDN;
reverse proxy.

Некоторые сети отлично работают с QUIC.

Другие — значительно хуже.

Поэтому H2 остаётся очень нормальным вариантом.

HTTP/3 может работать через CDN

Одна интересная особенность XHTTP заключается в том, что клиент может использовать:

HTTP/3

до CDN.

А CDN затем преобразует соединение к origin, например:

H3 client
↓
CDN
↓
H2 origin
↓
Xray

Такое преобразование HTTP versions является обычным для CDN/reverse proxy, и XHTTP специально спроектирован с учётом подобной архитектуры.

Сервер Xray не обязан сам слушать H3

Например, Xray может принимать H2 за:

Nginx;
Caddy;
CDN.

А клиент до внешнего CDN использует H3.

То есть пользовательская сторона и origin connection не обязаны использовать одну HTTP version.

Что такое XMUX

Ещё одно важное отличие XHTTP.

XHTTP имеет собственный механизм multiplexing:

XMUX.

Он управляет:

количеством proxy-запросов на соединение;
количеством connections;
временем их повторного использования;
количеством reuse;
HTTP keepalive.

Зачем вообще нужен multiplexing

Без mux десять пользовательских соединений могут потребовать десять отдельных transport connections.

С multiplexing:

Connection 1
├── Site A
├── Site B
├── Discord
├── API
└── Other traffic

несколько proxy streams могут использовать одну H2/H3 connection.

Это уменьшает количество новых handshake.

Почему нельзя просто держать одну connection вечно

Потому что слишком долгоживущий канал тоже имеет недостатки.

Например:

CDN может ограничивать duration;
reverse proxy может закрывать старые connections;
одна плохая connection начинает влиять на много streams.

Поэтому XMUX умеет ограничивать reuse и периодически создавать новые connections.

У XMUX есть рабочие default values

Если параметры не задавать вручную, Xray использует подготовленные default values и даже диапазоны случайных значений для части настроек.

Разработчики специально проектировали default XMUX так, чтобы соединения периодически обновлялись вместо бесконечного использования одного H2/H3 connection.

Это ещё одна причина не копировать случайные XMUX-настройки из Telegram-гайда.

Нужно ли включать старый mux.cool вместе с XHTTP

Нет.

Официальное описание XHTTP прямо предупреждает:

при XHTTP не следует включать старый mux.cool.

XHTTP уже имеет собственную multiplexing architecture через XMUX.

Разделение upload и download

Это одна из наиболее необычных функций XHTTP.

Upload и download могут идти по разным подключениям.

Более того, при дополнительной конфигурации они могут использовать даже разные network paths.

Например:

Upload
↓
IPv4 / H2

а:

Download
↓
IPv6 / H3

Современный XHTTP поддерживает это через downloadSettings.

Зачем вообще разделять направления

Это уже advanced-сценарий.

Он позволяет:

использовать разные маршруты;
разные CDN;
разные IP families;
разные transport security paths.

Для обычного пользователя VLESS эта функция вообще не требуется.

Но она показывает, насколько XHTTP архитектурно отличается от WebSocket.

WebSocket значительно проще

У WebSocket модель понятнее:

Client
⇄
WebSocket connection
⇄
Server

Один канал.

XHTTP может быть:

POST + GET

или:

streaming POST + GET

или:

single streaming POST

или даже:

upload через один endpoint
download через другой

Поэтому XHTTP мощнее, но и внутренне сложнее.

Что проще администратору

Если сравнивать минимальную конфигурацию:

WebSocket проще понять.

Например:

path=/vpn

reverse proxy:

/vpn → Xray

и всё.

XHTTP имеет намного больше возможностей.

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

В официальном quick-start даже рекомендуется для обычной XHTTP-конфигурации в большинстве случаев заполнять только path, оставляя остальное по умолчанию.

То есть XHTTP не обязательно сложно настраивать

Именно.

Внутри XHTTP сложный.

Но пользовательский config может быть довольно коротким.

Это как современный браузер:

внутри огромное количество логики,

но пользователь нажимает одну кнопку.

XHTTP и Nginx

XHTTP можно использовать через reverse proxy.

Но конкретный mode влияет на требования к Nginx.

Если стандартная конфигурация не пропускает streaming mode, разработчики XHTTP рекомендуют попробовать:

grpc_pass;
либо более совместимый packet-up.

Это отличается от классического WebSocket, где обычно используется обычная WebSocket proxy-конфигурация.

XHTTP и CDN

Здесь XHTTP особенно интересен.

packet-up специально спроектирован для прохождения через большое количество HTTP middleware.

А H2/H3 позволяют использовать современные CDN transports.

Разработчики XHTTP прямо называют packet-up наиболее совместимым режимом при проблемах с CDN и reverse proxy.

WebSocket через CDN тоже работает

Конечно.

Это одна из основных причин исторической популярности WS.

Многие CDN давно умеют:

WebSocket upgrade;
persistent WS connections.

Поэтому рабочая схема:

VLESS
↓
WSS
↓
CDN

никуда не исчезла.

Тогда зачем XHTTP

Потому что XHTTP больше похож на обычный современный HTTP traffic и предоставляет намного больше вариантов передачи.

Главные преимущества:

H2;
H3;
несколько режимов upload;
streaming download;
header padding;
XMUX;
direction separation;
большая вариативность HTTP traffic.

Актуальная документация Xray поэтому прямо рекомендует XHTTP вместо WebSocket.

Что такое header padding

Размер HTTP headers тоже способен создавать повторяемые характеристики.

XHTTP добавляет случайный padding.

В packet-up client request по умолчанию получает дополнительный Referer с padding, а server response — X-Padding.

Default range в текущем описании составляет:

100–1000 bytes

и выбирается случайным образом для запросов/ответов.

Обычному пользователю менять это обычно не нужно.

WebSocket тоже имеет способы уменьшения характеристик

Нельзя сказать, что WebSocket вообще никак не эволюционировал.

Xray поддерживает WebSocket early data и дополнительные настройки handshake.

Но сама документация всё равно выделяет HTTP/1.1 ALPN как существенный остающийся признак и рекомендует XHTTP.

XHTTP поддерживает TLS

Да.

Xray разрешает сочетание:

XHTTP + TLS

Актуальная таблица совместимости транспорта также допускает XHTTP с REALITY.

WebSocket поддерживает TLS:

WSS

но по текущей таблице Xray WebSocket с REALITY не совместим.

Это ещё одно техническое отличие.

TLS и XHTTP — не одно и то же

XHTTP отвечает:

как переносить данные.

TLS:

как защищать transport connection.

Поэтому:

VLESS + XHTTP + TLS

— три разных уровня.

Не стоит говорить:

XHTTP вместо TLS.

Это разные функции.

WebSocket тоже не является шифрованием

Обычный:

ws://

сам по себе не защищён TLS.

Защищённый WebSocket:

wss://

использует TLS.

То же самое относится к другим HTTP transports.

Что быстрее: XHTTP или WebSocket

Нельзя честно назвать один transport всегда более быстрым.

Результат зависит от:

режима XHTTP;
H2/H3;
CDN;
reverse proxy;
маршрута;
RTT;
сервера.

WebSocket способен выдавать очень высокую скорость.

XHTTP тоже.

Само название transport не отменяет плохой network route.

Может ли XHTTP быть быстрее

Да.

Например, XHTTP может использовать:

H2/H3 multiplexing;
XMUX;
потоковый upload/download;
QUIC.

Это создаёт архитектурные преимущества в некоторых условиях.

Но это не гарантирует:

WebSocket 200 Мбит/с → XHTTP обязательно 500 Мбит/с.

Сравнивать нужно на реальной сети.

Может ли WebSocket оказаться быстрее

Тоже да.

Например:

проверенный прямой WSS;
хороший маршрут;
простой Nginx;
неудачно настроенный CDN для XHTTP.

В такой ситуации старый WS может выиграть конкретный benchmark.

Поэтому миграция только ради Speedtest не является главной причиной перехода.

Главная причина перехода — архитектура, а не Speedtest

XHTTP разрабатывался не просто как:

WebSocket, но быстрее.

Его преимущества прежде всего:

больше HTTP variants;
лучше адаптация к middleware;
H2/H3;
более гибкая multiplexing architecture;
отсутствие специфичного WebSocket upgrade profile;
разделение потоков.

XHTTP и задержка

Multiplexing способен уменьшить необходимость создавать новую transport connection для каждого proxy request.

Это может положительно влиять на latency коротких соединений.

В официальном описании XHTTP разработчики отмечают, что default multiplexing может давать низкую задержку, хотя синтетическая многопоточная скорость зависит от настроек XMUX.

То есть:

benchmark и пользовательская отзывчивость — не всегда одно и то же.

Почему Speedtest иногда выглядит странно на XHTTP

Speedtest создаёт много параллельных соединений.

XMUX может объединять их внутри ограниченного числа transport connections.

Поэтому итог синтетического multi-thread test зависит от:

maxConcurrency

и других параметров.

Разработчики XHTTP даже отдельно рекомендуют определённую настройку XMUX для многопоточного speed test.

Для обычного пользователя это скорее повод:

не оптимизировать VPN только под цифру Speedtest.

Что важнее Speedtest

Проверьте:

YouTube;
браузинг;
Discord;
файлы;
стабильность нескольких часов.

Если XHTTP показывает условные:

300 Мбит/с

вместо:

350 Мбит/с WebSocket,

но быстрее открывает соединения и меньше рвётся, первый вариант может быть практичнее.

А для игр?

Здесь transport — только одна часть пути.

Игры больше чувствительны к:

ping;
jitter;
packet loss.

Если XHTTP и WebSocket идут через один и тот же сервер, различия могут быть небольшими.

Но H3/QUIC или другой routing могут изменить результат.

Проверяйте непосредственно в игре.

Для YouTube

Смотрите прежде всего на:

throughput;
стабильность.

Оба transport способны нормально обслуживать video streaming.

Если один конкретный сервер тормозит, причина может быть вообще не в XHTTP/WebSocket.

Для Discord

Особенно voice:

нужен стабильный real-time traffic;
важны UDP и routing.

Выбор между XHTTP и WS сам по себе не определяет всю работу Discord.

VLESS/Xray может транспортировать пользовательский UDP другими механизмами поверх proxy connection.

XHTTP или WebSocket при плохой сети

Интереснее становится при:

нестабильном mobile ISP;
сложном middlebox;
CDN.

XHTTP имеет больше режимов адаптации.

Если streaming режим не проходит, можно использовать packet-up.

WebSocket такой вариативности не предоставляет.

packet-up — хороший fallback

Именно поэтому packet-up особенно полезен.

Если сеть или reverse proxy плохо относится к:

long streaming request;
определённой H2-схеме,

XHTTP может разбить upload на обычные requests.

Это один из сильнейших аргументов в пользу XHTTP как универсального HTTP transport.

А WebSocket всё равно очень совместим

Да.

И эта практическая совместимость накоплена годами.

Большое количество:

CDN;
Nginx examples;
proxy services;
старых клиентов

умеет WebSocket.

Поэтому старые deployment иногда проще оставить как есть до плановой миграции.

Поддержка клиента — ключевой вопрос

XHTTP появился заметно позже WebSocket.

Старые Xray-core или сторонние клиенты могут его не понимать.

Поэтому перед миграцией необходимо убедиться, что:

server core;
client core

достаточно новые.

Сам Xray поддерживает XHTTP в современных версиях, а транспорт входит в текущую официальную transport configuration.

Почему это особенно важно для коммерческого VPN

Оператор может обновить сервер за пять минут.

Но у пользователей могут остаться:

старые Android-клиенты;
старые Windows clients;
сторонние приложения.

Если внезапно заменить всем:

WebSocket → XHTTP

часть клиентской базы может просто перестать подключаться.

Поэтому миграцию лучше делать постепенно.

Хорошая миграция

Например:

старый WS endpoint
+
новый XHTTP endpoint

Какое-то время оба существуют параллельно.

Новые подписки получают XHTTP.

Старые пользователи обновляют клиент.

После миграционного периода WebSocket можно убрать.

Не меняйте transport пользователю вручную

Если сервис выдаёт подписку:

transport должен управляться оператором.

Пользователь не должен заходить в HAPP и случайно менять:

ws
↓
xhttp

в надежде повысить скорость.

Если сервер всё ещё ожидает WebSocket, соединение просто перестанет работать.

Что означает type=ws в VLESS-ссылке

В VLESS URI можно встретить параметр, указывающий transport:

type=ws

Это означает WebSocket transport.

Также часто присутствуют:

path;
host;
security-related параметры.

Не публикуйте полный VLESS URI публично — он содержит credential.

А type=xhttp

Современная конфигурация может использовать:

type=xhttp

и собственные XHTTP parameters.

Но опять же:

это должно соответствовать server config.

Просто заменить слово ws на xhttp недостаточно.

Почему XHTTP иногда не подключается после миграции

Первое, что стоит проверить:

Client Xray обновлён?
Server Xray обновлён?
Transport одинаковый?
path совпадает?
TLS/SNI корректны?
Reverse proxy знает про новый transport?

Не начинайте с замены UUID.

WebSocket работает, XHTTP нет

Это не означает:

XHTTP хуже.

Возможно:

reverse proxy настроен только под WebSocket;
client core старый;
XHTTP mode не проходит через CDN;
path обработан неправильно.

Нужно сравнить инфраструктуру.

XHTTP работает напрямую, но не через CDN

Тогда проблема почти наверняка находится в CDN path.

Попробуйте:

проверить поддержку H2/H3;
использовать packet-up;
проверить gRPC support;
reverse proxy rules.

Quick-start XHTTP прямо рекомендует packet-up при проблемах прохождения через CDN/middleware.

stream-one не работает через CDN

Попробуйте:

stream-up

или:

packet-up

stream-one требует более полного bidirectional streaming поведения.

Не каждый middleware обращается с ним одинаково.

stream-up не проходит через Nginx

Актуальный XHTTP quick-start рекомендует при соответствующей проблеме попробовать grpc_pass вместо обычного proxy_pass.

Но это уже server-side настройка.

Обычному пользователю VLESS ничего менять не нужно.

H3 не подключается

Проверьте:

UDP;
firewall;
CDN;
поддержку H3;
ALPN.

HTTP/3 требует QUIC.

Если UDP path плохой, H2 может оказаться стабильнее.

Нужно ли открывать UDP 443

Если Xray принимает H3 напрямую — да, QUIC требует UDP.

Но если клиент использует H3 до CDN, а CDN подключается к origin по H2, origin Xray может вообще не принимать H3 напрямую.

Архитектура зависит от deployment.

WebSocket path и XHTTP path — одно и то же?

Семантически оба транспорта могут использовать HTTP path.

Но они являются разными transport implementations.

Нельзя считать:

раз path /vpn одинаковый, WebSocket и XHTTP взаимозаменяемы.

Reverse proxy также должен понимать соответствующую схему.

Что выбрать без CDN

Если есть:

прямой сервер;
современный Xray;
современные клиенты;

XHTTP всё равно остаётся хорошим выбором.

CDN — не обязательное условие его использования.

XHTTP может работать напрямую с сервером.

А WebSocket без CDN

Тоже может.

Но тогда теряется одна из основных исторических причин использовать WebSocket вместо более простого transport.

Если нет CDN/reverse proxy requirements, стоит сравнить также другие современные варианты Xray.

XHTTP — не просто «transport для CDN»

Это важно.

Его возможности:

H2/H3;
XMUX;
stream modes;
split directions

полезны и без CDN.

CDN — лишь один из сценариев.

Что выбрать для нового сервера в 2026 году

Если всё начинается с нуля:

современный Xray;
современный client;
нет legacy users;

я бы выбирал XHTTP.

Это соответствует и текущему направлению самого Project X: официальная документация WebSocket рекомендует переходить на XHTTP.

Что выбрать для уже работающего WebSocket

Если сейчас:

пользователи подключаются;
скорость хорошая;
CDN работает;
сервер стабилен;

нет необходимости ночью срочно переносить всё на XHTTP.

Можно:

добавить XHTTP;
протестировать;
проверить клиентов;
постепенно мигрировать.

Это гораздо безопаснее.

Когда WebSocket всё ещё разумен

Например:

legacy client fleet;
старое оборудование;
стабильный CDN setup;
нет времени тестировать новую инфраструктуру.

WebSocket остаётся официально поддерживаемым transport Xray.

Project X рекомендует XHTTP, но WebSocket из core не исчез.

Когда XHTTP явно интереснее

Если нужны:

новые deployments;
HTTP/2;
HTTP/3;
QUIC;
XMUX;
разные upload modes;
высокая совместимость с HTTP middleware через packet-up;
split upload/download.

Здесь WebSocket просто не предлагает сопоставимого набора возможностей.

Таблица сравнения XHTTP и WebSocket

Характеристика	XHTTP	WebSocket
Поддержка VLESS	Да	Да
HTTP/1.1	Да	Да
HTTP/2	Да	Нет в текущем Xray WS transport
HTTP/3	Да	Нет
QUIC	Через H3	Нет
CDN	Да	Да
Nginx / reverse proxy	Да	Да
Packetized upload	Да	Нет
Streaming upload	Да	Да, как WS stream
Streaming download	Да	Да
XMUX	Да	Нет
Split upload/download	Да	Нет
Header padding	Да	Ограниченнее
Простота	Сложнее внутри	Проще
Legacy compatibility	Ниже	Выше
Current Xray recommendation	Предпочтительный	Рекомендуется миграция
TLS	Да	Да
REALITY compatibility	Да	Нет по текущей таблице Xray

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

WebSocket.

Концептуально он проще.

Что лучше по возможностям

XHTTP.

Здесь разница уже большая.

Что лучше для старых клиентов

Чаще:

WebSocket.

Потому что он существует в Xray намного дольше.

Что лучше для современной инфраструктуры

Чаще:

XHTTP.

Особенно если server/client stack контролируется одним оператором.

Что лучше через сложный CDN

Начать стоит с XHTTP.

Если streaming modes не проходят:

packet-up.

Это его главное преимущество — возможность менять схему upload, не отказываясь от самого transport.

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

Проверять.

Ни один transport не выигрывает во всех сетях.

Для реального пользователя важнее:

стабильность;
время открытия сайтов;
скорость длинных загрузок;
отсутствие reconnect.

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

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

Не нужно самостоятельно выбирать transport внутри HAPP.

Клиент должен получить правильные параметры от оператора.

Если конкретный профиль не работает, обновите:

приложение;
подписку;

и сообщите оператору, а не меняйте transport вручную.

Почему подписка здесь особенно удобна

Оператор может постепенно заменить:

старый WebSocket

на:

новый XHTTP

внутри subscription.

Пользователь делает Refresh и получает новый серверный профиль.

Не нужно рассылать инструкции:

откройте настройки, поменяйте transport, path, host, ALPN…

Можно даже держать обе конфигурации

Например:

🇳🇱 Netherlands · XHTTP
🇳🇱 Netherlands · WS

на период тестирования.

Пользователь может сравнить их в одной сети.

Но постоянно держать дубли каждого сервера обычно нет необходимости.

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

Используйте:

один сервер;
один ISP;
одно устройство;
одинаковое время.

И сравните:

время подключения;
загрузку сайтов;
download;
upload;
Discord;
длинное соединение;
несколько часов стабильности.

Так результат будет значительно полезнее случайного Speedtest.

Что не стоит сравнивать

Плохой тест:

WebSocket → сервер Netherlands A
XHTTP → сервер France B

и вывод:

XHTTP быстрее.

Вы сравнили:

transport;
сервер;
страну;
route

одновременно.

Такой тест ничего не говорит именно о transport.

Не существует «лучшего transport для всех»

У разных сетей разные:

фильтры;
CDN routes;
peering;
UDP quality.

Поэтому оператору полезно иметь несколько технических вариантов.

Но пользователю лучше давать уже протестированный профиль, а не двадцать переключателей.

Нужно ли обычному пользователю знать packet-up

Не обязательно.

Если VLESS:

подключается;
быстро работает;
стабилен,

можно вообще не знать, какой XHTTP mode используется внутри.

Эти параметры нужны прежде всего:

разработчикам;
администраторам;
операторам VPN.

Но понимать разницу полезно

Потому что при диагностике становится понятно:

XHTTP — это не одна фиксированная схема.

Если один CDN не пропускает stream-one, это ещё не означает:

XHTTP не работает.

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

stream-up;
packet-up.

Почему статья «XHTTP против WebSocket» немного несправедлива

Потому что WebSocket — один transport mechanism.

А современный XHTTP уже больше похож на:

семейство HTTP transmission strategies под одним transport.

Поэтому сравнение не совсем симметричное.

Что говорит сам Project X

Текущая официальная страница WebSocket прямо содержит рекомендацию перейти на XHTTP, чтобы избежать заметных характеристик вроде WebSocket ALPN = http/1.1.

А основной документ XHTTP описывает его как transport с:

packet-up;
stream-up;
stream-one;
H2/H3;
XMUX;
direction splitting.

Поэтому направление развития Xray достаточно очевидно.

Если WebSocket работает — он не стал «неправильным»

Это тоже важно.

Рекомендация мигрировать не означает:

WS сломан.

Он остаётся:

официально поддерживаемым;
работоспособным;
совместимым с VLESS;
совместимым с TLS.

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

Что НЕ нужно делать

Не стоит:

вручную менять type=ws на xhttp;
копировать случайные XMUX values;
принудительно ставить H3 ради скорости;
включать одновременно XHTTP и старый mux.cool;
менять UUID из-за transport error;
менять TLS/SNI без причины.

Каждый параметр отвечает за свой уровень.

Если XHTTP не работает — короткая диагностика

Один сервер XHTTP не работает

Попробуйте другой сервер.

Все XHTTP не работают, WS работает

Проверьте версию клиента.

Direct XHTTP работает, CDN нет

Проверяйте CDN/reverse proxy/mode.

stream-one не работает

Попробуйте stream-up или packet-up на серверной стороне.

H3 не работает

Проверьте UDP/H3 и временно H2.

После ручной смены WS → XHTTP всё сломалось

Верните исходную subscription-конфигурацию.

Если WebSocket перестал работать

Проверьте:

сервер;
CDN;
path;
reverse proxy;
TLS.

Не нужно автоматически считать:

WebSocket заблокировали, срочно XHTTP.

Сначала исключите обычную неисправность.

Хорошая стратегия оператора VLESS

Для нового сервиса в 2026 году я бы строил основной HTTP transport вокруг XHTTP.

При наличии legacy users:

XHTTP → основной
WebSocket → временный compatibility fallback

с последующей миграцией.

Так можно использовать современные возможности Xray и не ломать старых клиентов одним обновлением.

Если нужен готовый VLESS

Пользователю готового сервиса обычно не нужно самостоятельно решать:

packet-up или stream-up?

Серверная конфигурация должна быть уже протестирована оператором.

VLESS.ART использует готовые профили и подписки для HAPP и совместимых клиентов: пользователь получает серверы через subscription и не собирает транспортную конфигурацию вручную.

Посмотреть тарифы VLESS.ART

Если профиль меняется на стороне сервиса, достаточно обновить подписку.

Что выбрать: финальная таблица

Ситуация	Рекомендация
Новый VLESS-сервер	XHTTP
Современные Xray clients	XHTTP
Нужен HTTP/2	XHTTP
Нужен HTTP/3 / QUIC	XHTTP
Нужен CDN	XHTTP, при проблемах packet-up
Нужна максимальная legacy compatibility	WebSocket
Старый WS стабильно работает	Можно оставить и мигрировать планово
Старый клиент без XHTTP	WebSocket
Нужен split upload/download	XHTTP
Нужен XMUX	XHTTP
Нужна наиболее простая исторически понятная схема	WebSocket
Создаётся новая инфраструктура на годы вперёд	XHTTP

Итог

Если выбирать XHTTP или WebSocket для VLESS сегодня, направление развития Xray довольно однозначно.

WebSocket остаётся рабочим и официально поддерживаемым transport.

Он:

простой;
хорошо известен;
поддерживается большим числом клиентов;
удобно проксируется через Nginx и CDN.

Но текущая документация Project X уже прямо рекомендует перейти на XHTTP из-за заметных характеристик WebSocket-трафика, включая ALPN = http/1.1.

XHTTP значительно современнее.

Он поддерживает:

HTTP/1.1;
HTTP/2;
HTTP/3;
QUIC;
packet-up;
stream-up;
stream-one;
XMUX;
header padding;
раздельные upload/download connections.

При этом XHTTP не требует, чтобы обычный пользователь вручную настраивал всю эту сложность.

У transport есть готовые defaults, а официальный quick-start для стандартной конфигурации в большинстве случаев советует задать path и позволить Xray выбрать остальные параметры автоматически.

Поэтому практическая рекомендация выглядит так:

новый сервер и современные клиенты → XHTTP.

старый стабильный WebSocket → не ломать срочно, а мигрировать постепенно.

сложный CDN → XHTTP packet-up как наиболее совместимый fallback.

нужны H2/H3, XMUX или разделение направлений → однозначно XHTTP.

И главное — не менять transport только на клиенте.

WebSocket и XHTTP являются частью согласованной server/client configuration. Если сервер ждёт WebSocket, клиент с XHTTP не подключится, и наоборот.

Для пользователя готовой VLESS-подписки правильный подход значительно проще:

обновить клиент → обновить subscription → использовать transport, который выдал оператор.

А администратору новой Xray-инфраструктуры WebSocket сегодня уже стоит рассматривать скорее как проверенный legacy-вариант, тогда как XHTTP — как основной современный HTTP transport.