Как технически работает VLESS Reality (объясняем на пальцах)

Reality — это не очередной шифр и не магия. Это очень аккуратный фокус с TLS-рукопожатием, который заставляет систему глубокой инспекции пакетов поверить, что вы зашли на amazon.com. В этой статье мы по шагам разберём, как именно он это делает, без формул и без размытых аналогий — но и без академического тумана.

Если вы хоть раз настраивали клиент Hiddify, v2rayN или Streisand, вы наверняка видели длинную ссылку, начинающуюся с vless:// и хвостом из публичного ключа, SNI, fingerprint и short ID. За этой строкой стоит протокол, который в 2023 году переписал правила игры в обходе DPI — и до сих пор остаётся единственным способом гарантированно работать сквозь ТСПУ. Чтобы понять, почему он работает, надо сначала разобраться, как именно блокировки обнаруживают VPN-трафик, а потом посмотреть, как Reality прячется от этих механизмов прямо у них на виду.

Что вообще ищет DPI, когда «видит» ваш трафик

Глубокая инспекция пакетов — это не магическое чтение мыслей. Это набор довольно простых эвристик, которые ТСПУ применяет к каждому TCP- или UDP-соединению, проходящему через российский магистральный шлюз. Если упростить до уровня бытовой логики, выглядит это так: на оборудование приходит поток байтов, и оно задаёт ему несколько последовательных вопросов. На какой порт идёт соединение? На какой IP? Какой первый пакет полезной нагрузки? Похож ли он на TLS, или на QUIC, или на голый WireGuard? Если похож — насколько именно? Совпадают ли версии шифров с теми, что обычно использует Chrome или iPhone? Видно ли поле SNI, и если да — известный ли это домен?

Каждый из этих вопросов превращается в правило. Например: «UDP-пакет длиной ровно 148 байт со специфическим заголовком — это WireGuard handshake, режем». Или: «TLS Client Hello, в котором отсутствует расширение ALPN, но есть подозрительный набор шифров — это Shadowsocks с обфускацией, режем». ТСПУ обновляется регулярно: новые сигнатуры подгружаются Роскомнадзором централизованно на все магистральные узлы, и иногда обновление перекрывает протокол, который ещё вчера работал. Так в 2022-м умер OpenVPN, в 2023-м — Shadowsocks-2022 и трюк с маскировкой под HTTPS под названием TLS-in-TLS, а в 2024-м прекратили работать почти все варианты Trojan и стандартного V2Ray.

У этой системы есть одно фундаментальное ограничение: DPI не может позволить себе блокировать всё подозрительное. Если оборудование начнёт резать любое необычное TLS-соединение, в России перестанут открываться половина сайтов, банковские приложения и игры. Поэтому правила всегда формулируются как «блокировать X, который похож на VPN», а не «пропускать только то, что точно не VPN». Reality эксплуатирует именно этот зазор.

Главная идея Reality: не маскироваться, а быть настоящим

Все предыдущие способы обхода DPI пытались притвориться легитимным трафиком. Shadowsocks выдавал себя за HTTPS, добавляя в начало соединения правдоподобный TLS-заголовок. Trojan делал то же самое, но честнее: внутри у него действительно был TLS, просто с самоподписанным сертификатом и поддельным доменом. Проблема в обоих случаях одна и та же — рано или поздно DPI учился отличать настоящий TLS от поддельного. Достаточно было сравнить тайминги, последовательность сообщений, набор поддерживаемых шифров или поведение сервера на нестандартный запрос — и маска слетала.

Автор Reality (известный под ником RPRX, разработчик ядра Xray) подошёл к проблеме под другим углом. Он сказал: давайте не будем притворяться. Давайте сделаем так, чтобы наш сервер в самом деле устанавливал TLS-соединение с настоящим легитимным сайтом — например, с www.microsoft.com или www.apple.com — и подменял трафик только тогда, когда узнает «своего» клиента. А для «не своих» — пусть всё работает как настоящий поход на этот сайт.

