XHTTP-транспорт: когда и зачем

XHTTP решает не ту же задачу, что Reality. Reality прячет тебя от блокировки по рукопожатию, XHTTP — от блокировки по IP, пряча ноду за CDN. Разбираю, что это за транспорт, чем он отличается от вебсокетов и когда его доставать. Конфиги — в парной практике.

Другая ось защиты

Сначала разложу, чтобы не было путаницы. DPI душит VPN по трём осям: рукопожатие/SNI, поведение трафика, IP. Reality и Vision закрывают первые две. Но когда тебе просто заблокировали IP — отравили адрес, забанили подсеть хостера, — никакая маскировка рукопожатия не поможет: пакеты до ноды физически не доходят. Тут нужна другая защита — спрятать ноду за чужим большим IP, которому доверяют. Это и есть работа CDN. А чтобы твой VPN проехал сквозь CDN, нужен транспорт, который CDN пропускает как обычный веб-трафик. XHTTP — как раз такой.

То есть XHTTP не конкурент Reality, а другой инструмент для другой беды. Часто их даже совмещают: XHTTP как транспорт плюс Reality как маскировка рукопожатия.

Что такое XHTTP и откуда он взялся

XHTTP — это транспорт поверх обычного HTTP. Раньше он назывался SplitHTTP, потом переименовали. Идея: упаковать VPN-поток в набор обычных HTTP-запросов и ответов, так чтобы для любого промежуточного узла (в первую очередь CDN) это выглядело как штатный HTTP-обмен — GET-ы, POST-ы, привычные заголовки, ничего экзотического.

Он пришёл на смену WebSocket-транспорту, который долго был стандартом для прохода за CDN, и заменил его не случайно. У WebSocket есть врождённые болячки: он требует апгрейда соединения (тот самый Upgrade: websocket), держит одно долгоживущее соединение, и не все CDN его любят — некоторые режут или таймаутят долгие апгрейднутые коннекты. XHTTP эти проблемы обходит: он не апгрейдит соединение в вебсокет, а работает как поток обычных HTTP-запросов, которые CDN обрабатывает штатно, без спецрежима.

Почему именно он дружит с CDN

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

Отдельно про режимы. У XHTTP есть три способа гонять данные вверх (от клиента к серверу), и выбор между ними — это балансировка «надёжность против задержки»:

• auto — транспорт сам выбирает, разумный дефолт для большинства случаев.
• packet-up — надёжнее за капризными CDN, которые чудят с длинными потоками; данные идут отдельными запросами, CDN их спокойнее переваривает.
• stream-up — ниже задержка, поток идёт непрерывнее, но требовательнее к тому, как CDN держит соединение.

На практике я начинаю с auto, и если за конкретным CDN вылезают обрывы — переключаю на packet-up. Это первое, что стоит попробовать, когда «за CDN не заводится».

Важное отличие: у XHTTP нет Vision

Момент, на котором спотыкаются те, кто пришёл с TCP-Reality. На XHTTP flow не используется — Vision тут нет и быть не должно. Vision — специфичная штука для сырого TCP, где надо руками ломать паттерн двойного TLS. У XHTTP другая модель: поток размывается самой природой HTTP-транспорта, данные пакуются в запросы, и отдельный flow не нужен. Пропишешь flow на XHTTP-инбаунде — получишь неработающий или некорректный конфиг. Просто оставляй поле пустым.

Два сценария применения

XHTTP бывает в двух обвязках, и это надо различать:

XHTTP + Reality (прямой). Транспорт XHTTP, а рукопожатие маскируется донорским Reality без своего сертификата. Это когда ты хочешь плюсы XHTTP-транспорта, но подключаешься напрямую к ноде, не через CDN. Стелс тот же, что у Reality, плюс устойчивость HTTP-транспорта.

XHTTP + TLS (за CDN). Честный TLS на твоём домене — то, что нужно для фронта за Cloudflare или другим CDN. TLS терминирует твой домен или сам CDN, а трафик идёт как обычный HTTPS к «сайту», который на самом деле твоя нода за фронтом. Это основной сценарий обхода блокировки по IP.

Когда доставать XHTTP из резерва

Я держу XHTTP не как основной канал, а как слой выживания, который включается по ситуации:

• Заблокировали IP или подсеть. Reality не спасёт — рукопожатие в порядке, но пакеты не доходят. Уходишь за CDN на XHTTP-TLS, и клиент подключается к CDN-домену, а не к твоему адресу.
• Режут именно TCP. Если в регионе душат TCP-профиль, а UDP-Hysteria не вариант, XHTTP за CDN — обходной путь.
• Скрытый резерв для авто-свопа. Один видимый основной канал (TCP-Reality) плюс XHTTP в подписке скрытым конфигом: основной лёг — клиент переключается на XHTTP автоматически.

Отдельно про цену: за CDN добавляется задержка (лишний хоп через фронт, обычно доли секунды). Поэтому XHTTP-за-CDN — не то, что ставят «на всех по умолчанию», а то, что достают, когда прямое подключение перестало работать.

Что дальше

Суть ты понял: XHTTP — про обход блокировки по IP через CDN, а не про маскировку рукопожатия; у него нет Vision; и он бывает в двух обвязках — прямой с Reality и за CDN с TLS. Как поднять XHTTP поверх Reality руками — путь, path, режимы, проверка — в парной практике «Настройка XHTTP поверх Reality».