Что значит «пробивается под троттлингом»: режим белого списка
Когда мобильный оператор в РФ уходит в режим ограничений — при веерных шатдаунах или локальных блокировках — сеть переводится в режим белого списка. В этом состоянии абоненту доступны только whitelisted-ресурсы: часть CDN, госсайты, отдельные сервисы. Всё остальное, включая VPN-ноду, к которой клиент ходит напрямую по IP, становится недоступно — пакеты просто не выходят за пределы разрешённого списка.
Поэтому «пробивается ли сервер под троттлингом» — это вопрос не про скорость, а про доступность входа в режиме белого списка. Вход пробивается, если оператор считает его обращением к разрешённому ресурсу. На практике это достигается тем, что VPN-вход спрятан за whitelisted CDN-edge: оператор видит трафик как запрос к «белому» CDN, а edge проксирует его на вашу ноду. Задача проверки — подтвердить это поведение в реальных условиях ограничения, а не в лабораторных.
Почему универсального чекера whitelist не существует
Публичного чекера, который гарантированно скажет «ваш IP в белом списке», нет — и вот почему. Белый список привязан к подсетям /24, ведётся на стороне оператора, отличается по регионам и меняется без анонсов. IP, доступный вчера, завтра может выпасть. Любой «онлайн-чекер whitelist оператора» даёт в лучшем случае косвенную оценку, а не факт.
Единственный авторитетный источник правды — реальное устройство на проблемном операторе в затронутом регионе в момент ограничения. Проверка с VPS, пинг из другого региона или тест на обычном мобильном интернете без троттлинга идут по другому пути и вводят в заблуждение. Корректный метод — дифференциальный тест: одновременно проверить несколько целей с одной и той же SIM и сравнить, что отвечает, а что нет.
Дифференциальный тест: как проверить сервер под блокировкой
Суть теста — развести три независимые цели и посмотреть на разницу в их доступности с одного устройства:
- Контрольный «белый» ресурс — заведомо whitelisted-сайт (госсервис или крупный CDN-ресурс). Подтверждает, что устройство действительно в режиме белого списка, а не просто офлайн.
- Прямой IP ноды — TLS-хендшейк или запрос напрямую к серверу VPN по его IP.
- CDN-поддомен входа — домен вида
*.whitechannel-x1-cdn.ruили ваш CDN-edge, за которым спрятана нода.
Интерпретация результатов:
| Контрольный ресурс | Прямой IP ноды | CDN-поддомен | Что это значит |
|---|---|---|---|
| отвечает | отвечает | отвечает | Ограничений нет — оператор не в режиме белого списка, тест неинформативен |
| отвечает | не отвечает | отвечает | Режим белого списка активен, вход через CDN пробивается — целевое состояние |
| отвечает | не отвечает | не отвечает | CDN-edge не в белом списке для этого оператора — меняйте /24 edge |
| не отвечает | — | — | Полный шатдаун или устройство офлайн — тест невалиден, повторите |
Ключевой сигнал успеха — вторая строка: прямой путь к ноде закрыт, а путь через CDN живёт.
Проверка подсети /24 и статуса хостера
Если CDN-поддомен не пробивается (третья строка таблицы), проблема почти всегда в подсети. Оператор whitelisting-ит не отдельные хосты, а блоки /24. Поэтому проверять нужно /24 именно того узла, который непосредственно отвечает оператору: при схеме за CDN это IP edge-узла, при прямой схеме — IP самой ноды.
Практика по хостерам нестабильна и требует актуальной проверки под каждую /24:
- Selectel — подсети часто оказываются whitelisted.
- cloud.ru / SberCloud — подсети часто НЕ в белых списках.
Это наблюдение, а не гарантия: статус меняется, и соседние /24 одного хостера могут вести себя по-разному. Никогда не полагайтесь на «хостер X — белый» целиком. Проверяйте конкретную /24, фиксируйте результат и перепроверяйте периодически — то, что пробивалось на прошлой неделе, могло выпасть.
Проверка транспорта и конфигурации: не спутайте с троттлингом
Частая ошибка — принять сбой конфигурации за троттлинг. Под белым списком напрямую обычно не проходят Reality и Hysteria2: edge их не пропускает. Рабочий транспорт через CDN — XHTTP в режиме packet-up.
Но и XHTTP легко сломать так, что симптом будет неотличим от «не пробивается». Критичный момент: uplink-данные должны идти в теле запроса (uplinkDataPlacement: "body"), а не в кастомном заголовке вроде X-Payload. CDN-edge не доносит кастомные заголовки до origin, и туннель рвётся с ошибкой unexpected EOF. Session/seq кладите в cookie, padding — в query.
Проверьте также, что path, host и extra на клиенте и на ноде совпадают точь-в-точь — иначе туннель не поднимется, даже если сеть в порядке. Нода за CDN держит XHTTP-инбаунд (например, на порту 25454), а клиентский конфиг указывает CDN-поддомен в Address/SNI/Host.
Разделяйте два уровня проверки: доступность CDN-поддомена на сетевом уровне (TLS-хендшейк проходит) и подъём самого туннеля. Если хендшейк до CDN есть, а туннель всё равно не встаёт — дело в конфиге (body placement, рассинхрон path/host), а не в белом списке оператора.
Отделяем троттлинг от репутации IP и проверяем origin
Не путайте две разные задачи. «Пробить троттлинг» — это доступность входа в белом списке. «Разблокировать российский стриминг» (Kinopoisk и подобные) — отдельная проблема: такие сервисы банят датацентр-IP по репутации и требуют резидентного IP. Whitelist-CDN эту задачу не решает. Если после успешного прохождения теста стриминг всё равно не работает — причина не в троттлинге.
Заодно проверьте, что origin закрыт: файрвол на входе должен пускать только IP gateway, а секрет-заголовок X-Cdn-Auth — отсекать прямые обращения к ноде мимо CDN. Если нода из строки 2 таблицы отвечает на прямой IP всем подряд — это дыра в защите, а не «вход пробивается».
Собрать и держать whitelisted-вход самостоятельно можно, но /24 нужно постоянно перепроверять и менять при выпадении из белого списка. Clearway (clear-way.pro) отдаёт whitelisted-вход как сервис для VPN-операторов: edge-домен *.whitechannel-x1-cdn.ru стоит перед вашими нодами, а вы отвечаете только за саму ноду и её конфиг. Считать по прайсу за гигабайт нельзя: CDN тарифицирует ещё и количество запросов, а XHTTP плодит много мелких обращений — итоговый счёт расходится с номиналом ₽/ГБ тем сильнее, чем интерактивнее трафик абонентов.