todo/xray/xhttp.md

---
date: 2026-07-17
tags:
  - xray
  - xhttp
  - splithttp
  - transport
  - cdn
  - censorship
aliases:
  - XHTTP
  - SplitHTTP
  - Xray XHTTP transport
link: https://github.com/XTLS/Xray-core/tree/main/transport/internet/splithttp
---

# 📡 XHTTP: транспорт Xray, притворяющийся обычным веб-трафиком

> [!info] О чём заметка
> Подробный разбор транспорта **XHTTP** (раньше назывался **SplitHTTP**) в [[xray/project-x|Xray-core]] — как он заворачивает прокси-трафик в обычные HTTP-запросы, чтобы пройти сквозь CDN вроде Cloudflare, и в чём разница между его режимами `packet-up`, `stream-up` и `stream-one`. Разбор основан на чтении исходного кода `transport/internet/splithttp/` (внутреннее имя пакета осталось `splithttp`, публичное название — XHTTP). XHTTP — это транспорт (как переносить), он ортогонален протоколу [[xray/vless|VLESS]] и слою безопасности [[xray/reality|REALITY]].

## TL;DR

- **XHTTP** — транспорт, который упаковывает поток прокси в обычные HTTP GET/POST-запросы. Для CDN и наблюдателя это выглядит как штатное веб-приложение.
- «Split» в старом названии = **разделение направлений**: скачивание (download) и отправка (upload) идут разными HTTP-запросами, потому что HTTP по своей природе полудуплексный, и промежуточные узлы (CDN, nginx) плохо переносят долгие двунаправленные потоки.
- Три режима: **`packet-up`** (аплинк дробится на кучу коротких POST — самый CDN-дружелюбный), **`stream-up`** (аплинк одним длинным POST, даунлинк отдельным GET), **`stream-one`** (всё в одном дуплексном запросе — для REALITY напрямую, без CDN).
- **XMUX** мультиплексирует много логических сессий в одно физическое соединение и ротирует соединения — как настоящий браузер.
- Маскировка усиливается паддингом, заголовками «под fetch/gRPC/SSE» и анти-буферными заголовками, отключающими кэширование на CDN.

## Зачем нужен XHTTP: пройти сквозь CDN

Основная задача XHTTP — прогнать прокси-трафик **через CDN** (сеть доставки контента, например Cloudflare). Смысл в том, что цензору очень дорого блокировать CDN целиком: за одним IP Cloudflare стоят миллионы легальных сайтов. Если прокси-трафик неотличим от обычных запросов к сайту за CDN, заблокировать его точечно почти невозможно.

Но CDN — капризная среда: она понимает только валидный HTTP, не любит долгие двунаправленные соединения, буферизует и кэширует ответы. Поэтому нельзя просто пустить туда произвольный TCP-туннель. XHTTP устроен так, чтобы выглядеть как настоящее веб-приложение, которое грузит данные POST-запросами и получает ответ GET-запросом.

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

## «Split»: почему upload и download — разные запросы

Один логический дуплексный туннель (VLESS поверх транспорта) в коде представлен структурой `splitConn` — это соединение с **раздельными** `reader` (входящий поток) и `writer` (исходящий). Название «Split» отражает главную идею: два направления физически разнесены на разные HTTP-запросы.

Причина в природе HTTP: тело запроса естественно течёт вверх (клиент → сервер), тело ответа — вниз. Полноценный одновременный дуплекс в одном HTTP-обмене возможен только по HTTP/2 или HTTP/3 и плохо переживает промежуточные прокси. Поэтому:

- **Download (сервер → клиент)** — один длинный GET, тело ответа которого стримится бесконечно.
- **Upload (клиент → сервер)** — либо одно длинное тело POST, либо множество коротких POST (зависит от режима).

Сессию на сервере склеивает общий `sessionId`: GET-запрос даунлинка и все POST-запросы аплинка с одинаковым `sessionId` относятся к одному туннелю.

## Три режима работы

Режим задаётся полем `mode`. Значение `auto` (по умолчанию) раскрывается так: обычно → `packet-up`; при включённом [[xray/reality|REALITY]] → `stream-one`; а если при REALITY задан отдельный канал скачивания (`downloadSettings`) → `stream-up`.

### packet-up — самый CDN-дружелюбный

Аплинк нарезается на **множество коротких независимых POST-запросов**, каждый несёт кусок данных с порядковым номером `seq`. Даунлинк — отдельный длинный GET.

