Обход белых списков через VLESS: рабочие схемы Reality, CDN и XHTTP в 2026 году

Разбираем, как работает VLESS при белых списках ТСПУ: протокол Reality, SNI из белого списка, CDN-фронт и транспорт XHTTP. Практические советы, ограничения и ответы на частые вопросы.

Что такое белый список и почему он ломает VPN

Белый список (allowlist) — это режим блокировки, при котором оператор разрешает доступ только к заранее одобренному набору доменов, а всё остальное блокируется по умолчанию. В отличие от привычного чёрного списка, где запрещены конкретные сайты, здесь работает обратная логика: разрешено только то, что явно указано.

В России этот режим тестируется с осени 2025 года на мобильных операторах «большой четвёрки» — МТС, МегаФон, Билайн и Tele2. По оценкам сообщества, в список входит примерно 1000 доменов из миллиона популярных в мире — около 0,1%. В него попадают Госуслуги, маркетплейсы, экосистема Яндекса, VK, банки и другие социально значимые ресурсы.

Технически блокировка реализована через ТСПУ — оборудование, которое анализирует TLS-рукопожатие и смотрит на SNI (имя сервера). Если домен не в белом списке, соединение устанавливается, но через 16–20 килобайт переданных данных пакеты перестают доходить. Это не разрыв с ошибкой, а «заморозка» — пользователь видит вечную загрузку.

Для VPN это критично: даже если туннель успевает установиться за первые килобайты, дальнейший трафик упирается в стену. Поэтому классические протоколы вроде OpenVPN, WireGuard и Shadowsocks перестают работать — их сигнатуры известны ТСПУ, и рукопожатие режется на ранней стадии.

Почему VLESS+Reality стал основным инструментом обхода

VLESS — это лёгкий прокси-протокол без встроенного шифрования, который обычно работает в паре с TLS. Его главное преимущество — гибкость: он может маскироваться под обычный HTTPS-трафик, используя различные транспорты и обфускации.

Reality — это технология, которая делает TLS-рукопожатие неотличимым от обращения к реальному публичному сайту. Вместо самоподписанного сертификата или поддельного SNI Reality использует настоящий сертификат выбранного сайта, а клиент проверяет его подлинность. Это позволяет обмануть DPI, который видит обычное HTTPS-соединение.

В режиме белого списка VLESS+Reality работает только при одном важном условии: SNI должен быть из белого списка разрешённых российских ресурсов. Если использовать зарубежный домен, ТСПУ не пропустит даже рукопожатие. Поэтому правильный выбор SNI — yandex.ru, mail.ru, vk.com, ok.ru, max.ru, ozon.ru, wildberries.ru, 2gis.ru и другие домены из allowlist.

Однако с ноября 2025 года операторы начали ужесточать проверки: они сравнивают IP-адрес, который резолвится из DNS для выбранного SNI, с реальным IP-адресом сервера, куда уходит трафик. Если они не совпадают, соединение блокируется. Это стало причиной массовых сбоев у пользователей, которые использовали «чужие» SNI без привязки к IP.

Как работает проверка IP и почему она ломает простые схемы

Осенью 2025 года пользователи заметили, что VLESS+Reality перестал работать даже с правильными SNI. Причина — операторы начали проверять не только SNI, но и IP-адрес назначения. Если IP сервера не входит в белый список, соединение блокируется, даже если SNI маскируется под разрешённый домен.

Эта проверка реализована на уровне CIDR-диапазонов. Например, если вы используете SNI yandex.ru, но ваш VPS находится в европейском дата-центре, ТСПУ видит несоответствие: SNI говорит «Яндекс», а IP — зарубежный хостинг. Такое соединение режется.

Некоторые пользователи нашли обходной путь: арендовать VPS в подсетях самих Яндекса или VK (например, в Yandex Cloud или VK Cloud). Если IP вашего сервера попадает в CIDR, который оператор включил в белый список, соединение проходит. Однако такие IP-адреса быстро заканчиваются, и операторы ужесточают требования — вплоть до совпадения первых трёх октетов IP.

Важно понимать: белый список по IP обойти практически невозможно, если ваш адрес не входит в разрешённые диапазоны. Поэтому стратегия обхода строится не на подборе «правильного» IP, а на использовании инфраструктуры, которая уже в белом списке — например, CDN.

CDN-фронт: как спрятать реальный IP за диапазонами CDN

CDN (Content Delivery Network) — это сеть серверов, распределённых по всему миру, которые кэшируют и доставляют контент. Когда вы подключаетесь к сайту через CDN, ваш запрос идёт на ближайший edge-сервер, а тот уже обращается к origin-серверу.

В контексте обхода белых списков CDN решает проблему достижимости адреса. Вместо того чтобы подключаться напрямую к IP вашей ноды (который почти наверняка не в белом списке), клиент подключается к домену CDN. Если IP-диапазоны этого CDN входят в whitelist оператора, соединение физически проходит.

