Зачем оператору обфускация 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, но по дороге может выбрасывать кастомные заголовки. Отсюда типичная ошибка.
Ошибка unexpected EOF сама по себе не определяет причину. В текущем входе Clearway GET с телом отклоняется CDN с ошибкой 413. Проверьте серверный auto и лимит заголовков, затем клиентский header; для других ошибок сопоставьте время и журналы клиента, CDN, gateway и origin. Ответ HTTP 200 и успешный TLS ещё не подтверждают передачу HTTPS через туннель. Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Отдельно стоит секрет X-Cdn-Auth: его добавляет gateway на плече gateway → origin (не клиент), а нода проверяет и отбивает прямые обращения мимо CDN. Этот заголовок не подвержен проблеме edge-стриппинга, потому что живёт на управляемом вами участке, а не на публичном пути клиент → edge.
Актуальные настройки XHTTP через CDN
За 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-вход перед ними.