Гайд: как работает Reality (XTLS) и почему он обходит DPI

TrustMe · 04.Август.2026 20:07:18

На форуме десятки конфигов с Reality, но мало где объясняется, почему он вообще работает. А понимать это важно: когда знаешь механику, ты осознанно настраиваешь dest/serverNames, а не копируешь чужой JSON наугад. Разберём протокол REALITY (XTLS) по-человечески — без воды, но по существу.

Проблема, которую решает Reality

Классические «обёртки в TLS» (Trojan, VMess+TLS) уязвимы сразу с нескольких сторон:

TLS-in-TLS. Внутри вашего TLS едет ещё один TLS от прокси — DPI умеет распознавать этот «двойной» паттерн.
Свой сертификат = свой отпечаток. Чтобы поднять честный TLS, нужен домен и сертификат, а связка «домен + сертификат + поведение сервера» образует опознаваемую сигнатуру.
SNI виден. Имя домена в ClientHello открыто → цензору легко блокировать по SNI.
Активные пробы. Цензор стучится на ваш сервер и по нестандартному ответу понимает, что это прокси.

Ключевая идея: не поднимать TLS, а «занять» чужой

Reality не реализует собственный TLS — он заимствует рукопожатие настоящего чужого сайта. В конфиге вы указываете реальную цель (dest, например www.microsoft.com:443), и клиент делает вид, что подключается именно к ней. Снаружи это выглядит как обычный визит на популярный сайт с валидным сертификатом этого сайта.

Дальше работает аутентификация на X25519:

сервер генерирует пару ключей X25519; публичный ключ — это, по сути, «пароль» клиента (publicKey);
клиент внутри легитимного TLS-потока доказывает знание ключа — незаметно для наблюдателя;
аутентифицированный клиент получает временный сертификат, подписанный эфемерным ключом, и дальше едет проксёй;
неаутентифицированный запрос (проба цензора, случайный сканер) проваливается на настоящий целевой сайт и получает его реальный контент.

Именно в этом магия: сервер неотличим от того сайта, который он подделывает. Нет своего сертификата — нечего фингерпринтить; нет TLS-in-TLS — нечего ловить; активная проба упирается в настоящий microsoft.com.

Главные параметры конфига

Со стороны сервера:

dest (target) — реальный сайт-донор рукопожатия, домен:порт;
serverNames — список SNI, которые клиент имеет право предъявлять (должны соответствовать dest);
privateKey — приватный ключ X25519;
shortIds — короткие идентификаторы для разграничения клиентов/групп.

Со стороны клиента:

serverName — какой SNI предъявлять (из serverNames);
publicKey — публичный ключ сервера;
shortId — соответствующий идентификатор;
fingerprint — профиль uTLS (chrome, firefox и т. п.), чтобы TLS-отпечаток совпадал с реальным браузером.

Трезвая оценка: не серебряная пуля

Reality силён, но у него есть жёсткие требования, о которые спотыкаются новички.

Выбор dest критичен. Донор должен быть «чужим», популярным, поддерживать TLS 1.3 и X25519, находиться рядом (по маршруту/гео) с вашим сервером и не стоять за Cloudflare/вашим же хостером. Плохой dest — и маскировка сыпется.
serverNames обязаны соответствовать dest. Рассинхрон — типичная причина «не подключается».
Это не панацея от блокировок. Reality маскирует отпечаток, но не спасает от блокировки по IP вашего сервера или от эвристик по объёму/таймингам трафика. Свежие блокировки иногда требуют комбинировать транспорты (см. на форуме тему про xHTTP).
Совместимость. Reality — это XTLS/Xray-экосистема; клиент и сервер должны её поддерживать (актуальные Xray-core, sing-box, клиенты уровня v2rayN/Throne/Streisand).

Что делать

Подберите dest осознанно: крупный сторонний сайт с TLS 1.3 и X25519, географически близкий к серверу, не за Cloudflare. Проверить поддержку можно, например, через онлайн TLS-чекеры.
Держите serverName = один из serverNames = домен dest. Это лечит 90% проблем «не коннектится».
Ставьте fingerprint: chrome (или актуальный браузерный профиль) на клиенте — чтобы uTLS-отпечаток совпадал с массовым трафиком.
Не полагайтесь только на Reality: при жёстком DPI держите запасной транспорт и помните про блокировки по IP.

Источники

Какой dest вы используете и по каким критериям выбирали? И замечали ли деградацию Reality под свежим DPI — что помогало: смена донора, IP или связка транспортов?