Как VLESS Reality делает VPN-трафик невидимым для цензоров

У каждого VPN-протокола есть фингерпринт. Инициация handshake WireGuard всегда ровно 148 байт с фиксированной структурой. У контрольного канала OpenVPN тайминги, очевидные при анализе. Даже Shadowsocks, спроектированный специфически для устойчивости к цензуре, производит трафик с измеримо высокой энтропией, который DPI-системы могут флагать как «не нормальный HTTPS».

Шифрование защищает контент. Никак не скрывает факт, что используешь VPN.

VLESS Reality, выпущенный в Xray-core v1.8.0 в начале 2023, берёт совершенно другой подход. Вместо шифрования трафика и надежды, что цензоры не идентифицируют обёртку, делает VPN-соединения идентичными обычному HTTPS-браузингу. Не похожими. Идентичными. TLS-сертификат, который представляет соединение — настоящий, выпущенный настоящим CA, для настоящего сайта.

Вот как это работает, почему это сложно блокировать, и что отдаёшь, чтобы получить.

Проблема детекта

DPI-системе не нужно расшифровывать трафик, чтобы знать, какой протокол. Просто нужно распознать паттерны.

WireGuard — лёгкий пример. Сообщение инициации handshake начинается с 1-байтового поля типа, 3 байта зарезервированных нулей, 4-байтового sender index, потом 32-байтовый незашифрованный эфемерный ключ. Эта структура никогда не меняется. ТСПУ (Технические средства противодействия угрозам) России может детектить WireGuard с почти 100% точностью, матчя этот паттерн на первом пакете.

OpenVPN чуть сложнее детектить, но не сильно. У TLS-handshake характерные тайминги, и контрольный канал использует узнаваемый формат фрейминга. Великий китайский файрвол блокирует его надёжно годами.

Сложнее проблема — энтропийный анализ. Полностью зашифрованный трафик (случайные байты без узнаваемой структуры) реально выглядит подозрительно. У нормального HTTPS-трафика конкретный статистический профиль: TLS-handshake с предсказуемыми цепочками сертификатов, потом зашифрованные данные приложения с характерными размерами записей. Соединение Shadowsocks — поток высокоэнтропийных байт с первого пакета. Для статистического классификатора эта разница очевидна.

Это фундаментальный вызов. Шифрование делает данные нечитаемыми, но трафик сам имеет форму. Цензорам не нужно читать данные. Им нужно распознать форму.

Почему традиционная обфускация проваливается

До Reality сообщество устойчивости к цензуре пробовало несколько подходов обфускации трафика.

obfs4 оборачивает трафик в слой, спроектированный выглядеть случайным шумом. Какое-то время работало. Потом Китай и Иран развернули классификаторы, флагающие высокоэнтропийные потоки, не совпадающие с известным протоколом. Если трафик не выглядит как HTTP, HTTPS, DNS или другой обычный — блокируется или троттлится. Случайный шум на самом деле очень выделяется, когда вокруг всё структурировано.

Shadowsocks имеет ту же энтропийную проблему. AEAD-варианты улучшили, но фундамент остался: трафик не выглядит ни на что легитимное. Китайские DPI начали блокировать Shadowsocks-соединения, детектя отсутствие стандартного TLS-handshake в комбинации с высокоэнтропийными нагрузками.

Domain fronting (отправка трафика к одному домену через CDN, маршрутизирующий к другому) работало хорошо, пока Google, Amazon и Cloudflare все его не закрыли между 2018 и 2020. Полагалось на терпимость CDN-провайдеров. Они перестали.

Trojan был улучшением. Мимикрирует HTTPS, реально выполняя TLS-handshake и обслуживая настоящий сайт неавторизованным соединениям. Но Trojan использует self-configured TLS-сертификат, цепочка которого отличается от того, что представил бы настоящий сайт. Активный пробер, сравнивающий сертификат сервера с известными Certificate Transparency-логами, может заметить расхождение.

Паттерн через все: они пытаются аппроксимировать нормальный трафик, не будучи им. При достаточном анализе аппроксимация всегда ломается.

RPRX (создатель проекта XTLS) ясно сформулировал проблему: цензура SNI-whitelist сделала все TLS-based инструменты обхода до Reality недоступными в определённых областях за ночь. Если цензор решит пускать только соединения к известным легитимным TLS-серверам, любой инструмент со своим сертификатом мёртв.

Как Reality реально работает

Reality не аппроксимирует TLS-handshake. Делает настоящий.

Поток подключения шаг за шагом:

Шаг 1: клиент шлёт ClientHello. Клиент инициирует TLS 1.3 handshake. Поле Server Name Indication (SNI) содержит hostname настоящего популярного сайта вроде www.microsoft.com. Клиент использует библиотеку uTLS для копирования точного TLS-фингерпринта настоящего браузера (Chrome 120, Firefox, Safari, что настроено). ClientHello байт-в-байт идентичен тому, что отправил бы тот браузер.