Почему это лучше всего проходит через CDN: короткие POST + один GET не требуют полного дуплекса, который многие CDN не поддерживают. Но есть сложность — независимые POST приходят на сервер **в произвольном порядке** (через CDN они могут идти по разным бэкенд-соединениям). Поэтому каждый POST помечен монотонным `seq`, а сервер восстанавливает исходный порядок.

За пересборку отвечает `upload_queue.go` — очередь с приоритетом (min-heap по `seq`): пакеты выдаются наверх строго по возрастанию номера, «опоздавшие» копятся в куче и ждут недостающий. Если куча разрастается сверх лимита (`scMaxBufferedPosts`, по умолчанию 30) — соединение рвётся, чтобы потерянный пакет не съел всю память.

На стороне клиента есть важная оптимизация — **батчинг**: множество мелких `Write` склеиваются в буфере в один POST покрупнее (иначе пропускная способность резко падает). Между POST выдерживается пауза `scMinPostsIntervalMs` (по умолчанию 30 мс) — заодно сбивает фингерпринт по таймингу.

### stream-up — аплинк потоком

Аплинк идёт **одним длинным потоковым POST** (тело не закрывается, данные текут), даунлинк — отдельным GET. Может использовать разные адреса и транспорты для отправки и скачивания (через `downloadSettings`). Это разделение «загружаю через один канал, качаю через другой».

### stream-one — всё в одном запросе

И аплинк, и даунлинк идут в рамках **одного HTTP-обмена**: тело запроса — вверх, тело ответа — вниз, одновременно. Это истинный дуплекс, требующий HTTP/2 или HTTP/3. Идеален для REALITY напрямую (без CDN), где полный дуплекс гарантирован. `sessionId` здесь не нужен — сессия и есть один запрос.

| Режим | Uplink | Downlink | Где хорош |
|---|---|---|---|
| `packet-up` | много коротких POST с `seq` | отдельный длинный GET | через CDN, HTTP/1.1 |
| `stream-up` | одно длинное тело POST | отдельный GET | раздельные каналы up/down |
| `stream-one` | тело одного запроса | тело того же ответа | REALITY напрямую, h2/h3 |

## XMUX: мультиплексирование как у браузера

**XMUX** управляет тем, сколько HTTP-запросов туннеля мультиплексируется в одно нижележащее (TCP/QUIC) соединение и когда соединения переиспользуются или закрываются. Смысл — вести себя как настоящий браузер: тот держит несколько долгих HTTP/2-соединений и гоняет по ним много параллельных запросов, периодически их обновляя.

Ключевые лимиты (все задаются диапазонами и рандомизируются):

- **`maxConcurrency`** — сколько запросов одновременно активны на одном соединении.
- **`maxConnections`** — сколько соединений держать в пуле.
- **`cMaxReuseTimes`** — сколько раз одно соединение можно переиспользовать.
- **`hMaxRequestTimes`** — сколько всего запросов провести через соединение, прежде чем сменить его.
- **`hMaxReusableSecs`** — временной лимит жизни соединения.

Когда соединение исчерпало лимит запросов или время жизни — клиент переключается на свежее. Ротация соединений экономит TLS-рукопожатия и одновременно мешает фингерпринтить прокси по аномально долгоживущим соединениям.

## Маскировка: паддинг и «правильные» заголовки

XHTTP старательно имитирует легитимный HTTP-трафик несколькими способами:

- **XPadding** — случайный заполнитель (`xPaddingBytes`, по умолчанию 100–1000 байт) размывает характерные размеры запросов и ответов. Есть даже режим `tokenish`, который подгоняет паддинг под нужную длину *после* сжатия заголовков HPACK/QPACK, чтобы на проводе он занимал ровно заданное число байт. По умолчанию паддинг прячется в query-параметр `x_padding` внутри заголовка `Referer`.
- **Заголовки под браузер** — запросы по умолчанию имитируют браузерный `fetch`.
- **Маскировка под gRPC** — потоковые запросы помечаются `Content-Type: application/grpc`.
- **Маскировка под SSE** — даунлинк-ответ помечается `Content-Type: text/event-stream` (Server-Sent Events).
- **Анти-буферные заголовки** — `X-Accel-Buffering: no` и `Cache-Control: no-store` отключают буферизацию и кэширование на nginx/CDN. Это критично: иначе CDN накопил бы стрим в кэше и сломал интерактивность.