Идея настолько неочевидная, что её стоит проговорить ещё раз другими словами. Представьте, что ваш VPN-сервер — это администратор гостиницы, который ещё подрабатывает почтальоном. Когда к нему приходит обычный гость и спрашивает номер, он отвечает как настоящий администратор: вот ключ, вот лифт, всё штатно. А когда приходит «свой» курьер с условной фразой — например, особым образом сложенным конвертом — администратор молча открывает потайную дверь и пускает его в служебное помещение. Снаружи здание выглядит абсолютно нормально, потому что оно и есть нормальная гостиница. Просто у некоторых гостей в кармане лежит другой пропуск.

Технически это означает следующее: на стороне сервера Reality стоит специальный прокси, который умеет одновременно играть две роли — обычного TLS-зеркала на чужой домен и VPN-шлюза. Внешне порт 443 ничем не отличается от обычного веб-сервера, и если вы попробуете зайти на IP-адрес VPN-ноды через браузер, вам откроется настоящий microsoft.com с настоящим сертификатом Microsoft. Никакого подлога — сервер действительно сходил на www.microsoft.com и принёс вам оттуда страницу.

Что именно происходит во время рукопожатия

Теперь самое интересное — момент, в который ваш VPN-клиент и сервер договариваются, что они «свои». Reality использует встроенный механизм TLS 1.3, который называется ClientHello — это первое сообщение, которое любой TLS-клиент отправляет при установке защищённого соединения. В нём указывается, на какой домен мы хотим попасть (поле SNI), какие версии шифров поддерживаем, какие расширения протокола нам нужны. Для DPI это видимое сообщение: оно ещё не зашифровано, потому что шифрование договорится только после.

В обычной жизни клиент пишет в SNI что-то вроде www.example.com, и DPI видит, куда мы идём. Reality делает то же самое — пишет в SNI настоящий легитимный домен, например www.amazon.com или dl.google.com. Этот домен выбирается заранее при настройке сервера: важно, чтобы это был популярный TLS-1.3-сайт без HTTP/2 ALPN-нюансов, с быстрым ответом и без CDN-капризов. Список «хороших» SNI для Reality — отдельная тема, но идея в том, что DPI видит в SNI домен, который ему запрещено блокировать (попробуйте порезать amazon.com — в России мгновенно ляжет половина интернет-магазинов и Twitch).

Но в ClientHello помимо SNI есть ещё десятки полей-расширений. Одно из них — TLS extension под названием key_share — содержит публичный ключ клиента для эфемерного обмена ключами по алгоритму X25519. Reality использует именно это расширение, чтобы спрятать в нём «секретный байт» — крошечный фрагмент данных, зашифрованный заранее заготовленным симметричным ключом, который знают только VPN-клиент и VPN-сервер. Для DPI этот key_share выглядит абсолютно как обычная случайная байтовая последовательность — потому что эллиптические ключи и должны быть неотличимы от шума. А сервер Reality, получив ClientHello, первым делом смотрит на это поле и пробует «расшифровать» его своим ключом.

Дальше развилка. Если расшифровка дала ожидаемый результат — значит, это «свой» клиент, и сервер переключается в режим VPN: дальше пойдёт зашифрованный туннель, через который вы будете ходить в интернет. Если расшифровка ничего внятного не дала — значит, к нам пришёл случайный гость (например, ТСПУ из любопытства решило проверить, что отдаст этот IP при подключении по 443). В этом случае Reality не закрывает соединение. Он молча, прозрачно, без единой задержки прокидывает весь трафик к настоящему amazon.com и обратно. И клиент-исследователь получает настоящий ответ Amazon с настоящим сертификатом Amazon, валидным по всем проверкам. Никакого «лишнего» поведения, никакого RST в неожиданный момент, никаких неверных версий TLS — потому что отвечает действительно Amazon, а не наш сервер.

Эта симметрия — главное архитектурное достижение Reality. Раньше системы маскировки палились именно на «активных пробах»: ТСПУ периодически пытался установить TLS-соединение с подозрительными IP-адресами и смотрел на ответ. Если сервер вёл себя странно (закрывал соединение, возвращал самоподписанный сертификат, не поддерживал нужные расширения) — IP попадал в чёрный список. Reality на активную пробу отвечает идеально: ведь отвечает не он, а реальный сервер реального домена через прозрачный TLS-прокси.

Откуда берётся скорость и почему батарея не плачет