Шаг 2: сервер получает ClientHello. Сервер Reality проверяет pre-shared shortId и валидирует клиента через X25519 key agreement. Эта аутентификация происходит внутри полей, непрозрачных любому наблюдателю, скрытых в key share extension TLS-handshake.

Шаг 3: сервер связывается с реальным камуфляж-сайтом. Сервер Reality открывает своё TLS-соединение к настоящему www.microsoft.com (или любому домену, настроенному как камуфляж-цель). Делает легитимный TLS-handshake с серверами Microsoft.

Шаг 4: сервер форвардит реальный сертификат. Цепочка сертификатов, которую возвращает Microsoft, форвардится обратно клиенту. Это настоящий сертификат, подписанный настоящим CA, для настоящего домена. Нечего детектить, потому что нечего фейкового.

Шаг 5: аутентифицированные клиенты туннелируются. Если клиент прошёл shortId и X25519-аутентификацию на шаге 2, сервер устанавливает VLESS-туннель. VPN-трафик течёт внутри того, что выглядит как нормальная HTTPS-сессия с microsoft.com.

Шаг 6: неаутентифицированные соединения форвардятся. Если кто-то (активный пробер цензора, исследователь, кто угодно) подключается без валидных credentials, сервер прозрачно проксирует соединение к настоящему microsoft.com. Видят настоящий контент. Настоящие заголовки. Настоящее поведение. Нечем отличить сервер от легитимного reverse proxy.

Это ключевое отличие от каждого предыдущего подхода. Сертификат настоящий. Сайт за ним настоящий. TLS-фингерпринт совпадает с настоящим браузером. Нет детектируемой лжи во всей цепочке.

Устойчивость к активному зондированию

Цензоры не только пассивно анализируют. Активно зондируют подозрительные серверы.

Великий китайский файрвол это делает как минимум с 2012. Когда детектит соединение, могущее быть прокси, реплеит handshake клиента или шлёт свой пробу серверу. Если сервер отвечает иначе, чем легитимный сервис — блокируется.

Так Trojan-серверы рано или поздно детектируются. Пробер подключается, не аутентифицируется, и сервер возвращает generic веб-страницу. Но TLS-сертификат не совпадает с тем, что Certificate Transparency logs говорят о домене. Или HTTP response headers слегка отличаются от настоящего развёртывания того веб-сервера. Мелкие несоответствия, но достаточно.

Reality полностью побеждает активное зондирование. Когда пробер подключается к Reality-серверу без валидных credentials, форвардится к настоящему камуфляж-сайту. Ответ — не симуляция. Это И ЕСТЬ microsoft.com через прозрачный прокси. Тот же сертификат. Те же заголовки. То же поведение. Тот же контент.

Цензору пришлось бы различать «пользователь, посещающий microsoft.com» и «Reality-сервер, проксирующий к microsoft.com». Снаружи они идентичны. TLS-сессия выглядит так же. HTTP-ответы те же. IP-адрес — единственное отличие, и IP, хостящий reverse proxy к microsoft.com, не подозрителен сам по себе.

Vision flow и TLS-in-TLS

Есть более тонкий вектор детекта, который Reality тоже адресует. Когда запускаешь VPN внутри TLS-туннеля, зашифрованный VPN-трафик содержит свои TLS-handshakes (каждый посещаемый HTTPS-сайт генерирует один). Это создаёт TLS-in-TLS паттерн: TLS-записи, содержащие явно ещё TLS-записи, видимые через анализ трафика, даже если контент зашифрован.

XTLS Vision flow (xtls-rprx-vision) это устраняет. Вместо двойного шифрования TLS-трафика Vision детектит, когда внутренняя нагрузка уже TLS-protected, и пропускает с минимальной обёрткой. Внешний TLS-слой обрабатывает аутентификацию и фрейминг; внутренние TLS-данные текут без избыточного шифрования.

Статья USENIX подтвердила, что Vision достиг design goals. Паттерн трафика VLESS+Vision соединения статистически неотличим от прямого HTTPS-соединения к камуфляж-сайту.

Это важно, потому что анализ трафика (смотреть размеры пакетов, тайминги и паттерны без расшифровки) — самая правдоподобная оставшаяся атака против Reality. Vision закрывает этот пробел.

Что делает блокирование сложным

Чтобы заблокировать VLESS Reality, цензор должен сделать одно из:

Заблокировать камуфляж-домен полностью. Если Reality настроен мимикрировать microsoft.com, цензору нужно заблокировать microsoft.com. Или google.com. Или какой ещё домен выбрали операторы. Блокировка крупных облачных и productivity-сервисов имеет огромную экономическую цену. Китай принял эту цену для части сервисов, но даже Китай не блокировал microsoft.com.

Детектить X25519-аутентификацию в TLS-handshake. Эта информация в key share extension, который шифруется в TLS 1.3. Без ломки самого TLS-handshake аутентификация невидима.