Ключевой момент: CDN не защищает от DPI (анализа трафика), но прячет реальный IP ноды. Для наблюдателя это обычный HTTPS к крупной сети, которую нельзя вырезать точечно без ущерба для легитимных сервисов. Поэтому CDN-фронт стал одним из самых устойчивых способов обхода.

Однако не каждый CDN подходит. Нужно, чтобы его диапазоны действительно были в белом списке у вашего оператора. Это проверяется эмпирически: с устройства в зоне блокировки можно выполнить curl к edge-IP и посмотреть, устанавливается ли соединение. У разных операторов списки отличаются, поэтому универсального решения нет.

Транспорты для CDN: XHTTP, WebSocket и gRPC

Сырой TCP/Reality через CDN не работает, потому что CDN понимает только HTTP(S). Поэтому нужен транспорт поверх HTTP. На практике используются три варианта: WebSocket, gRPC и XHTTP.

WebSocket — самый совместимый вариант. Его поддерживают почти все CDN, и по нему больше всего гайдов. Однако у него есть минусы: одна TCP-сессия на соединение, а некоторые CDN обрывают upgrade или закрывают соединение по idle-таймауту.

gRPC — мультиплекс поверх HTTP/2, стабилен на длинных сессиях. Но требует сквозного HTTP/2, а часть CDN даунгрейдит до HTTP/1.1, что ломает стриминг.

XHTTP (splithttp) — самый гибкий вариант. Он рассчитан на промежуточные HTTP-прокси и умеет работать даже там, где CDN разрешает только GET. XHTTP разделяет upload и download, что важно для CDN, которые по-разному обрабатывают направления. Главный подводный камень — режим packet-up: если CDN не пропускает POST, нужно явно задать mode packet-up на обеих сторонах, иначе клиент и сервер не договорятся о направлении аплоада.

Проверить, режет ли ваш CDN POST, можно простым curl-запросом. Если POST возвращает 403/405, а GET — 200/404, значит CDN GET-only, и packet-up обязателен.

Настройка VLESS через CDN: каркас без панелей

Настройка VLESS через CDN состоит из нескольких шагов, общих для всех панелей (3x-ui, Marzban, Remnawave).

  1. DNS и origin. Заведите поддомен, наведите его на CDN. В настройках CDN укажите origin — IP вашей ноды. Реальный IP не должен светиться ни в одном клиентском конфиге.
  1. TLS. Клиент → CDN идёт по валидному сертификату CDN-домена. CDN → origin — по своему TLS (или отдельному сертификату на ноде). SNI клиента — ваш CDN-домен.
  1. Inbound на ноде. Настройте VLESS + XHTTP на конкретном path (например, /xhttp). Тот же path пропишите в правилах CDN — проксировать на origin, а не кэшировать как статику.
  1. Режим. Если CDN умеет POST — можно оставить auto. Если только GET — жёстко packet-up на клиенте и сервере.
  1. Кэш. Для трафикового path отключите кэш на CDN (Cache-Control: no-cache), иначе CDN будет отдавать устаревшие ответы, а подписки — залипать.

После настройки проверьте, что handshake идёт на CDN-домен, а не на IP ноды. Можно имитировать падение прямого IP с помощью iptables и убедиться, что соединение через CDN продолжает работать.

AmneziaWG и Hysteria2 как альтернативы VLESS

Хотя VLESS+Reality — самый популярный протокол для обхода белых списков, есть и другие рабочие варианты.

AmneziaWG — российская модификация WireGuard от команды Amnezia. Перед обычным handshake протокола передаются junk-пакеты со случайными заголовками, из-за чего ТСПУ не может опознать сигнатуру WireGuard. Внешне трафик выглядит как случайный UDP, который в whitelist обычно пропускается. Производительность — как у обычного WireGuard, без накладных расходов.

Hysteria2 — современный протокол на QUIC поверх UDP, маскируется под обычный HTTP/3-трафик. На нестабильных мобильных сетях работает особенно хорошо благодаря собственному контролю перегрузки Brutal: пользователь задаёт реальную полосу пропускания, и алгоритм её удерживает, не сбрасывая скорость при потерях пакетов.

Эти протоколы могут быть полезны, если VLESS+Reality не работает у конкретного оператора. Однако они менее гибки в настройке SNI и CDN-фронтов, поэтому для максимальной устойчивости многие используют комбинацию: VLESS+Reality для прямого подключения и AmneziaWG/Hysteria2 как запасной вариант.

Двойной туннель: российский VPS + зарубежный VPS

Ещё один способ повысить устойчивость — использовать цепочку из двух серверов: клиент → российский VPS с «белым» IP → зарубежный VPS → интернет.

Логика проста: ТСПУ видит, что вы общаетесь с российским сервером, чей IP или SNI в белом списке. Дальше трафик идёт между двумя серверами, и Россия не блокирует исходящий трафик с собственных коммерческих VPS на внешние сети. Таким образом, вы обходите ограничение на уровне первого хопа.

Минусы: нужны два VPS (около $10 в месяц суммарно) и навыки настройки. Но для важных сценариев это один из самых стабильных вариантов на сегодня.

