# VLESS（XTLS Vision Seed）

VLESS - это легкий транспортный протокол без сохранения состояния, который разделен на входящую и исходящую части и может служить мостом между клиентом и сервером Xray.

В отличие от [VMess](./vmess.md), VLESS не зависит от системного времени, аутентификация также осуществляется с помощью UUID.

## InboundConfigurationObject

`InboundConfigurationObject` соответствует элементу `settings` в [`InboundObject`](../inbound.md).

```json
{
  "inbounds": [
    {
      // ...
      "protocol": "vless",
      // [!code focus:17]
      "settings": {
        "users": [
          {
            "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
            "level": 0,
            "email": "love@xray.com",
            "flow": "xtls-rprx-vision",
            "reverse": {}
          }
        ],
        "decryption": "none",
        "fallbacks": [
          {
            "dest": 80
          }
        ]
      }
    }
  ]
}
```

> `users`: \[ [UserObject](#userobject) \]

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

Каждый элемент является пользователем [UserObject](#userobject).

> `decryption`: "none"

Настройки [шифрования VLESS](https://github.com/XTLS/Xray-core/pull/5067). Не может быть пустым, для отключения необходимо явно установить значение `"none"`.

Большинству пользователей рекомендуется использовать команду `xray vlessenc` для автоматической генерации этого поля, чтобы избежать ошибок. Подробные настройки ниже рекомендуются только для продвинутых пользователей.

::: details Подробная конфигурация
Его формат представляет собой строку подробных настроек, соединенных символом `.`. Например, `mlkem768x25519plus.native.600s.100-111-1111.75-0-111.50-0-3333.ptjHQxBQxTJ9MWr2cd5qWIflBSACHOevTauCQwa_71U`. В этом документе отдельная часть, разделенная точкой, называется блоком.

- Первый блок, это метод рукопожатия, в настоящее время он может быть только `mlkem768x25519plus`. Требуется, чтобы сервер и клиент совпадали.
- Второй блок, это метод шифрования, возможные варианты: `native`/`xorpub`/`random`, которые соответствуют: пакет данных в исходном формате / исходный формат + обфускация части открытого ключа / полностью случайное число (подобно VMESS/Shadowsocks). Требуется, чтобы сервер и клиент совпадали.
- Третий блок, это время действия тикета восстановления сеанса. Формат: `600s` или `100-500s`. Первый случай будет случайным образом выбирать время между указанной длительностью и ее половиной (например, `600s`=`300-600s`), второй случай позволяет вручную указать случайный диапазон.

Далее идет 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` (используя часть PrivateKey) или `./xray mlkem768` (используя часть Seed) и должен соответствовать клиенту. `mlkem768` является постквантовым алгоритмом, который может предотвратить (в будущем) взлом закрытого ключа квантовым компьютером и выдачу себя за сервер, если параметры клиента будут скомпрометированы. Этот параметр используется только для проверки, сам процесс рукопожатия в любом случае является постквантово-безопасным, и существующие зашифрованные данные не могут быть взломаны будущими квантовыми компьютерами.
:::

> `fallbacks`: \[ [FallbackObject](../features/fallback.md) \]

Массив, содержащий ряд конфигураций fallback-маршрутизации (необязательно).
Подробную информацию о настройке fallbacks см. в разделе [FallbackObject](../features/fallback.md#fallbacks-конфигурация).

### UserObject

```json
{
  "id": "5783a3e7-e373-51cd-8642-c83782b807c5",
  "level": 0,
  "email": "love@xray.com",
  "flow": "xtls-rprx-vision",
  "reverse": {}
}
```

> `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.

> `level`: number

Уровень пользователя, для подключения будет использоваться [локальная политика](../policy.md#levelpolicyobject), соответствующая этому уровню пользователя.

Значение level соответствует значению `level` в разделе [policy](../policy.md#policyobject). Если не указано, используется значение по умолчанию - 0.

> `email`: string

Адрес электронной почты пользователя, используется для разделения трафика разных пользователей (отображается в журналах, статистике).

> `flow`: string

Режим управления потоком, используется для выбора алгоритма XTLS.

В настоящее время для входящего протокола доступны следующие режимы управления потоком:

- Отсутствует `flow` или пустая строка: используется обычный TLS-прокси
- `xtls-rprx-vision`: используется новый режим XTLS, включает случайное заполнение внутреннего рукопожатия

XTLS доступен только в следующих комбинациях

- TCP+TLS/REALITY В этом случае зашифрованные данные копируются напрямую на низком уровне (если передается TLS 1.3).
- VLESS Encryption Нет ограничений на транспорт нижнего уровня; если транспорт не поддерживает прямое копирование (см. выше), то выполняется только проброс Encryption.

> `reverse`: struct

Упрощённая конфигурация обратного прокси VLESS.

Наличие этого параметра означает, что соединение от данного пользователя может быть использовано для установления туннеля обратного прокси, при этом обычное использование в качестве прямого прокси отключается.

```json
{
  "reverse": {
    "tag": "r-outbound"
  }
}
```

`tag` — это тег исходящего прокси для данного обратного прокси. Использование маршрутизации для направления трафика на этот исходящий прокси приведет к пересылке данных через обратный прокси в систему маршрутизации подключенного клиента (подробнее о конфигурации клиента см. в разделе об исходящих соединениях VLESS).

Когда имеется несколько различных подключений (возможно, с разных устройств), ядро будет случайным образом выбирать одно из них для каждого запроса на отправку данных через обратный прокси.

::: tip
Полное руководство: [Примеры обратного проксирования VLESS](../../document/level-2/vless_reverse.md)
:::