Зачем оператору обфускация XHTTP
При блокировках и шатдаунах мобильные операторы РФ нередко переводят сеть в режим «белого списка»: доступны только whitelisted-ресурсы (часть CDN, госсайты), а VPN, идущий напрямую к своей ноде, отваливается. Reality и Hysteria2 напрямую под троттлингом в таком режиме обычно не проходят — whitelisted-edge их не пропускает.
Рабочий подход — транспорт XHTTP в режиме packet-up через whitelisted CDN-edge: для оператора связи это выглядит как обращение к «белому» CDN, а CDN проксирует трафик на ноду. Но чтобы туннель жил стабильно, запросы должны быть неотличимы от легитимного веб-трафика и корректно упакованы под требования CDN. Именно этим и занимается набор extra-параметров XHTTP.
Обфускация XHTTP здесь — не «магия обхода», а приведение транспорта к форме обычного HTTPS-запроса плюс правильное размещение служебных данных. Три ключевых элемента этой формы — session, seqKey и padding.
session и seqKey: сборка uplink в packet-up
В режиме packet-up downlink (сервер → клиент) идёт одним длинным GET-стримом, а uplink (клиент → сервер) — серией отдельных POST-запросов, «пакетов». Каждый такой POST независим на уровне HTTP, поэтому origin нужно понимать две вещи:
- session — к какой туннельной сессии относится запрос (чтобы не смешать потоки разных клиентов);
- seqKey — порядковый номер пакета, чтобы склеить тела POST в правильной последовательности.
Без этих полей origin не соберёт поток: пакеты придут вперемешку и туннель развалится. С точки зрения маскировки session выглядит как обычный сессионный идентификатор — нормальная для веба вещь, — а seqKey читается как рядовой параметр. Важно понимать: session и seqKey — часть протокола транспорта, а не косметика. Их нельзя произвольно переименовывать или менять формат «для красоты» — это сломает сборку потока.
padding (xPadding): маскировка размеров пакетов
DPI ловит туннели чаще не по содержимому (оно спрятано в TLS), а по метаданным: постоянная длина запросов, характерные интервалы, повторяющиеся размеры POST. Если каждый uplink-пакет имеет узнаваемый размер, поток выделяется на фоне обычного веба.
padding (xPadding) добавляет в запрос филлер случайной длины, чтобы размеры «плавали» и не складывались в стабильный паттерн. Обычно задаётся диапазоном (min–max байт): чем шире диапазон, тем сильнее размывается сигнатура.
padding — это чистая обфускация: на корректность потока он не влияет, влияет только на «внешний вид» трафика. Плата за него — лишние байты. На объём это влияет умеренно, но злоупотреблять широким диапазоном не стоит — экономику это ухудшает (см. ниже).
Куда класть extra-параметры при работе через CDN
Это самый неочевидный и при этом критичный момент. CDN-edge не прозрачен: он проксирует запрос на origin, но по дороге может выбрасывать кастомные заголовки. Отсюда типичная ошибка.
Если положить uplink-данные в кастомный заголовок (например, X-Payload), edge не донесёт этот заголовок до origin. Нода не получит тело uplink — и туннель порвётся с характерной ошибкой unexpected EOF. Лечится это правильным размещением полей:
| Что | Куда класть | Почему |
|---|---|---|
| uplink-payload | тело запроса — uplinkDataPlacement: "body" | тело POST CDN проксирует на origin всегда |
| session / seqKey | cookie | куки CDN-edge доносит до origin стабильно |
| padding (xPadding) | query-строка | query доходит до origin, удобно варьировать длину |
Отдельно стоит секрет X-Cdn-Auth: его добавляет gateway на плече gateway → origin (не клиент), а нода проверяет и отбивает прямые обращения мимо CDN. Этот заголовок не подвержен проблеме edge-стриппинга, потому что живёт на управляемом вами участке, а не на публичном пути клиент → edge.
Клиент и нода: extra должны совпадать точь-в-точь
За CDN нода держит XHTTP-инбаунд (например, на порту 25454). Клиентский конфиг указывает CDN-поддомен как Address / SNI / Host, а трафик уходит на «белый» edge, который проксирует его на ноду.
Жёсткое правило: path и все extra-параметры — режим mode, uplinkDataPlacement, схема размещения session/seqKey, диапазон xPadding — на клиенте и на ноде должны совпадать байт в байт. Любое расхождение в path или в mode ломает туннель: он либо не поднимется вовсе, либо будет рваться.
Настраивается это в разделе инбаунда/транспорта панели — Remnawave, 3x-ui, Marzban или Hiddify. Частая причина «почти рабочего» конфига — разный path на двух концах или разный mode. Всегда сверяйте инбаунд ноды с реально выданным клиентским конфигом, а не с тем, что «должно было сгенерироваться».
Экономика обфускации и безопасность origin
packet-up по своей природе плодит много мелких запросов, а CDN тарифицирует не только переданные байты, но и число запросов. Считать по прайсу за гигабайт нельзя: CDN тарифицирует ещё и количество запросов, а XHTTP плодит много мелких обращений — итоговый счёт расходится с номиналом ₽/ГБ тем сильнее, чем интерактивнее трафик абонентов.
Отсюда два разнонаправленных рычага:
- укрупнение uplink-постов снижает число запросов (больше данных на один POST → меньше запросов → ниже кост);
- широкий padding тянет цену вверх за счёт лишних байт.
Поэтому диапазон xPadding держат разумным, а uplink по возможности батчат. По безопасности: origin закрывают файрволом на вход только с IP gateway и включают проверку секрета X-Cdn-Auth. Без этого ноду можно дёрнуть напрямую мимо CDN — теряется смысл whitelist-маскировки и растёт риск для origin.
Что важно не перепутать
Обфускация XHTTP решает одну задачу — провести туннель через троттлинг и whitelist-режим, приведя транспорт к виду легитимного CDN-трафика. Она не решает разблокировку стриминга: сервисы вроде Кинопоиска банят датацентр-IP по репутации, и для российского контента нужен резидентный IP — это отдельная задача, которую whitelist-CDN не закрывает.
Сам whitelist привязан к подсетям /24: у одних хостеров подсети «белые», у других нет. Selectel часто whitelisted, cloud.ru / SberCloud — часто нет, и статус меняется со временем. Поэтому каждую /24 проверяют актуально и без гарантий.
Эту рутину — подбор whitelisted-подсетей и совместимость XHTTP-параметров с CDN — оператор может снять с себя, взяв «белый» вход как сервис. Clearway (edge *.whitechannel-x1-cdn.ru) даёт whitelisted CDN-edge и проксирование на ноду: оператор держит свою панель и ноды, а Clearway отвечает за whitelisted-вход перед ними.