VLESS, REALITY и XTLS Vision — три разных компонента одного соединения Xray: VLESS задаёт лёгкий прокси-протокол и поля идентификации клиента; REALITY относится к уровню защиты транспорта; XTLS Vision является режимом потока VLESS, который выбирается значением flow и меняет обработку подходящего трафика. Удобное название «VLESS Reality» обозначает комбинацию, но скрывает границы между уровнями.［1］［2］

Полное руководство по VPN объясняет модель туннеля, маршрутов и наблюдателей. Здесь мы разбираем только роли компонентов. Мы не называем всю комбинацию единым стандартизованным VPN-протоколом и не даём инструкций по обходу правил сети.

Ключевые выводы

VLESS, REALITY и Vision дополняют друг друга, а не конкурируют как три VPN-протокола.

VLESS переносит прокси-запрос и идентификатор клиента, но не определяет все свойства транспорта и защиты.

REALITY отвечает за конкретную схему защищённого транспортного рукопожатия и проверки сервера.

xtls-rprx-vision — режим flow для VLESS; совместимые стороны должны согласовать его.

Маршруты, DNS, способ транспортировки и охват системного туннеля задаются отдельно.

Почему эти три названия часто употребляют вместе?

Конфигурация Xray собирается из нескольких уровней. Пользователь может выбрать входящее или исходящее соединение VLESS, включить REALITY в параметрах защиты потока (stream security) и указать xtls-rprx-vision в поле VLESS flow. В подписке или ответе поддержки такую связку нередко сокращают до «VLESS REALITY» либо «VLESS Reality Vision». Это узнаваемая комбинация, а не новый компонент вместо трёх исходных.

Разделение важно по практической причине. Один и тот же VLESS можно использовать с разными параметрами потока. REALITY не занимается только распознаванием пользователя VLESS. Vision не выбирает адрес сервера, нижележащий транспорт, DNS, правила маршрутизации или приложения, которые попадут в соединение.

Документация Project X проводит те же границы. На странице VLESS описаны клиенты и поле flow. Страница транспорта разделяет прокси-протокол, способ транспортировки, защиту транспорта и низкоуровневые настройки сокета. Поэтому конфигурационное дерево надёжнее короткого составного названия.［1］［2］

За что отвечает VLESS?

Project X описывает VLESS как лёгкий транспортный протокол без состояния. В конфигурации Xray он определяет разрешённых клиентов, переносит запрос к назначению и содержит поля для согласования дополнительного поведения потока. На входе сервера обычно перечисляются идентификаторы клиентов, а исходящее соединение клиента указывает сервер и подходящий идентификатор.［1］

Идентификатор часто выглядит как UUID. Это не то же самое, что долговременный закрытый ключ, однако относиться к нему нужно как к чувствительному материалу доступа. Публикация может позволить другому человеку попытаться использовать сервис и усложнить расследование. Закрывайте UUID на снимках экрана, в журналах и публичных вопросах.

Сам VLESS не описывает весь защищённый путь. Рядом с ним находятся параметры потока (stream settings), где выбираются способ транспортировки и режим защиты транспорта. VLESS также не создаёт автоматически системный VPN-интерфейс. Трафик может входить через локальный прокси, TUN, маршрутизатор или другой слой интеграции — это находится за пределами формата сообщений VLESS.

В актуальной документации присутствуют и дополнительные параметры VLESS Encryption. Поэтому устаревшая формула «VLESS просто не шифрует» слишком груба. Корректнее сказать, что обязанности VLESS и уровня защиты потока разделены, а фактическая защита определяется полной конфигурацией для конкретной версии.［1］

За что отвечает REALITY?

REALITY — механизм защиты транспорта в экосистеме Xray/XTLS. Он участвует в рукопожатии, проверяет ожидаемый сервис с помощью настроенного криптографического материала и формирует внешнее соединение с поведением, совместимым с TLS. В документации Project X REALITY находится рядом с другими вариантами защиты потока (stream security), а не внутри списка клиентов VLESS.［2］

Такое расположение объясняет набор полей в конфигурации. Сервер хранит закрытый материал REALITY и разрешённые параметры рукопожатия. Клиенту нужны соответствующие открытые данные и значения, выбирающие ожидаемое поведение сервера. Имя сервера, короткий идентификатор и параметры отпечатка (fingerprint) относятся к контексту рукопожатия, а не заменяют UUID VLESS.

