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