На этом моменте у внимательного читателя должен возникнуть вопрос: если сервер каждый раз ходит на amazon.com, чтобы проверить клиента, не убьёт ли это скорость? Не получится ли так, что мы платим за двойной трафик и тройные задержки? Ответ — нет, и причина в том, что Reality использует так называемый XTLS Vision flow. Это специальный режим работы, в котором после установки соединения данные пользователя идут напрямую между клиентом и его финальным адресатом в интернете, без повторного шифрования внутри VPN-туннеля.

Чтобы понять разницу, вспомните, как работает классический VPN. Каждый ваш HTTP-запрос сначала шифруется TLS внутри вашего браузера, потом ещё раз заворачивается в VPN-протокол (тоже зашифрованный), потом по сети идёт до VPN-сервера, там разворачивается из VPN-обёртки и улетает к финальному сайту. На обратном пути то же самое в зеркальном порядке. Это два слоя шифрования и два слоя расшифровки на каждом конце — а значит, удвоенная нагрузка на CPU и батарею. Если соединение и так шифровано (а 95% современного веба идёт по HTTPS), второй слой избыточен: он не добавляет безопасности, потому что внутренний TLS и так защищает данные.

XTLS Vision это понимает. После того как Reality убедился, что клиент «свой», и установил основной канал, последующая полезная нагрузка не шифруется повторно. Браузер передаёт уже зашифрованный TLS-пакет, Reality добавляет к нему минимальный заголовок и прокидывает в сеть. Получается, что VPN-сервер работает почти как обычный TCP-роутер — с минимальной обработкой каждого байта. На практике это даёт прирост скорости 30–50% по сравнению с обычным VLESS поверх TLS и 2–3-кратное снижение нагрузки на CPU клиента. Именно поэтому Reality на смартфоне почти не сажает батарею: процессору не приходится постоянно крутить AES и ChaCha20 на каждом килобайте видео из YouTube.

Есть и приятный побочный эффект для производительности — Reality по умолчанию работает поверх обычного TCP, а не UDP. Это позволяет ему пользоваться оптимизациями ядра Linux на стороне сервера: SO_REUSEPORT, TCP BBR, GRO/GSO-офлоадинг сетевой карты. UDP-протоколы вроде WireGuard тоже быстры, но на больших задержках и нестабильных каналах (мобильный интернет в электричке) TCP с правильным congestion control часто оказывается стабильнее. Поэтому Reality хорошо чувствует себя там, где WireGuard начинает заикаться.

Почему ТСПУ не может это заблокировать

Если объединить всё вышесказанное, картина для блокировщика выглядит так: соединение идёт на легитимный публичный IP (нашего VPN-сервера, но снаружи он представляется как обычный веб-узел); на порт 443 (нельзя заблокировать — лежит весь HTTPS); внутри ClientHello указан реальный, общеизвестный домен в SNI; шифры, расширения и порядок полей в TLS-рукопожатии полностью совпадают с тем, что отправляет настоящий Chrome или Safari (Reality умеет подделывать «отпечаток» популярных браузеров через uTLS); сертификат, который видит активная проба, настоящий и валидный; время ответа — нормальное; ALPN, OCSP, key shares — всё как у живых сайтов. Не за что зацепиться.

Теоретически у ТСПУ остаётся ровно один путь — блокировать конкретные IP-адреса VPN-серверов, когда их каким-то образом удаётся вычислить (например, через утечку из публичного списка узлов или массовое тестирование диапазонов). Но это игра в кошки-мышки на стороне инфраструктуры: VPN-провайдеры просто арендуют новые IP, иногда даже на ходу через blue/green deployment. И именно поэтому в России в 2026 году выживают только те сервисы, у которых есть стабильная инфраструктура с быстрой ротацией IP — а не самосборные VPN на одном арендованном сервере.

В PlaceVPN мы используем именно VLESS Reality с XTLS Vision и подменой SNI на крупные публичные домены. Все наши узлы в Финляндии, Латвии и Молдове настроены так, чтобы выдерживать активные пробы ТСПУ без следов. Бот выдаёт vless://-ссылку, которую вы импортируете в Hiddify (iPhone/Android) или v2rayN (Windows/macOS) одним тапом — никакой ручной работы с ключами и SNI.