REALITY не решает, какое конечное назначение запросит пользователь через VLESS, какие приложения попадут в локальный клиент и будет ли операционная система направлять весь трафик в туннель. Он также не делает любое соединение неотличимым от обычного просмотра сайтов. Внешние адреса, время, размеры пакетов, особенности реализации и последующее поведение потока остаются отдельными наблюдаемыми признаками. Статья о TLS-фингерпринтинге объясняет, почему TLS-подобное рукопожатие не гарантирует невидимость.

Мы намеренно не рассматриваем выбор цели рукопожатия и настройку параметров против средств анализа. Такие решения связаны с полномочиями, безопасностью и эксплуатацией и должны приниматься в контролируемом процессе развёртывания.

За что отвечает XTLS Vision?

XTLS Vision обычно выбирается значением VLESS flow — xtls-rprx-vision. Поле сообщает совместимым сторонам, какой режим обработки использовать. Следовательно, Vision не является ни идентификатором клиента, ни рукопожатием REALITY. Это согласованное поведение потока внутри конфигурации VLESS.［1］

Иногда Vision ошибочно называют отдельным транспортом. Из-за этого появляются несовместимые комбинации и неверная диагностика. Способ транспортировки, например RAW, XHTTP или gRPC, задаётся в другой части параметров потока. Совместимость REALITY и Vision следует проверять по актуальной версии Xray и полной комбинации, а не по одному знакомому слову.［1］［2］

Vision также не определяет область маршрутизации. Локальный клиент может предоставить отдельным приложениям SOCKS- или HTTP-прокси. Другой слой может направить трафик устройства через TUN. Одна и та же серверная связка поэтому способна участвовать в разных пользовательских сетевых моделях.

При поиске несовпадения flow сохраняйте точное строковое значение и версии обеих сторон, но удаляйте идентификаторы и ключи. Фразы «Vision включён» недостаточно, чтобы доказать согласование одинакового поддерживаемого режима.

Как сочетаются VLESS, REALITY и XTLS Vision?

Удобнее двигаться от приложения вниз. Приложение создаёт запрос. Локальные маршруты или прокси-интеграция решают, попадёт ли он в Xray. VLESS описывает прокси-запрос и клиента. Vision может изменить обработку подходящего потока. REALITY защищает транспорт. Выбранный способ транспорта переносит поток, а IP-сеть доставляет пакеты до конечной точки.

Уровень или решение	Обычная обязанность	Чего он не определяет
Приложение и локальная маршрутизация	Выбор трафика для клиента	Удалённый VLESS ID или ключи REALITY
VLESS	Идентификатор клиента и запрос к назначению	Общесистемные маршруты и все свойства защиты
XTLS Vision flow	Обработка совместимого трафика VLESS	Адрес сервера, DNS и способ транспорта
REALITY	Защищённое рукопожатие и контекст проверки сервера	Выбор приложения и итоговую маршрутную политику
Способ транспорта	Перенос потока в поддерживаемом формате	Авторизацию пользователя VLESS
IP-сеть	Доставку до настроенной конечной точки	Успешное рукопожатие и рабочий прокси-маршрут

Номера на схеме соответствуют строкам таблицы; стрелки показывают порядок ролей, а не вложенность пакетов. Реализация может объединять операции, но для диагностики полезно относить каждую настройку к её документированной роли.

Что находится вне этой связки?

DNS задаётся отдельно. Он может разрешать имя внешнего сервера, локально или удалённо разрешать конечные назначения и следовать собственным правилам. Успешное соединение VLESS и REALITY не доказывает правильность DNS после рукопожатия.

Маршрутизация также отдельна. Правила Xray могут отправлять разные назначения или входящие теги в разные исходящие подключения (outbounds). У операционной системы остаются собственные маршруты, политика межсетевого экрана и TUN. Аутентификация может завершиться, хотя приложение пойдёт не по тому пути.

Отдельны учётная запись и политика продукта. Общая документация Xray не подтверждает, какие функции предоставляет коммерческое VPN-приложение. Продукт может использовать иной протокол, скрывать компоненты за автоматическим режимом или вообще не поддерживать эту связку.

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

Как читать конфигурацию и не смешивать уровни?

