Что такое режим белого списка и при чём тут 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» они не подходят.
Ошибка 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-входа Clearway клиент отправляет uplink в заголовках: uplinkHTTPMethod: "GET", uplinkDataPlacement: "header", uplinkChunkSize: 4096, scMaxEachPostBytes: 4096. Сначала на сервере задайте uplinkDataPlacement: "auto" и serverMaxHeaderBytes: 262144, затем обновите Host и подписки клиентов. Порт, путь, пользователей и остальные параметры сохраняйте. Серверный auto нельзя переносить в клиентскую ссылку.
Экономика трафика и защита origin
Размер uplink-пакета влияет на число HTTP-запросов и нагрузку. Для текущего входа используйте клиентские uplinkChunkSize: 4096 и scMaxEachPostBytes: 4096. Увеличение пакетов ради экономии требует отдельной проверки лимитов CDN и сервера; перенос GET в body сейчас приводит к ошибке 413.
Безопасность 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-слой.