mirrors/Xray-docs-next
1
0
Fork 0
mirror of https://github.com/XTLS/Xray-docs-next.git synced 2025-12-15 09:55:33 +08:00
Code Issues Packages Projects Releases Wiki Activity

RU VLESS: Add VLESS encryption

Browse Source
This commit is contained in:
iambabyninja
2025-10-19 13:34:41 +03:00
parent 092edc0f93
commit 25cd499b6f
2 changed files with 33 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

25
docs/ru/config/inbounds/vless.md
View File

@@ -1,9 +1,5 @@
# VLESS（XTLS Vision Seed）
::: danger
VLESS не предусматривает встроенного шифрования, поэтому обязательным условием для его использования является наличие надежного канала, такого как TLS или REALITY.
:::
VLESS - это легкий транспортный протокол без сохранения состояния, который разделен на входящую и исходящую части и может служить мостом между клиентом и сервером Xray.
В отличие от [VMess](./vmess.md), VLESS не зависит от системного времени, аутентификация также осуществляется с помощью UUID.
@@ -38,11 +34,24 @@ VLESS - это легкий транспортный протокол без с
> `decryption`: "none"
На данный момент необходимо указать `"none"`, значение не может быть пустым.
Если значение decryption установлено неверно, при использовании Xray или -test будет выдано сообщение об ошибке.
Настройки [шифрования VLESS](https://github.com/XTLS/Xray-core/pull/5067). Не может быть пустым, для отключения необходимо явно установить значение `"none"`.
Обратите внимание, что здесь используется decryption, на том же уровне, что и clients.
Расположение decryption и encryption в протоколе vmess отличается, потому что, если используется дополнительный уровень шифрования, сервер должен сначала расшифровать данные, чтобы узнать, какой это пользователь.
Большинству пользователей рекомендуется использовать `./xray vlessenc` для автоматической генерации этого поля, чтобы избежать ошибок. Подробные настройки ниже рекомендуются только для продвинутых пользователей.
Его формат представляет собой строку подробных настроек, соединенных символом `.`. Например, `mlkem768x25519plus.native.0rtt.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) \]

23
docs/ru/config/outbounds/vless.md
View File

@@ -1,9 +1,5 @@
# VLESS（XTLS Vision Seed）
::: danger
VLESS не предусматривает встроенного шифрования, поэтому обязательным условием для его использования является наличие надежного канала, такого как TLS или REALITY.
:::
VLESS - это легкий транспортный протокол без сохранения состояния, который разделен на входящую и исходящую части и может служить мостом между клиентом и сервером Xray.
В отличие от [VMess](./vmess.md), VLESS не зависит от системного времени, аутентификация также осуществляется с помощью UUID.
@@ -89,11 +85,24 @@ VLESS - это легкий транспортный протокол без с
> `encryption`: "none"
Необходимо указать `"none"`, значение не может быть пустым.
Настройки [шифрования VLESS](https://github.com/XTLS/Xray-core/pull/5067). Не может быть пустым, для отключения необходимо явно установить значение `"none"`.
Это требование призвано напомнить пользователю об отсутствии шифрования, а также предотвратить ошибки пользователей при вводе имени атрибута или его расположения в будущем, когда будут доступны методы шифрования.
Большинству пользователей рекомендуется использовать `./xray vlessenc` для автоматической генерации этого поля, чтобы избежать ошибок. Подробные настройки ниже рекомендуются только для продвинутых пользователей.
Если значение encryption установлено неверно, при использовании Xray или -test будет выдано сообщение об ошибке.
Его формат представляет собой строку подробных настроек, соединенных символом `.`. Например, `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