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