XHTTP в Xray: режимы работы, XMUX и стабильность VPN в нестабильных сетях

Что такое XHTTP и три режима его работы

XHTTP — это транспорт в Xray, выросший из SplitHTTP. Его смысл не в замене одного модного слова другим: идея в том, чтобы VPN-трафик выглядел как обычная работа с CDN или API — загрузка файлов частями, стриминговые ответы сервера, API-запросы микросервисов.

XHTTP реализует три режима: packet-up создаёт серию последовательных POST-запросов для загрузки (upload) и один долгий GET для скачивания (download) — такой профиль похож на загрузку файла в облако. stream-up использует один непрерывный POST в HTTP/2 и маскируется под gRPC-поток с заголовком Content-Type: application/grpc. stream-one сводит всё к единственному запросу и хорошо сочетается с REALITY, потому что сокращает количество рукопожатий.

В отличие от старых транспортов, XHTTP отвязан от версии HTTP. Один и тот же режим может работать поверх H1, H2 или H3, что даёт гибкость в зависимости от того, что пропускает конкретный маршрут. Но гибкость не означает, что один режим подходит всем устройствам и сетям.

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

WebSocket в типичных Xray-сценариях часто заметен по ALPN http/1.1. Актуальная документация Xray рекомендует переходить с WebSocket на XHTTP именно из-за этого видимого признака. gRPC опирается на HTTP/2 и остаётся рабочим вариантом, но у него есть ограничения: нет поддержки Host-хедера, нет fallback на другие сервисы, структура потока менее гибкая.

TCP-RAW прост и эффективен на чистом маршруте, но наследует проблемы одного долгого соединения: потери пакетов, head-of-line blocking, заметный паттерн при длинных сессиях. XHTTP снижает часть этих рисков через множество HTTP-обменов вместо одного постоянного туннеля, но платит за это большей зависимостью от клиента, режима и поведения сети.

• WebSocket: ALPN http/1.1 — характерная сигнатура, Xray рекомендует заменить на XHTTP.
• gRPC: HTTP/2 с мультиплексированием, но нет Host/fallback, заметен для DPI.
• TCP/RAW: прост, эффективен на чистом пути, но чувствителен к потерям и паттернам.
• XHTTP: нативные HTTP-запросы поверх H1/H2/H3, три режима, без долгих туннелей.

Почему HTTP/3 и QUIC важны для нестабильных сетей

HTTP/2 работает поверх TCP и мультиплексирует несколько потоков внутри одного соединения. Проблема в том, что TCP-level head-of-line blocking сохраняется: потеря одного пакета может притормозить все остальные потоки. HTTP/3 переносит HTTP на QUIC, а QUIC работает поверх UDP с независимыми потоками — потеря на одном не затрагивает остальные.

Ещё важнее QUIC connection migration: при переключении с Wi-Fi на LTE соединение переживает смену сети без разрыва и повторного рукопожатия. Для VPN на мобильных устройствах это принципиальное преимущество. Но QUIC не панацея: в части сетей UDP блокируется или получает более короткие idle timeouts, поэтому fallback на TCP по-прежнему критичен.

Где XHTTP реально помогает, а где нет

XHTTP особенно полезен в сетях, где длинные однотипные сессии ведут себя нестабильно: мобильная сеть с потерями, публичный Wi-Fi, маршруты через HTTP-прокси или CDN. Режим packet-up дробит отправку данных на HTTP-запросы, поэтому поток меньше похож на один длинный туннель и лучше вписывается в поведение обычной веб-инфраструктуры.

XHTTP помогает не во всех случаях. На стабильном проводном соединении разница с TCP-RAW может быть минимальной. Если клиент устарел или не поддерживает нужный режим, результат будет хуже. Если сервер перегружен, DNS работает неправильно или маршрут проблемный на уровне IP, смена транспорта сама по себе может ничего не исправить.

На iPhone и iPad XHTTP требует отдельной проверки. В практическом смысле это не такой же простой сценарий, как один TCP/REALITY-профиль с привычным поведением при потере сегментов: результат зависит от режима XHTTP, версии ядра, памяти приложения, idle timeout и того, как iOS-клиент удерживает сетевую сессию. Поэтому XHTTP не стоит включать всем iOS-пользователям только потому, что он новее.

• Помогает: мобильные сети с потерями, публичный Wi-Fi, смена Wi-Fi ↔ LTE.
• Помогает: маршруты через HTTP-прокси, CDN-цепочки, DPI с сигнатурным анализом.
• Не помогает: перегруженный сервер, блокировка UDP (для H3), устаревший клиент.
• Не подходит без проверки: iOS-клиенты, которые нестабильно держат XHTTP-сессию.
• Требует проверки: поддержка режима конкретным клиентом и версией ядра Xray.

XMUX и рандомизация: почему XHTTP сложнее классифицировать

Традиционные прокси держат одно долгое соединение и гоняют в нём данные часами — это создаёт статический паттерн, который проще заметить. XMUX в XHTTP работает иначе: он рандомизирует число одновременных потоков, лимит запросов до сброса соединения и время жизни сессии. Сегодня соединение живёт 1900 секунд с 16 потоками, завтра — 2800 секунд с 28. Пространство признаков становится шире, и классификация требует больше контекста.

Дополнительная рандомизация — padding в заголовке Referer каждого запроса. В режиме packet-up каждый POST может нести 100–1000 байт дополнительных данных. Один и тот же 1 КБ полезной нагрузки каждый раз выглядит в сети по-разному: то 1234 байта, то 1589. Это снижает надёжность классификации по гистограммам размеров пакетов.

Ещё одна возможность XHTTP — разделение потоков upload и download по разным IP или путям. Download может идти через один CDN, upload — через другой. Для анализатора это выглядит как два независимых потока от разных источников, и связать их в одну сессию становится заметно сложнее.

• XMUX рандомизирует число потоков, лимит запросов и время жизни сессии в каждой сессии.
• Padding 100–1000 байт в Referer меняет видимый размер HTTP-запросов.
• Интервал между POST-запросами тоже рандомизируется и усложняет временной анализ.
• Download-Upload Separation: два разных IP/пути сложнее связать в одну сессию.

Что это значит для пользователя BadVPN

Пользователю не нужно выбирать транспорт каждый день вручную. Хорошая подписка скрывает большую часть сложности: если профиль меняется на стороне сервиса, клиент получает актуальные параметры через обновление подписки.

BadVPN не включает XHTTP просто потому, что это новый транспорт. Мы подбираем актуальные конфигурации под ограничения устройства, клиента, сети и сервера: где-то лучше XHTTP, где-то стабильнее TCP/REALITY, где-то нужен отдельный маршрут или другой клиент. Для iOS это особенно важно, потому что один и тот же профиль может вести себя нормально на Android и ПК, но нестабильно на iPhone.

Если соединение часто рвётся, полезнее собрать симптомы, чем искать «самый мощный протокол»: устройство, клиент, тип сети, оператор, время проблемы, работает ли интернет без VPN, что происходит в другой сети. По этим данным проще понять, нужен другой сервер, другой транспортный профиль или диагностика устройства.