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