Важно: российский VPS должен быть в подсети, которая входит в белый список оператора. Это могут быть, например, диапазоны Yandex Cloud или VK Cloud. Проверить можно, подключившись к VPS с мобильного интернета в режиме whitelist — если соединение устанавливается, значит IP подходит.

Практические советы: что делать, если VPN не работает

Если вы столкнулись с тем, что VLESS+Reality перестал работать в режиме белого списка, действуйте по порядку:

  1. Проверьте, включён ли whitelist. Если Wi-Fi работает, а мобильный интернет — нет, скорее всего, режим активен.
  1. Переключите протокол на VLESS+Reality, AmneziaWG или Hysteria2. Чистые WireGuard, OpenVPN, Trojan и Shadowsocks не пройдут.
  1. Убедитесь, что SNI для Reality — из белого списка (yandex.ru, max.ru и т.д.). Не используйте зарубежные домены.
  1. Попробуйте другой сервер или другую локацию. Возможно, конкретный IP уже заблокирован.
  1. Если ничего не помогает, рассмотрите CDN-фронт или двойной туннель.

Также полезно настроить автоматическое подключение VPN при включении устройства, чтобы при следующей блокировке не пришлось настраивать всё в спешке. И помните: белый список — это временная мера, но она может длиться от часа до нескольких суток.

Ограничения и риски: что нужно знать заранее

Обход белых списков — это гонка вооружений. Операторы постоянно ужесточают проверки, и то, что работало вчера, может перестать работать сегодня. Вот ключевые ограничения:

  • Белый список по IP обойти практически невозможно, если ваш адрес не входит в разрешённые диапазоны.
  • CDN-фронт не гарантирует вечную работу: диапазоны CDN могут выпадать из whitelist после изменений у оператора.
  • Латентность растёт из-за лишнего хопа через CDN — для игр и голосовых звонков это может быть критично.
  • CDN стоит денег, и считать нужно не только гигабайты, но и количество запросов — XHTTP генерирует много мелких запросов, что увеличивает счёт.
  • Origin-сервер нужно прятать: если реальный IP утечёт (через старые A-записи или прямые подключения), весь смысл CDN-фронта теряется.

Также важно понимать, что использование VPN для обхода блокировок может нарушать законодательство РФ. Статья 15.3 ФЗ-149 предусматривает ответственность за обход блокировок, хотя на практике наказания для конечных пользователей редки. Тем не менее, риски существуют, и каждый решает сам.

Вопросы и ответы

Какой SNI выбрать для VLESS+Reality в России?

Для России SNI должен быть из белого списка разрешённых ресурсов: yandex.ru, mail.ru, vk.com, ok.ru, max.ru, ozon.ru, wildberries.ru, 2gis.ru и другие. Использование зарубежных доменов приведёт к блокировке рукопожатия. Также важно, чтобы IP вашего сервера соответствовал SNI — операторы проверяют это соответствие.

Почему VLESS+Reality перестал работать после 6 ноября 2025?

Операторы начали проверять не только SNI, но и IP-адрес назначения. Если IP сервера не входит в белый список, соединение блокируется, даже если SNI маскируется под разрешённый домен. Это стало причиной массовых сбоев у пользователей с VPS в зарубежных дата-центрах.

Что лучше: CDN-фронт или двойной туннель?

Оба варианта имеют плюсы и минусы. CDN-фронт проще настроить и он дешевле (если не считать трафик), но зависит от того, входят ли диапазоны CDN в whitelist. Двойной туннель с российским VPS в белой подсети более стабилен, но требует двух серверов и навыков настройки. Выбор зависит от ваших задач и бюджета.

Можно ли использовать WebSocket вместо XHTTP для CDN?

Да, WebSocket — самый совместимый транспорт, его поддерживают почти все CDN. Однако у него есть минусы: одна TCP-сессия на соединение и возможные обрывы по idle-таймауту. XHTTP более гибок и лучше подходит для CDN, которые разрешают только GET, но требует аккуратной настройки режима packet-up.

Как проверить, работает ли CDN-фронт?

С устройства в зоне блокировки выполните curl к edge-IP с resolve на ваш CDN-домен. Если соединение устанавливается и возвращается HTTP-код, значит диапазон CDN проходит. Также можно имитировать падение прямого IP с помощью iptables на ноде и убедиться, что клиент через CDN остаётся онлайн.

Какие протоколы точно не работают при белых списках?

Чистые WireGuard, OpenVPN, Trojan и Shadowsocks без обфускации не проходят — их сигнатуры известны ТСПУ, и рукопожатие режется на ранней стадии. Также не работают MTProto-прокси и другие протоколы, которые не маскируются под легитимный трафик.

Сколько стоит держать VLESS через CDN?

Стоимость зависит от CDN-провайдера и тарификации. Важно учитывать не только гигабайты, но и количество запросов — XHTTP генерирует много мелких запросов, что может увеличить счёт. Рекомендуется просчитать экономику до подключения, особенно для больших объёмов трафика.