# VLESS（XTLS Vision Seed） VLESS - это легкий транспортный протокол без сохранения состояния, который разделен на входящую и исходящую части и может служить мостом между клиентом и сервером Xray. В отличие от [VMess](./vmess.md), VLESS не зависит от системного времени, аутентификация также осуществляется с помощью UUID. ## OutboundConfigurationObject ```json { "address": "example.com", "port": 443, "id": "5783a3e7-e373-51cd-8642-c83782b807c5", "encryption": "none", "flow": "xtls-rprx-vision", "level": 0, "reverse": {} } ``` > `address`: address Адрес сервера, указывающий на сервер, поддерживаются доменные имена, IPv4 и IPv6. > `port`: number Порт сервера, обычно тот же, что и порт, прослушиваемый сервером. > `id`: string Идентификатор пользователя VLESS, может быть любой строкой длиной менее 30 байт или допустимым UUID. Пользовательская строка и ее UUID-отображение эквивалентны, это означает, что вы можете использовать следующие способы записи id в файле конфигурации для идентификации одного и того же пользователя: - Напишите `"id": "Я люблю арбуз учителя 1314"`, - Или напишите `"id": "5783a3e7-e373-51cd-8642-c83782b807c5"` (этот UUID является UUID-отображением строки "Я люблю арбуз учителя 1314") Стандарт сопоставления описан в [VLESS UUID Mapping Standard: Mapping Custom Strings to a UUIDv5](https://github.com/XTLS/Xray-core/issues/158). Вы можете использовать команду `xray uuid -i "Пользовательская строка"` для генерации UUID, соответствующего пользовательской строке. Вы также можете использовать команду `xray uuid` для генерации случайного UUID. > `encryption`: "none" Настройки [шифрования VLESS](https://github.com/XTLS/Xray-core/pull/5067). Не может быть пустым, для отключения необходимо явно установить значение `"none"`. Большинству пользователей рекомендуется использовать `./xray vlessenc` для автоматической генерации этого поля, чтобы избежать ошибок. Подробные настройки ниже рекомендуются только для продвинутых пользователей. Его формат представляет собой строку подробных настроек, соединенных символом `.`. Например, `mlkem768x25519plus.native.0rtt.100-111-1111.75-0-111.50-0-3333.ptjHQxBQxTJ9MWr2cd5qWIflBSACHOevTauCQwa_71U`. В этом документе отдельная часть, разделенная точкой, называется блоком. - Первый блок, это метод рукопожатия, в настоящее время он может быть только `mlkem768x25519plus`. Требуется, чтобы сервер и клиент совпадали. - Второй блок, это метод шифрования, возможные варианты: `native`/`xorpub`/`random`, которые соответствуют: пакет данных в исходном формате / исходный формат + обфускация части открытого ключа / полностью случайное число (подобно VMESS/Shadowsocks). Требуется, чтобы сервер и клиент совпадали. - Третий блок, это восстановление сеанса. Выбор `0rtt` будет следовать настройкам сервера, пытаясь использовать ранее сгенерированный тикет для пропуска рукопожатия и быстрого подключения (может быть вручную отключено сервером). Выбор `1rtt` принудительно выполнит процесс рукопожатия 1 RTT. Здесь это отличается по смыслу от настроек сервера; подробности см. в настройках `decryption` для входящих соединений VLESS. Далее идет padding (заполнение). После установления соединения клиент отправляет некоторые "мусорные" данные для маскировки характеристик длины. Он не обязан совпадать с сервером (совпадающая часть для входящего трафика - это padding, отправляемый сервером в сторону клиента). Это переменная часть, формат: `padding.delay.padding`+`(.delay.padding)`\*n (можно вставлять несколько padding, но требуется, чтобы между двумя блоками padding обязательно был блок delay). Например, можно написать очень длинную строку `padding.delay.padding.delay.padding.delay.padding.delay.padding.delay.padding`. - Формат `padding`: `probability-min-max`, например, `100-111-1111`, что означает отправку padding длиной 111~1111 с вероятностью 100%. - Формат `delay` также `probability-min-max`, например, `75-0-111`, что означает ожидание 0~111 миллисекунд с вероятностью 75%. Первый блок padding имеет особые требования: вероятность должна быть 100%, а минимальная длина должна быть больше 0. Если padding отсутствует, ядро автоматически использует `100-111-1111.75-0-111.50-0-3333` в качестве настроек padding. Последний блок будет распознан ядром как параметр, используемый для аутентификации сервера. Он может быть сгенерирован с помощью `./xray x25519` (используя часть Password) или `./xray mlkem768` (используя часть Client) и должен соответствовать серверу. `mlkem768` является постквантовым алгоритмом, который может предотвратить (в будущем) компрометацию параметров клиента и использование квантового компьютера для взлома закрытого ключа и выдачи себя за сервер. Этот параметр используется только для проверки, сам процесс рукопожатия в любом случае является постквантово-безопасным, и существующие зашифрованные данные не могут быть взломаны будущими квантовыми компьютерами. > `flow`: string Режим управления потоком, используется для выбора алгоритма XTLS. В настоящее время для исходящего протокола доступны следующие режимы управления потоком: - Отсутствует `flow` или пустая строка: используется обычный TLS-прокси. - `xtls-rprx-vision`: используется новый режим XTLS, включает случайное заполнение внутреннего рукопожатия, поддерживает uTLS для имитации отпечатка клиента. - `xtls-rprx-vision-udp443`: аналогично `xtls-rprx-vision`, но разрешает UDP-трафик, направленный на порт 443. Кроме того, в настоящее время XTLS поддерживает только TCP+TLS/Reality. ::: tip О режимах управления потоком xtls-rprx-*-udp443 Когда XTLS в Xray-core включен, трафик, направленный на UDP-порт 443 (обычно QUIC), по умолчанию блокируется, чтобы приложение не использовало QUIC, а использовало TLS, чтобы XTLS действительно вступил в силу. Фактически, QUIC сам по себе не подходит для проксирования, поскольку QUIC имеет встроенные функции TCP, и когда он передается по протоколу VLESS как UDP-трафик, базовый протокол - TCP, что эквивалентно двум уровням TCP. Если блокировка не требуется, укажите `xtls-rprx-*-udp443` на стороне клиента, на стороне сервера оставляйте без изменений. ::: ::: tip О режиме Splice Splice - это функция, предоставляемая ядром Linux, где ядро системы напрямую пересылает TCP, минуя память Xray, что значительно сокращает количество операций копирования данных и переключения контекста процессора. Ограничения использования режима Splice: - Среда Linux. - Входящий протокол: `Dokodemo door`, `Socks`, `HTTP` и другие чистые TCP-соединения или другие входящие протоколы, использующие XTLS. - Исходящий протокол: VLESS + XTLS. - Обратите внимание, что при использовании протокола mKCP Splice не будет использоваться (да, хотя ошибки и нет, на самом деле он не используется). Кроме того, при использовании Splice отображение скорости сети будет запаздывать, это особенность, а не ошибка. При использовании режима Vision Splice будет включен автоматически, если выполнены вышеуказанные условия. ::: > `level`: number Уровень пользователя, для соединения будет использоваться [локальная политика](../policy.md#levelpolicyobject), соответствующая этому уровню пользователя. Значение level соответствует значению `level` в разделе [policy](../policy.md#policyobject). Если не указано, используется значение по умолчанию - 0. > `reverse`: struct Упрощённая конфигурация обратного прокси VLESS. Имеет то же назначение, что и встроенный в ядро универсальный обратный прокси, но с более простой настройкой. Наличие этого параметра означает, что данное исходящее соединение может быть использовано как исходящее соединение обратного прокси VLESS. Оно автоматически установит соединение с сервером для регистрации туннеля обратного прокси. Текущая запись ```json "reverse": { "tag": "r-inbound" } ``` `tag` — это тег входящего прокси для данного обратного прокси. Когда сервер отправляет запрос обратного прокси, он войдет в систему маршрутизации через входящее соединение с этим тегом. Используйте систему маршрутизации, чтобы направить его на нужное вам исходящее соединение. Используемый UUID должен совпадать с UUID, для которого на сервере также настроен `reverse` (подробнее см. в разделе о входящих соединениях VLESS).