Транспорт XHTTP / SplitHTTP

Эволюция проксирования через CDN. Разделение двунаправленного потока на стандартизированные GET и POST запросы для идеальной мимикрии под REST API.

Год релиза

2024 (Xray 1.8.8+)

Разработчик

Project X / RPRX

Совместимость с CDN

100% (Cloudflare, Fastly)

Базовые протоколы

HTTP/1.1, H2, H3 (QUIC)

1. Зачем понадобился новый транспорт?

Исторически для скрытия IP-адреса сервера за CDN (Content Delivery Network) вроде Cloudflare использовался транспорт WebSocket (WS). Однако WebSocket имеет характерные недостатки: он требует специфического хэндшейка (заголовок Upgrade: websocket), который легко детектируется DPI, и обладает заметным оверхедом при установке соединения.

Позже стандартом стал gRPC (от Google), работающий поверх HTTP/2. Он значительно быстрее, но имеет один фатальный минус для цензурируемых сетей: gRPC открывает долгоживущие двунаправленные потоки. DPI-системы ТСПУ, WAF (Web Application Firewalls) и балансировщики нагрузки часто сбрасывают или замораживают такие соединения по таймауту, если в них долго не передаются данные, что приводит к обрывам.

Разработчики Project X представили XHTTP (и его ядро SplitHTTP) — транспорт, который выглядит и ведет себя как самая обычная загрузка веб-страницы или передача файлов через API.

2. Архитектура: Магия Split-режима

Главная инновация SplitHTTP заключается в физическом разделении VPN-туннеля (который по своей природе является двунаправленным) на два независимых, полностью легитимных HTTP-запроса:

Upstream (От клиента к серверу): Данные отправляются короткими, фрагментированными POST или PUT запросами. Для CDN и DPI это выглядит так, будто пользователь загружает фотографии или отправляет данные формы на сайт.
Downstream (От сервера к клиенту): Данные принимаются через длительный GET запрос (техника Long-polling) или Server-Sent Events. Это выглядит как потоковая загрузка видео или получение обновлений ленты.

Оба потока мультиплексируются поверх современного HTTP/2 или HTTP/3 (QUIC).

3. Схема маршрутизации через Cloudflare

[ Ваш Клиент (sing-box / v2rayN) ] | | 1. POST /upload-data (Запрос с зашифрованными исходящими пакетами) | 2. GET /stream (Ожидание входящих данных) v [ Cloudflare CDN / Reverse Proxy ] — видит стандартный веб-трафик (HTTP/2) | | Проксирует REST API запросы на ваш скрытый сервер v [ Ваш Xray Server (VLESS + XHTTP) ] | +--> Расшифровывает Payload --> [ Свободный Интернет ]

4. Идеальная совместимость с WAF и CDN

Почему XHTTP настолько устойчив? Большинство систем глубокого анализа пакетов (DPI) и файрволов (WAF) не могут позволить себе блокировать стандартные методы GET и POST, так как это сломает 99% интернета (перестанут работать корзины в магазинах, авторизация, загрузка файлов).

0-RTT и восстановление сессий

При переключении между мобильной сетью и Wi-Fi, транспорт XHTTP использует механизм 0-RTT, встроенный в HTTP/3 и TLS 1.3. Приложение не тратит время на повторное согласование ключей — новые HTTP-запросы мгновенно улетают на сервер с прежним токеном сессии, обеспечивая бесшовный интернет.

5. Вердикт: Место XHTTP в современной архитектуре

XHTTP — это ультимативный выбор, если ваш IP-адрес заблокирован (или подвернулся жесткому троттлингу) и вы вынуждены прогонять трафик через CDN (например, бесплатный Cloudflare Workers или CDN-прокси).

Ключевые преимущества

Безупречная маскировка под обычные REST API запросы.
Идеально проходит через Cloudflare, Fastly и любые балансировщики нагрузки.
Не страдает от обрывов долгоживущих TCP-соединений, как gRPC.
Нативная поддержка HTTP/2 и HTTP/3 (QUIC) с мультиплексированием.

Технические нюансы

Имеет больший оверхед в байтах, чем чистый VLESS+Vision или XTLS, из-за HTTP-заголовков.
Настройка связки XHTTP + Cloudflare требует регистрации домена и базовых навыков администрирования.
При проксировании через CDN задержка (пинг) будет выше, чем при прямом подключении к VPS.