Что такое режим белого списка у мобильного оператора
«Белый список интернета оператора» — это не постоянная настройка тарифа, а аварийный/ограничительный режим фильтрации, который операторская сеть включает по команде регулятора: во время региональных отключений мобильного интернета, массовых блокировок или локальных шатдаунов. В обычном состоянии сеть работает по принципу «разрешено всё, кроме заблокированного» (чёрные списки на DPI/ТСПУ). В режиме whitelist логика инвертируется: разрешено только то, что явно внесено в белый список, остальное отбрасывается или жёстко троттлится.
Для инженера, который строит VPN-сервис, важны три следствия этого режима:
- Фильтрация идёт на уровне транспортного/сетевого стыка (IP-адрес назначения, SNI, паттерн трафика), а не на уровне приложения.
- Прямое обращение к вашей ноде по IP датацентра почти всегда попадает в «неразрешённое» и рвётся.
- Whitelist динамичен: его состав и охват меняются в разных регионах и в разное время, единой публичной таблицы не существует.
Поэтому задача оператора VPN формулируется как задача устойчивости инфраструктуры: сделать так, чтобы вход сервиса технически совпадал с тем, что операторская сеть уже считает «белым», а не пытаться «пробить» фильтр в лоб.
Что попадает в whitelist: подсети /24, CDN и госресурсы
В белые списки операторов обычно попадают ресурсы, отключение которых ломает базовую доступность: государственные порталы, часть инфраструктуры крупных экосистем и, что важнее всего для нашей задачи, подсети магистральных CDN. Именно CDN даёт «серую зону»: через один и тот же whitelisted edge раздаётся легитимный контент множества сервисов, поэтому оператор не может просто вырезать его целиком.
Ключевой технический факт: whitelist привязан к подсетям /24, а не к целым ASN или /16-блокам. Нельзя сказать «весь такой-то провайдер в белом списке». Внутри одного /16 соседние /24 могут иметь разных фактических владельцев и разный статус: одна попала в whitelist, соседняя — нет. Это принципиально меняет методику размещения нод.
| Что часто внутри whitelist | Что обычно снаружи |
|---|---|
| Подсети /24 крупных CDN | Прямые IP «обычных» датацентров |
| Госпорталы | Произвольные VPS по IP |
| Часть инфраструктуры экосистем | Транспорты с характерным «не-HTTP» отпечатком |
Отсюда практический вывод: белый список мобильных операторов нельзя рассматривать как список доменов, который можно «подставить». Это набор сетевых признаков (в первую очередь — подсети), и работать нужно именно с ними.
Нужен вход, который проходит при белых списках, прямо сейчас? CLEAR VPN: первые 5 дней бесплатно, карта не нужна, до 10 устройств.
Получить ключ на 5 дней →Почему прямой VPN отваливается, а вход за CDN — нет
Когда клиент VPN идёт напрямую к вашей ноде, операторская сеть в режиме белого списка видит соединение к IP-адресу, которого нет в whitelist, — и обрывает его. Маскировка протокола на уровне приложения тут не помогает, потому что решение принимается раньше, по адресу назначения и паттерну трафика.
Рабочий подход — поставить перед нодой whitelisted CDN-edge. Схема движения трафика:
- Клиент обращается не к IP ноды, а к поддомену CDN (он же прописан как Address/SNI/Host в конфиге).
- Для операторской сети это обращение к «белой» подсети CDN — трафик проходит фильтр.
- CDN-edge принимает соединение и проксирует его на ваш origin (ноду).
- Нода терминирует VPN-туннель и выпускает пользователя в интернет.
Важный нюанс: сам origin не обязан находиться в whitelisted-подсети — «белизну» на стыке с оператором обеспечивает edge. Origin может стоять на любом хостинге, лишь бы был доступен со стороны CDN. Это развязывает две задачи, которые раньше приходилось решать одним сервером: «попасть в белый список» и «держать производительную ноду».
Именно на этом принципе строится whitelist-CDN как инфраструктурный слой: оператор арендует не сервер, а whitelisted-вход перед своей нодой.
Транспорт под троттлингом: XHTTP через CDN vs Reality/Hysteria2
Не любой транспорт переживёт проход через CDN-edge и режим белого списка. Здесь есть жёсткое ограничение: edge — это HTTP-обратный прокси, он пропускает то, что выглядит как валидный HTTP(S)-запрос, и не пропускает всё остальное.
- XHTTP (mode packet-up) через CDN — рабочий подход. Трафик туннеля упаковывается в обычные HTTP-запросы, которые edge спокойно проксирует на origin. Для операторской сети это HTTPS к whitelisted CDN, для CDN — легитимный HTTP к origin.
- Reality, Hysteria2 напрямую под троттлингом обычно не проходят. Reality рассчитан на прямое TLS-соединение и не переживает промежуточный HTTP-прокси; Hysteria2 работает поверх QUIC/UDP, который edge через себя как HTTP не пропускает. В режиме белого списка попытка идти этими транспортами напрямую упирается в тот же фильтр по адресу назначения.
Поэтому под задачу «устойчивость под ограничениями оператора» практически безальтернативно берут XHTTP за CDN. Reality/Hysteria2 остаются полезными как транспорты для регионов и операторов без whitelist-режима, но как «белый» вход они не годятся.
Актуальные настройки XHTTP через CDN
Это самый неочевидный и самый частый источник поломок при заводе XHTTP за CDN. XHTTP умеет размещать uplink-данные (то, что клиент шлёт на сервер) в разных местах HTTP-запроса. И вот здесь CDN расставляет ловушку.
Ошибка 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 через CDN:
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Как проверять whitelist по /24 и где размещать ноды
Поскольку белый список операторов работает по /24 и меняется, единственный надёжный метод — проверять конкретную подсеть, а не доверять репутации хостера целиком. Порядок работы:
- Определить владельца /24. Один и тот же /16 может быть физически разделён между разными компаниями; ASN и владельца конкретной подсети смотрят через RDAP / ip-api.
- Свериться с актуальным списком. Открытые агрегированные списки whitelisted-префиксов мобильного интернета РФ помогают предварительно отсеять заведомо «серые» подсети, но их нужно перепроверять — состав меняется.
- Сделать реальный тест из мобильной сети. Никакая офлайн-проверка не даёт 100%: единственная достоверная проверка — поднять ресурс в подсети и подключиться к нему из мобильной сети оператора в зоне ограничений.
По статусу хостеров (ориентир, не гарантия — проверяйте актуально по каждой /24):
| Хостер | Практика по whitelist |
|---|---|
| Selectel | часть /24 регулярно оказывается в whitelist |
| cloud.ru / SberCloud | подсети часто НЕ в whitelist |
| Крупные публичные облака | статус нестабилен: диапазоны то попадают, то выпадают — обязательна проверка каждой /24 |
Важная деталь: близость к whitelisted-подсети ничего не значит. Внутри выделенного пула может быть whitelisted только одна конкретная /24, а соседняя — нет. Поэтому при заказе IP через API облака нужно отбирать адреса по факту попадания в нужные префиксы, а не по «соседству». И держать в голове, что статус динамичен — то, что работало вчера, может выпасть из whitelist оператора завтра.
Настройка входа за CDN: панели, порты и безопасность origin
На стороне ноды нужен XHTTP-инбаунд, а на стороне клиента — конфиг, указывающий на CDN-поддомен. Подход одинаково ложится на популярные панели: Remnawave, 3x-ui, Marzban, Hiddify.
Опорные правила:
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Безопасность origin — обязательная часть, а не опция:
- Файрвол на вход: origin принимает соединения только с IP gateway/edge, всё остальное закрыто. Это отсекает прямое сканирование ноды по IP.
- Секрет-заголовок (например,
X-Cdn-Auth): edge добавляет его к запросам на origin, origin отклоняет всё без корректного секрета. Так нода защищена от обращений мимо CDN, даже если её IP кто-то узнал.
Отдельно про учёт трафика в панели (на примере Remnawave): у ноды есть множитель потребления и per-user лимиты. Множитель 0 на ноде означает, что её трафик не засчитывается против лимита пользователя, при этом нода продолжает работать — удобно для сервисных/тестовых нод. Для боевого CDN-входа множитель обычно ставят по реальной экономике трафика.
Экономика CDN-трафика и учёт потребления
Whitelisted-вход через CDN — это метрируемый трафик, и его стоимость нужно закладывать в юнит-экономику сервиса.
- Ставку за сырой трафик смотрите в прайсе выбранного провайдера — разброс между площадками кратный.
- На масштабе плата за запросы становится отдельной статьёй расхода, и считать её надо по своей выгрузке из биллинга, а не по прайсу. Причина — XHTTP плодит множество мелких HTTP-запросов, а тарификация CDN учитывает не только объём, но и число запросов.
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Для учёта на стороне сервиса удобно опираться на механизмы панели: множитель потребления ноды и per-user лимиты (Remnawave), а на инфраструктурном слое — на инкрементальный учёт байт на gateway. Важный технический момент для тех, кто строит собственный биллинг поверх стриминговых транспортов: учёт трафика должен быть инкрементальным, а не по завершению запроса. XHTTP-даунлинк — это один длинный streaming-GET на всю сессию; если считать байты только по закрытию соединения, большая часть трафика не учитывается в реальном времени и теряется при рестарте счётчика.
Чего whitelist-CDN не решает: стриминг и резидентные IP
Важно не смешивать две разные инженерные задачи, потому что их часто путают в поддержке.
- «Пройти режим белого списка оператора» — это задача доступности: сделать вход сервиса whitelisted, чтобы туннель вообще поднимался. Её решает CDN-edge перед нодой.
- «Разблокировать российский стриминг» — это отдельная задача про репутацию исходящего IP. Сервисы вроде Kinopoisk банят датацентр-IP по репутации: с адреса дата-центра контент не отдаётся независимо от того, как построен вход. Для такого контента нужен резидентный (residential) IP на выходе.
Whitelist-CDN это НЕ решает. Он обеспечивает «белый» вход и устойчивость под ограничениями оператора, но не меняет репутацию выходного IP ноды. Если пользователи оператора ждут доступ к контенту, чувствительному к типу IP, это отдельный слой инфраструктуры (резидентные выходы), который строится и оплачивается отдельно.
Для текущего XHTTP-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.