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