Метаданные (`sessionId`, `seq`) и даже саму полезную нагрузку XHTTP умеет раскладывать по разным частям запроса — в путь URL, query, заголовки или cookie (настраивается через `sessionIDPlacement`, `seqPlacement`, `uplinkDataPlacement`). При размещении данных в заголовках/cookie они кодируются base64url и режутся на чанки. Это даёт гибкость под требования конкретного CDN.

## Как XHTTP сочетается с TLS и REALITY

XHTTP — это транспорт уровня приложения (HTTP), а шифрование задаётся отдельно, в общих настройках потока (`streamSettings`), а не внутри самого XHTTP. Слой безопасности — обычный TLS (через uTLS с фингерпринтом браузера) или [[xray/reality|REALITY]].

Выбор версии HTTP зависит от слоя безопасности: при REALITY — всегда HTTP/2; без TLS — HTTP/1.1; иначе по согласованному ALPN (`h3` → HTTP/3, иначе HTTP/2). Именно поэтому при REALITY автоматический режим — `stream-one` (полный дуплекс гарантирован), а через произвольный CDN по HTTP/1.1 безопаснее `packet-up`.

> [!note] XHTTP и Vision: раньше не совмещались, теперь совмещаются через VLESS Encryption
> Долгое время правило звучало просто: [[xray/xtls-vision|XTLS-Vision]] работает только поверх прямого TLS/REALITY по TCP, поэтому в связке с XHTTP flow `xtls-rprx-vision` не использовался, и приходилось выбирать один подход к маскировке из двух. С сентября 2025 это изменилось: если включить [[xray/vless-encryption|VLESS Encryption]], Vision становится доступен поверх XHTTP и других транспортов — документация Xray описывает XTLS как доступный либо при `TCP + TLS/REALITY`, либо при VLESS Encryption без ограничений на транспорт. Оговорка: ядерный `splice` через XHTTP всё равно не включится — он работает только поверх голого TCP. Остальное Vision делает исправно: и набивку внутреннего рукопожатия, и отказ от повторного шифрования уже зашифрованного TLS 1.3, так что выигрыш по процессору сохраняется и здесь. Рекомендация автора Xray для связок через CDN звучит как «VLESS Encryption + XTLS Vision + XHTTP XMUX». Разбор комбинаций — в [[xray/vless-stack-map|карте слоёв VLESS-стека]].

## Ключевые параметры конфига

| Параметр | Что это |
|---|---|
| `mode` | Режим: `auto` / `packet-up` / `stream-up` / `stream-one` |
| `path` | Базовый URL-путь запросов |
| `host` | Значение заголовка `Host` / SNI |
| `headers` | Дополнительные HTTP-заголовки |
| `scMaxEachPostBytes` | Макс. размер тела одного upload-POST (по умолчанию 1 000 000) |
| `scMinPostsIntervalMs` | Мин. пауза между POST (по умолчанию 30 мс) |
| `scMaxBufferedPosts` | Глубина очереди пересборки (по умолчанию 30) |
| `xPaddingBytes` | Диапазон длины паддинга (по умолчанию 100–1000) |
| `noGRPCHeader` / `noSSEHeader` | Отключить маскировку под gRPC / SSE |
| `xmux` | Настройки мультиплексирования (см. выше) |
| `downloadSettings` | Отдельный транспорт/адрес для канала скачивания |

## 📚 См. также

- [[xray/vless|Протокол VLESS]] — протокол, который переносится поверх XHTTP
- [[xray/vless-encryption|VLESS Encryption]] — шифрование самого VLESS: прячет UUID и адреса назначения от CDN и открывает Vision поверх XHTTP
- [[xray/vless-stack-map|Слои VLESS-стека]] — матрица: какие сочетания транспорта, `security`, `flow` и `encryption` работают
- [[xray/reality|REALITY]] — слой безопасности, с которым XHTTP работает через CDN
- [[xray/xtls-vision|XTLS и Vision]] — альтернативный подход (прямой TLS вместо HTTP-маскировки)
- [[xray/project-x|Project X (Xray-core)]] — обзор проекта и всех технологий
- 🔗 [transport/internet/splithttp](https://github.com/XTLS/Xray-core/tree/main/transport/internet/splithttp) — исходный код транспорта

---

> [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ
> При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/xhttp.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).