vless://, QR-кодах, подписках и клиентах на базе Xray-core, sing-box или mihomo.VLESS Reality обычно пишут как одно название, но технически это два разных слоя. VLESS отвечает за прокси-протокол и идентификацию пользователя между клиентом и сервером. REALITY отвечает за транспортную безопасность и внешний вид TLS-рукопожатия. Поэтому корректнее читать профиль не как «протокол Reality», а как схему: VLESS + REALITY + transport + flow + DNS/routing.
В Xray такая связка часто выглядит как protocol=vless и streamSettings.security=reality. В share link это обычно превращается в строку вида vless://uuid@example.com:443?security=reality&type=tcp&sni=www.example.org&fp=chrome&pbk=...&sid=.... Если один параметр не совпадает с сервером, профиль может не импортироваться, подключаться без трафика или падать на рукопожатии.
#Почему появился REALITY
У классической схемы VLESS + TLS есть понятная модель: сервер показывает настоящий сертификат для своего домена, а клиент проверяет этот сертификат. Это удобно, но у такой схемы есть следы: отдельный домен, сертификат, параметры TLS-рукопожатия, поведение сервера при неправильном запросе и реакция на активное зондирование. В сетях с DPI этого может быть достаточно, чтобы выделять подозрительные прокси-серверы.
REALITY в Xray появился как другой подход к транспортной защите. Он модифицирует TLS-рукопожатие и использует параметры, которые позволяют клиенту и серверу узнавать друг друга без обычной выдачи собственного публичного сертификата прокси. Для постороннего наблюдателя соединение должно быть ближе к обычному HTTPS-трафику, но это не означает магическую невидимость: важны выбранный target, SNI, IP, fingerprint, поведение клиента, fallback и сеть провайдера.
Документация Project X описывает REALITY как технологию Xray на транспортном уровне. В том же разделе указано, что transport должен совпадать на обеих сторонах: если сервер ждет RAW/TCP, а клиент пытается WebSocket или gRPC, соединение не установится. Поэтому выражение «у меня VLESS Reality» всегда нужно дополнять деталями: RAW или XHTTP, включен ли xtls-rprx-vision, какой SNI, какой fingerprint и какая версия core используется.
#Как читать профиль по слоям
Самый безопасный способ понять VLESS Reality — разложить ссылку на уровни. Не нужно начинать с ручной правки: сначала определите, что за что отвечает. В большинстве клиентских интерфейсов эти поля разбросаны по вкладкам Protocol, Transport, TLS/REALITY, Advanced и Routing, но в конфигурации они все должны описывать одну согласованную схему.
- Протокол: VLESS. Он задает UUID или другой id пользователя, иногда flow и encryption.
- Адрес: server, address, host и port. Это точка, куда клиент реально подключается.
- Transport: чаще RAW/TCP, но возможны XHTTP, WebSocket, gRPC и другие варианты, если сервер настроен так же.
- Security: REALITY. Это не то же самое, что TLS с обычным сертификатом.
- Имена: SNI или serverName должны соответствовать списку serverNames на сервере и выбранной маскирующей цели.
- Ключи: public key на клиенте должен соответствовать private key на сервере.
- Идентификатор REALITY: short ID помогает серверу отличать допустимые попытки от посторонних.
- Отпечаток: fingerprint задает, какой TLS ClientHello эмулировать через uTLS, например chrome.
VLESS
Переходите к настройке VLESS
Если вы уже понимаете, как работает VLESS, получите данные для подключения и добавьте их в совместимое приложение.
#Ключевые параметры
| Параметр | Где встречается | Что означает | Типичная ошибка |
|---|---|---|---|
id, UUID | VLESS user | Идентификатор пользователя для аутентификации VLESS. | Скопировали не тот UUID, потеряли символ или импортировали старый профиль. |
encryption | VLESS | Настройка шифрования уровня VLESS; в классических ссылках часто none. | Считают none признаком полностью открытого соединения, хотя REALITY находится ниже. |
flow | VLESS/XTLS | Режим управления потоком, чаще xtls-rprx-vision или пустое значение. | Клиент не поддерживает Vision или flow не совпадает с сервером. |
security=reality | streamSettings | Включает REALITY как транспортную защиту. | Меняют на tls или none, не меняя серверную схему. |
sni, serverName | REALITY/TLS | Имя, которое участвует в TLS ClientHello и должно попадать в допустимые serverNames. | Исправляют SNI на домен сервера или случайный популярный сайт. |
pbk, public key | REALITY client | Публичный ключ REALITY, связанный с приватным ключом сервера. | Берут public key от другого inbound или путают его с UUID. |
sid, short ID | REALITY client/server | Короткий hex-идентификатор; на сервере он должен быть в массиве shortIds. | Добавляют пробел, меняют регистр/длину или оставляют пустым, когда сервер ждет конкретное значение. |
fp, fingerprint | uTLS | Отпечаток TLS ClientHello: chrome, firefox, safari, ios, android и другие варианты. | Клиент игнорирует поле, использует unsafe/go tls или не поддерживает выбранный fingerprint. |
spx, spiderX | REALITY client | Дополнительный путь для поведения fallback/маскировки в некоторых профилях. | Удаляют как «неважный хвост», после чего сервер отличает клиента иначе. |
#Public key, short ID, SNI и fingerprint простыми словами
Public key в клиентской ссылке — это не пароль пользователя и не сертификат сайта. Он нужен, чтобы клиент мог проверить REALITY-сторону сервера. На сервере хранится соответствующий private key, а клиенту передают только public key. Если public key не от той конфигурации, рукопожатие не станет правильным, даже если адрес, порт и UUID верные.
Short ID — короткая метка REALITY. В серверной конфигурации это массив shortIds, а в клиентской ссылке часто параметр sid. Он может быть пустым только если сервер это допускает. В остальных случаях пустой или неправильный sid выглядит как загадочная ошибка подключения: сервер доступен, порт открыт, но REALITY-проверка не проходит.
SNI или serverName — имя, которое клиент показывает в TLS ClientHello. В обычном TLS оно связано с проверкой сертификата. В REALITY оно также участвует в выбранной маскировочной схеме и должно соответствовать серверному списку serverNames. Нельзя считать SNI декоративной подписью: это рабочий параметр рукопожатия.
Fingerprint — способ сделать TLS ClientHello похожим на выбранный класс клиентов. Project X использует uTLS и по умолчанию часто встречается chrome. Но fingerprint работает только если клиент и используемое ядро действительно поддерживают эту функцию. Старый клиент может показать поле в интерфейсе, но собрать другой handshake или проигнорировать часть параметров.
#Совместимость клиентов
Для VLESS Reality мало поддержки VLESS как протокола. Клиент должен поддерживать REALITY, нужный transport, flow, uTLS fingerprint и формат импортируемой ссылки. Поэтому старое приложение может успешно добавить обычный VLESS + TLS, но не понять VLESS + REALITY + Vision или новые варианты transport вроде XHTTP.
На практике совместимость зависит от ядра внутри приложения. Клиенты на Xray-core обычно ближе всего к терминологии Project X. Клиенты на sing-box используют свою структуру TLS/REALITY-полей, но тоже могут поддерживать VLESS и Reality. Клиенты на mihomo/Clash Meta читают похожие параметры через YAML-схему, где Reality-поля могут называться иначе. В GUI это скрыто за кнопкой импорта, но при ошибках важно знать, какое ядро сейчас выбрано.
- Windows, macOS, Linux: часто используют v2rayN, NekoRay, Hiddify, Happ или другие клиенты с Xray/sing-box ядром.
- Android: встречаются v2rayNG, NekoBox, Hiddify и другие клиенты; важна версия core внутри APK.
- iOS и iPadOS: поддержка зависит от конкретного App Store-клиента и его ядра; не все приложения одинаково импортируют Reality-ссылки.
- Router/OpenWrt: конфигурации часто конвертируются в sing-box, Xray или mihomo; ошибка маппинга поля может сломать рабочую ссылку.
- Подписки: один и тот же узел может прийти в формате v2rayN, Clash/Mihomo или sing-box; конвертер должен сохранять
pbk,sid,sni,fpиflow.
#Безопасность и ограничения
VLESS Reality не делает пользователя анонимным автоматически. Сервер все равно является стороной доверия: он видит технические метаданные подключений и управляет выходом в интернет. Сайты видят IP-адрес выходного сервера, а приложение на устройстве управляет DNS, маршрутизацией и TUN/system proxy режимом. Если DNS идет мимо туннеля или часть приложений исключена из маршрута, слово Reality это не исправит.
Не стоит отключать проверки или менять fingerprint только потому, что профиль не подключился. В документации Project X рядом с TLS-параметрами отдельно предупреждается об опасности небезопасных режимов. Для пользователя практическое правило проще: если готовый профиль не работает, сначала сверяйте версию клиента и поля с источником профиля, а не превращайте его в набор случайных настроек из разных инструкций.
Также важно не публиковать ссылку целиком. В VLESS Reality-ссылке секретными или чувствительными являются UUID, адрес, порт, public key, short ID, SNI, токен подписки и иногда имя профиля, если оно раскрывает провайдера или назначение узла. Скриншот настроек клиента может быть почти равен публикации доступа.
#Частые ошибки
- Смешали VLESS и REALITY. Пользователь меняет только протокол, но забывает, что REALITY находится в security/transport settings.
- Неверный transport. Сервер ожидает RAW/TCP, а клиент импортировал WebSocket, gRPC или XHTTP.
- Старое ядро. Приложение знает VLESS, но bundled core не поддерживает нужный REALITY, flow или fingerprint.
- Испорченная ссылка. Мессенджер обрезал символы после
?, заменил&или потерял фрагмент после#. - Не тот public key. Взяли
pbkиз соседнего профиля, панели или старой конфигурации. - Short ID не совпадает. На сервере разрешен один список
shortIds, а клиент отправляет другое значение. - SNI выбран по популярной инструкции. Случайный домен из гайда не обязан подходить вашему серверу и target.
- Fingerprint не применяется. Клиент показывает
chrome, но выбранное ядро или TLS engine не поддерживает uTLS/REALITY. - Flow включен без поддержки.
xtls-rprx-visionдолжен быть согласован с сервером и клиентом. - Проблема не в VLESS. Подключение установлено, но сайты не открываются из-за DNS, routing, IPv6, firewall, TUN или блокировки конкретного выходного IP.
#Troubleshooting: что проверять по симптомам
| Симптом | Вероятная причина | Проверка |
|---|---|---|
| Профиль не импортируется | Ссылка обрезана или клиент не понимает формат | Скопируйте строку полностью, проверьте начало vless://, наличие security=reality и обновите клиент. |
| Сразу отказ или authentication failed | UUID/id не совпадает с сервером | Сверьте UUID с источником профиля; не заменяйте его на новый случайный UUID. |
| Handshake failed, connection reset | Ошибка REALITY-параметров | Проверьте pbk, sid, sni, fp, spx и версию core. |
| Timeout | Порт, IP, firewall, transport или сеть провайдера | Сравните другую сеть, проверьте порт и убедитесь, что transport совпадает с сервером. |
| Работает на Wi-Fi, но не на мобильной сети | Разная фильтрация, IPv6, DNS, MTU или блокировка IP-подсети | Не меняйте все поля сразу; сравните тот же профиль в другом клиенте и сети. |
| Статус connected есть, сайты не открываются | DNS/routing/TUN, а не REALITY-handshake | Проверьте системный proxy или TUN, DNS-серверы, правила маршрутизации и исключения приложений. |
| После обновления подписки узел сломался | Конвертер потерял параметры или серверная панель изменила схему | Сравните старый и новый профиль: pbk, sid, sni, fp, flow, type. |
Главный принцип диагностики: сначала восстановите исходную связку, затем меняйте по одному параметру и фиксируйте результат. VLESS Reality чувствителен к согласованности полей. Если профиль получен из подписки или панели, чаще всего быстрее обновить или перевыпустить профиль у источника, чем чинить ссылку вручную.
#Краткий вывод
VLESS Reality — практичная и распространенная схема Xray, но ее нельзя понимать как одну кнопку или универсальную гарантию обхода фильтрации. VLESS задает протокол и пользователя, REALITY задает транспортную защиту, SNI и fingerprint влияют на TLS-рукопожатие, public key и short ID участвуют в проверке, а клиентская совместимость зависит от версии core. Если держать эти уровни отдельно, ошибки становятся намного понятнее.