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