Сначала найдите входящее или исходящее соединение VLESS. Запишите только нечувствительную структуру: роль клиента или сервера, название протокола и наличие flow. Затем откройте параметры потока и отдельно запишите способ транспорта и режим защиты. После этого проверьте открытые параметры REALITY, не перенося в общие заметки закрытые ключи, UUID, short ID и полный файл.

Далее проверьте вход трафика и маршруты. Определите, используется ли локальный прокси или TUN, какие правила выбирают исходящее подключение и где выполняется DNS. Тогда ошибка маршрутизации после рукопожатия не будет ошибочно названа проблемой REALITY.

Сверяйте обе стороны с документацией именно установленных версий. Скопированный профиль может содержать поле, которое изменилось, переместилось или не поддерживается выбранной комбинацией. Меняйте один уровень за раз и храните возвратную копию через разрешённый канал конфигурации.

Как оценивать сервис с учётом этих компонентов?

Если вы оцениваете AethoVPN, а не собираете этот стек сами, установите клиент, выберите в приложении локацию сервера или рекомендованный узел и оцените подключение в своих сетях. Эти результаты описывают сервис, а не его устройство: публичные материалы AethoVPN не называют ни одного из разобранных здесь компонентов, поэтому не переносите поля VLESS, REALITY или Vision из этой статьи в его клиент. Начните 3-дневный бесплатный пробный период, чтобы провести такую оценку.

Если продукт предлагает автоматический режим, пользовательское название может не раскрывать внутренние компоненты. Не выводите скрытую поддержку протоколов из отдельной строки журнала или сходства с открытой конфигурацией. О доступности конкретных возможностей узнавайте из актуальной документации продукта или через его поддержку.

Итоги

VLESS задаёт прокси-протокол, идентификатор клиента, запрос назначения и согласование flow.
REALITY находится на уровне защиты потока и имеет собственные параметры рукопожатия и проверки.
XTLS Vision — режим потока VLESS, а не другое название REALITY или транспорта.
Локальный захват трафика, DNS, маршруты, транспорт и политика продукта остаются отдельными уровнями.
Используйте документацию для конкретной версии и очищенные доказательства, а не воспринимайте «VLESS Reality» как неделимый протокол.

Часто задаваемые вопросы (FAQ)

VLESS и REALITY — одно и то же?

Нет. VLESS задаёт прокси-протокол и контекст идентификации клиента, а REALITY настраивается как защита транспорта. Их можно использовать вместе, но поле одного уровня не заменяет настройку другого.

XTLS Vision — ещё один транспортный протокол?

Не в этой конфигурационной модели. xtls-rprx-vision является значением VLESS flow, а способ транспорта выбирается отдельно в параметрах потока.

Шифрует ли VLESS трафик самостоятельно?

По одному названию ответить нельзя. Актуальная документация VLESS содержит дополнительные поля шифрования (encryption), а защита потока настраивается отдельно. Оценивайте полную конфигурацию соответствующей версии.

Направляет ли REALITY трафик всех приложений в VPN?

Нет. Выбор приложений и системные маршруты находятся вне рукопожатия REALITY. Локальный прокси или TUN сначала должен направить трафик в нужное исходящее подключение.

Будет ли Vision работать при разных значениях flow на клиенте и сервере?

Несовпадающий или неподдерживаемый режим может помешать ожидаемому соединению. Сравните точные значения, транспорт, защиту и версии обеих сторон.

Доказывает ли успешное рукопожатие REALITY, что сайты откроются?

Нет. После него всё ещё могут отказать авторизация VLESS, обработка назначения, DNS, маршруты, правила межсетевого экрана или серверная пересылка.

Является ли «VLESS Reality» стандартизованным VPN-протоколом?

Обычно так называют комбинацию развёртывания. Здесь мы разделяем её на уровни; вопрос классификации всей связки требует отдельного анализа и не должен подменяться сокращением.

Отказ от ответственности: Материал предназначен для законного изучения, администрирования и диагностики. Соблюдайте применимое право и правила используемой сети.

Источники:

Project X, "VLESS inbound configuration": https://github.com/XTLS/Xray-docs-next/blob/main/docs/en/config/inbounds/vless.md
Project X, "Transport configuration": https://xtls.github.io/en/config/transport.html

Sources checked 11 сентября 2026 г.

Рекомендуемые статьи:

Что такое VLESS, REALITY и XTLS Vision?