Идентифицировать Reality-серверы по IP-репутации. Это самый эффективный подход, найденный цензорами. ТСПУ России начал флагать VPS-IP, получающие соединения с определёнными поведенческими паттернами: соединения от residential к VPS, также проксирующим к известным сайтам. Это не детект Reality самого. Это детект инфраструктурных паттернов вокруг. Скорость детекта правильно настроенного VLESS Reality всё ещё ниже 5% по сообществу, на февраль 2026.

Анализ таймингов трафика. У VPN-трафика другие тайминги, чем у нормального браузинга. Пользователь, стримящий видео через Reality, генерирует стабильные высокопропускные потоки, не совпадающие с типичными HTTPS-паттернами браузинга к microsoft.com. Это реальная слабость, хотя требует изощрённого анализа и даёт много false positives.

Иран расследовал блокировку Reality (обсуждается в GitHub issue #3269 в Xray-core). Пока надёжный метод детекта не развёрнут. Подход России с IP-репутационным скорингом самый успешный, но ловит малую часть соединений и требует постоянной ручной настройки.

Tradeoff'ы

Запускаем VLESS Reality в production в Fexyn рядом с WireGuard и OpenVPN. Не будем притворяться, что это бесплатный обед. Реальные расходы есть.

Задержка. Соединение Reality добавляет примерно 100 мс задержки по сравнению с WireGuard. Дополнительный TLS-handshake с камуфляж-сайтом, X25519-аутентификация и слой проксирования занимают время. Для общего браузинга едва заметно. Для гейминга или real-time голоса — почувствуешь.

TCP-оверхед. VLESS Reality работает поверх TCP. WireGuard — поверх UDP. У TCP head-of-line блокировка: если один пакет потерян, всё за ним ждёт ретрансмиссии. На сетях с потерями (мобильные, перегруженный Wi-Fi) это значит периодические тормоза, которых UDP-протоколы избегают. Транспортный режим XHTTP помогает мультиплексированием, но фундаментальное TCP-ограничение остаётся.

Сложность настройки. WireGuard нужна пара ключей и эндпоинт. Reality нужен камуфляж-домен, shortId, X25519-пара ключей, выбор uTLS-фингерпринта, transport-конфигурация и тщательное тестирование, чтобы камуфляж-сайт работал корректно. Мы это автоматизировали в Fexyn (клиент получает полную конфигурацию из нашего API), но self-hoster-ам больше управлять.

Сложность отладки. Когда падает WireGuard-соединение, режимы провалов прямые: неправильный ключ, неправильный эндпоинт, заблокирован порт. Когда падает Reality-соединение, может быть камуфляж-домен, shortId, пара ключей, uTLS-фингерпринт, transport-слой, недостижимость камуфляж-сайта с сервера или полдюжины других. Мы потратили значительное время отладки на Reality-соединения, оказавшиеся проблемами камуфляж-домена.

Не все камуфляж-домены работают одинаково. Камуфляж-сайт должен поддерживать TLS 1.3, иметь сертификат, цепочка которого ведёт к доверенному CA, и быть достижимым с твоего сервера. Часть доменов работает идеально. У других есть quirks, вызывающие тонкие провалы. Тестировали много и осели на наборе надёжных целей, но это потребовало реальной trial-and-error работы.

Реальные показатели детекта

По репортам сообщества и нашему тестированию:

Страна	WireGuard	OpenVPN	VLESS Reality
Россия (ТСПУ)	Блокируется мгновенно	Блокируется/троттлится	~95% успеха
Китай (GFW)	Блокируется	Блокируется	Работает, периодические IP-блоки
Иран	Блокируется	С перебоями	Работает, под активным исследованием
Туркменистан	Блокируется	Блокируется	Ограниченные данные, репортится работающим

~5% провала в России — в основном IP-репутационный скоринг, не детект протокола. Использование residential-выглядящих IP-диапазонов или облачных провайдеров не в blacklist приближает успех к 100%.

В Китае основная угроза — IP-блокировка, не детект протокола. GFW поддерживает списки известных VPS-IP-диапазонов и периодически блокирует. Reality-соединения с чистых IP работают стабильно.

Когда использовать

Если ты в стране без активной цензуры, WireGuard — лучший выбор. Быстрее, проще, использует UDP. Нет причин принимать tradeoffs Reality, если никто не блокирует.

Если ты в или едешь в страну с активным DPI (Россия, Китай, Иран, ОАЭ, многие другие), VLESS Reality с Vision flow — протокол, который реально работает. WireGuard будет заблокирован до завершения handshake.

Fexyn поддерживает оба с автоматической ротацией протоколов, переключающейся на VLESS Reality, когда WireGuard заблокирован. Получаешь скорость WireGuard, когда доступна, и устойчивость Reality к цензуре, когда нужна.

Если хочешь больше про сам VLESS-протокол (отдельно от транспорта Reality), мы написали детальный разбор VLESS, покрывающий архитектуру протокола и сравнение с альтернативами.

Попробуй Fexyn бесплатно 7 дней — Stealth (VLESS Reality с Vision flow) включён в каждый план.