Что происходит с мобильным интернетом под блокировками
Когда речь про «блокировки» на уровне мобильного оператора, инженеру важно различать два режима. Обычный DPI-троттлинг замедляет или рвёт подозрительные сессии, но сеть остаётся открытой. Гораздо жёстче — режим белого списка: в зоне шатдауна или ограничений мобильный интернет переводится так, что доступны только whitelisted-ресурсы (часть CDN, госсайты, отдельные сервисы), а всё остальное не резолвится или не отдаёт трафик.
Для VPN-оператора это переломная точка. Пока сеть открыта, задача сводится к маскировке транспорта. В whitelist-режиме маскировка уже не спасает: любой транспорт, который идёт напрямую на IP вашей ноды, не проходит, потому что подсеть ноды не в белом списке. Отсюда практический вывод: под жёсткими ограничениями выживает не «самый скрытный протокол», а тот вход, чей IP-адрес оператор считает «белым».
Именно поэтому вопрос «reality vs xhttp» или «hysteria2 под блокировкой» некорректно решать в отрыве от инфраструктуры входа. Транспорт — это половина задачи; вторая половина — за каким адресом он спрятан.
Почему Reality и Hysteria2 напрямую не проходят
Reality маскирует хендшейк под TLS к реальному стороннему сайту и хорошо противостоит активному пробингу в открытой сети. Но сам туннель всё равно устанавливается к IP вашей ноды. Как только оператор ушёл в whitelist-режим, дело уже не в том, «похож ли хендшейк на настоящий TLS», — а в том, что адрес назначения не в белом списке. Такой трафик edge просто не пропускает.
Hysteria2 работает поверх QUIC/UDP и хорош на нестабильных каналах, но под ограничениями это двойная уязвимость: UDP часто режется или деградирует первым, а назначение — снова прямой IP ноды вне белого списка. На практике под троттлингом и в whitelist-режиме Hysteria2 напрямую обычно не проходит.
Это не значит, что протоколы «плохие» — в открытой сети они рабочие. Проблема в топологии «клиент → нода напрямую».
| Транспорт | Как ходит | В открытой сети | Под whitelist-режимом (напрямую) |
|---|---|---|---|
| Reality | TLS-маскировка, TCP на IP ноды | Устойчив к пробингу | Обычно не проходит (IP не в белом списке) |
| Hysteria2 | QUIC/UDP на IP ноды | Хорош на плохих каналах | Обычно не проходит (UDP режется + IP не whitelisted) |
| XHTTP через CDN | HTTP(S) на whitelisted CDN-edge | Рабочий | Выживает: edge — «белый», проксирует на ноду |
Что выживает: XHTTP через whitelisted CDN
Рабочий подход под жёсткими ограничениями — спрятать вход VPN за whitelisted CDN-edge (например, за CDN, чьи подсети попадают в белые списки операторов). Схема по идее простая:
- Клиент обращается не к ноде, а к поддомену CDN.
- Оператор видит обычное обращение к «белому» CDN и пропускает его.
- CDN-edge проксирует запрос на ваш origin — ноду с XHTTP-инбаундом.
Почему именно XHTTP (mode packet-up): это транспорт поверх обычного HTTP(S), который CDN умеет прозрачно форвардить как веб-трафик. Reality и Hysteria2 через типовой CDN так не пронести — edge не пропускает их как «не-HTTP». XHTTP же для CDN выглядит легитимными HTTP-запросами и потому доходит до origin.
Со стороны панели это выглядит так: нода держит XHTTP-инбаунд на отдельном порту (например, 25454), а клиентский конфиг указывает CDN-поддомен как Address/SNI/Host. Схема одинаково ложится на Remnawave, 3x-ui, Marzban и Hiddify — разница только в UI. Критично, чтобы path и extra на клиенте и на ноде совпадали точь-в-точь: любое расхождение — и туннель не поднимется.
unexpected EOF при XHTTP через CDN: тело запроса против кастомного заголовка
Это самый частый и самый неочевидный провал при заводе XHTTP через CDN. По умолчанию некоторые конфигурации кладут uplink-полезнагрузку в кастомный HTTP-заголовок (например, X-Payload). В прямой связке «клиент → нода» это работает. Через CDN — нет.
Причина: CDN-edge не обязан доносить произвольные кастомные заголовки до origin — он их режет или нормализует. В результате нода не получает uplink-данные, и туннель рвётся с характерным unexpected EOF. Инженер при этом видит, что downlink идёт, а сессия не поднимается, — и теряет часы на ложные гипотезы.
Правильная раскладка XHTTP через CDN:
- uplinkDataPlacement: "body" — данные uplink идут в теле запроса, которое CDN всегда доносит до origin;
- session/seq — в cookie (cookie CDN сохраняет);
- padding — в query (параметры URL тоже доходят до origin).
Правило: через CDN доверять можно только тому, что гарантированно доходит до origin — телу, cookie и query. Всё, что зависит от кастомных заголовков, под CDN считайте ненадёжным.
Whitelist привязан к /24: выбор хостера и подсети
Белый список операторов привязан не к конкретному IP и не к «хостеру вообще», а к подсетям /24. У одного провайдера часть /24 может быть whitelisted, а соседняя — нет. Поэтому нельзя выбрать «хорошего хостера» раз и навсегда: проверять нужно каждую /24 отдельно, и статус со временем меняется.
| Хостер / сеть | Наблюдаемый статус | Практика |
|---|---|---|
| Selectel | Часто whitelisted | Нередко подходит, но проверять конкретную /24 |
| cloud.ru / SberCloud | Часто НЕ whitelisted | Обычно не годится под whitelist-вход |
| Прочие ДЦ | Непредсказуемо | Тестировать каждую /24 отдельно |
Это ориентиры, а не гарантии. Правильный процесс: перед запуском проверять актуальный статус конкретной /24 на реальной мобильной сети в зоне ограничений, а не полагаться на «вчера работало». Именно поэтому многие операторы не держат whitelist-вход сами, а берут его как сервис — чтобы не гоняться за меняющимися подсетями.
Экономика CDN-трафика и учёт в панели
CDN-вход — не бесплатный слой, и его стоит закладывать в юнит-экономику. Прайс за гигабайт — только половина счёта. Вторая половина у части провайдеров это запросы, а XHTTP в режиме packet-up дробит аплинк на множество мелких обращений. Реальная удельная стоимость выводится только из собственного биллинга: она зависит от профиля трафика абонентов и от того, тарифицирует ли провайдер запросы. Это ориентир, а не тариф: конкретные цифры зависят от профиля трафика и условий провайдера — считайте по своим данным.
Отсюда прямой инженерный рычаг: чем крупнее посты в body, тем меньше число запросов — и тем ниже стоимость. Это ещё один довод в пользу раскладки uplink в тело: она не только чинит unexpected EOF, но и снижает кост.
По учёту трафика используйте механизмы панели. В Remnawave есть множитель потребления ноды и per-user лимиты. Приём: множитель 0 на ноде означает, что трафик через неё не считается против лимита пользователя, при этом сама нода продолжает работать — удобно для fallback-входа, который вы не хотите тарифицировать пользователю.
Безопасность origin и что CDN НЕ решает
Раз вход теперь через CDN, origin (ноду) нужно закрыть, иначе его найдут напрямую в обход «белого» слоя:
- Файрвол на вход — принимать только с IP gateway/CDN; всё остальное дропать.
- Секрет-заголовок
X-Cdn-Auth— origin отвечает только на запросы с валидным секретом, что защищает от прямых обращений мимо CDN.
И отдельно — про частую путаницу. Whitelist-CDN решает задачу доставки туннеля до ноды под троттлингом и в whitelist-режиме. Он не решает разблокировку стриминга. Сервисы вроде Кинопоиска банят датацентр-IP по репутации (это не про whitelist), и для российского контента нужен резидентный IP — отдельная задача, которую whitelist-CDN не закрывает. Не смешивайте «пробить троттлинг» и «разблокировать стриминг»: это разные слои инфраструктуры.
Если собирать всё вручную неохота — держать актуальные whitelisted /24, чинить XHTTP-раскладку под конкретный CDN и следить за реноме подсетей — whitelisted-вход можно взять как сервис. Clearway (clear-way.pro) даёт операторам именно «белый» вход перед их нодами (CDN-edge *.whitechannel-x1-cdn.ru), без продажи серверов: вы держите свои ноды и панель, а устойчивость входа под ограничениями оператора закрывается на стороне CDN-слоя.