# 🔐 VLESS Encryption: собственное постквантовое шифрование протокола ![[vless-encryption-header.webp]] > [!info] О чём заметка > Разбор **VLESS Encryption** (*vlessenc, шифрование VLESS, mlkem768x25519plus*) — слоя шифрования, который в сентябре 2025 года появился внутри самого протокола [[xray/vless|VLESS]] и снял его историческую зависимость от внешнего TLS. Здесь: что делает команда `xray vlessenc`, как читается длинная строка параметра, какая под этим криптография, что она защищает, а что нет, и главный практический вопрос — помогает ли она обходить блокировки в России и Китае (короткий ответ: напрямую нет, и [[xray/authors-v2ray-xray|RPRX]] — автор Xray-core, VLESS и XTLS — пишет об этом прямым текстом). Разбор слоёв стека и матрица совместимости «что с чем работает» — в [[xray/vless-stack-map|карте слоёв VLESS-стека]]. ## TL;DR - **VLESS Encryption** — отдельный шифрующий слой между протоколом VLESS и транспортом. Он не заменяет ни [[xray/reality|REALITY]], ни TLS, ни [[xray/xtls-vision|Vision]]: те прячут соединение от цензора, а он защищает содержимое от того, кто это соединение всё-таки видит (CDN, промежуточный узел, будущий квантовый компьютер). - Появился в PR [#5067](https://github.com/XTLS/Xray-core/pull/5067) автора RPRX (влит 28 августа 2025). Код вышел уже в пре-релизе v25.8.29, но практический минимум — **v25.9.5** от 5 сентября 2025: это первый стабильный релиз, и только в нём появился генератор `xray vlessenc`, а между двумя релизами формат дважды менялся несовместимо. - Внутри — **два независимых обмена ключами**: аутентификация сервера (X25519 **или** ML-KEM-768 — на выбор) и эфемерный гибрид ML-KEM-768 + X25519, который и даёт forward secrecy с постквантовой стойкостью. - Автор прямо пишет: **«это шифрование не предназначено для прямого прохода через стену»**. Внешний вид соединения оно не меняет, поэтому против блокировок по TLS-отпечатку, SNI, IP и белым спискам эффект нулевой. - Настоящие сценарии применения — **CDN** (спрятать UUID и адрес назначения от Cloudflare), **транзит через чужой узел**, **связка без внешнего TLS вообще**, а также постквантовая защита «сверх» той, что уже есть в REALITY. - Побочный, но важный для практики эффект: с VLESS Encryption **Vision перестал требовать прямого TCP** и стал доступен поверх [[xray/xhttp|XHTTP]], WebSocket и gRPC. - Главные ограничения: несовместим с `fallbacks` (Xray просто не стартует), не поддерживается ядром **sing-box** (а значит Hiddify, NekoBox, Karing), и требует обновлённого Xray-core на обоих концах. ## Проблема, которую решает: у VLESS никогда не было своего шифра Исторический факт, с которого всё начинается: **сам протокол VLESS ничего не шифрует**. Он передаёт версию, UUID пользователя, команду и адрес назначения открытым текстом и рассчитывает, что конфиденциальность обеспечит слой под ним — обычный TLS или [[xray/reality|REALITY]]. Это было сознательным решением: собственное шифрование [[protocols/vmess|VMess]] оказалось и медленнее, и заметнее для DPI, чем настоящий TLS 1.3, поэтому преемник от него отказался (подробнее — в разборе [[xray/vless|протокола VLESS]]). Пока туннель идёт напрямую «клиент → сервер», такая схема работает: внешний TLS шифрует всё, включая заголовок VLESS. Проблемы начинаются там, где между клиентом и сервером появляется кто-то, кто **легально расшифровывает внешний TLS**. Самый массовый такой случай — CDN. Когда VLESS заворачивают в WebSocket или [[xray/xhttp|XHTTP]] и пускают через Cloudflare, TLS-сессия обрывается на границе CDN: дальше до вашего сервера идёт отдельное соединение, а сама Cloudflare видит содержимое кадров. А в содержимом лежит открытый заголовок VLESS — **16 байт UUID, тип и адрес назначения, порт**, и следом весь проксируемый поток, включая SNI сайтов, на которые вы ходите. Формально это не «утечка» — вы сами выбрали пропускать трафик через посредника, — но фактически посредник знает и кто вы, и куда вы ходите. Проще говоря: внешний TLS защищает участок от вас до ближайшего узла, который этот TLS терминирует. Если такой узел — ваш собственный сервер, всё в порядке. Если это CDN, чужой релей или транзитный VPS, то до сервера ваш VLESS-заголовок доезжает в открытом виде. Второй сценарий — связка **вообще без внешнего TLS**: транзит по внутренней сети, где HTTP/TLS запрещены или бессмысленны, или окружения вроде иранского открытого HTTP. Раньше в такой конфигурации VLESS было просто нечем защитить. Третий — «harvest now, decrypt later» («сейчас запишем — потом расшифруем»): наблюдатель сохраняет зашифрованный трафик сегодня в расчёте расшифровать его будущим квантовым компьютером. VLESS Encryption закрывает все три, добавляя шифрование **внутри** протокола — независимо от того, есть ли что-то снаружи. ## Что это технически: ещё один conn поверх открытого VLESS Реализация устроена нарочито просто, и это стоит понимать, потому что из устройства следуют почти все ответы про совместимость. RPRX формулирует принцип так: шифрование — это «дополнительный слой соединения поверх открытого протокола VLESS, не связанный с внутренним протоколом, его легко реализовать и легко заменить». То есть в стеке появляется новая прослойка: ```text приложение (браузер, его собственный TLS до сайта) ↓ протокол VLESS (версия, UUID, адрес назначения) ↓ VLESS Encryption ← новый слой: шифрует всё, что выше ↓ транспорт: RAW TCP / XHTTP / WebSocket / gRPC / mKCP ↓ слой безопасности: TLS, REALITY или none ``` Из этой схемы следуют два неочевидных вывода. **Криптографической связи с внешним TLS/REALITY нет.** Ключи VLESS Encryption выводятся только из его собственных параметров: ни привязки к TLS-сессии (channel binding), ни экспортёра ключей в коде нет. Практический смысл: скомпрометированный CDN или подменённый сертификат снаружи **не ломают** конфиденциальность внутреннего слоя — это самодостаточный контур. Обратное тоже верно: внешний слой не подтверждает подлинность внутреннего и наоборот, слои просто ничего не знают друг о друге. **Ограничений на транспорт нет.** Слой навешивается на любое соединение, поэтому в документации Xray прямо записано: «VLESS Encryption: no underlying transport restrictions» — никаких ограничений на нижележащий транспорт. Именно отсюда взялось важное следствие про Vision (см. раздел ниже). ## Строка параметра: как читать `mlkem768x25519plus.native.600s...` Настройка задаётся двумя парными полями: `decryption` на сервере (в `settings` VLESS-входа) и `encryption` на клиенте (в outbound или в параметре `vless://`-ссылки). Оба поля **обязательны**: пустыми их оставить нельзя, отключение пишется явно — `"none"`. Значение — это блоки, разделённые точками: ```text сервер: метод.внешний_вид.срок_тикета[.padding.delay.padding...].ключ[.ключ...] клиент: метод.внешний_вид.0rtt|1rtt[.padding.delay.padding...].ключ[.ключ...] ``` Третий блок — единственное место, где сервер и клиент синтаксически расходятся: сервер задаёт **срок жизни тикета**, клиент — **режим возобновления сессии**. | Блок | Значения | Что означает | |---|---|---| | Метод хендшейка | `mlkem768x25519plus` | Пока единственный. Должен совпадать у сервера и клиента. Имя оставлено «с запасом»: `plus` намекает на возможность подключить другие обмены ключами позже | | Внешний вид (appearance) | `native` · `xorpub` · `random` | Как выглядит трафик на проводе — разбор ниже. Должен совпадать у обеих сторон | | Тикет (только сервер) | `600s` · `100-500s` · `0s` | `600s` = каждому тикету случайный срок от половины до полного, то есть 300–600 с. Диапазон задаётся явно. `0s` отключает тикеты — тогда каждое соединение идёт по полному 1-RTT | | Режим (только клиент) | `0rtt` · `1rtt` | Пытаться ли возобновлять сессию по тикету или всегда делать полный обмен | | Padding и delay | `вероятность-мин-макс` | Набивка и задержки хендшейка, необязательный блок. Например `100-111-1111` = со 100 % вероятностью добавить 111–1111 байт; `75-0-111` = с 75 % вероятностью подождать 0–111 мс | | Ключ(и) | base64url | Материал аутентификации. Несколько ключей подряд — это цепочка релеев | Если блок padding не указан, ядро подставляет свой набор — `100-111-1111.75-0-111.50-0-3333`. Свой набор писать можно, но с ограничениями на первую набивку: документация требует вероятность 100 % и длину «больше нуля», а код жёстче — **и минимум, и максимум первой набивки должны быть не меньше 35 байт** (сообщение об ошибке так и звучит: `first padding length must not be smaller than 35`). Суммарный padding при этом не превышает 65553 байт. Вот как выглядят реальные строки — именно то, что печатает генератор: ```text "decryption": "mlkem768x25519plus.native.600s.<X25519 PrivateKey>" "encryption": "mlkem768x25519plus.native.0rtt.<X25519 Password>" ``` > [!warning] В официальных примерах документации обе строки заканчиваются одинаковым ключом > На странице конфига inbound и outbound приведены примеры с одним и тем же base64-значением в конце. Это плейсхолдер, а не рабочая пара: на сервере в последнем блоке лежит **приватный** ключ X25519 (или seed ML-KEM-768), у клиента — **публичный** материал (X25519 Password или ML-KEM-768 Client). Копировать пример «как есть» в обе стороны нельзя. ## Криптография: два обмена ключами, а не один Здесь легко ошибиться, потому что в описаниях фигурирует «гибрид ML-KEM-768 + X25519», и его принимают за один механизм. На деле обменов **два, и они независимы** — как и в [[xray/reality|REALITY]]. **nfsKey — аутентификация сервера** (*not forward secret*, «не обладающий прямой секретностью»). Это тот самый ключ из последнего блока конфига. Он бывает двух видов, **на выбор, а не одновременно**: либо X25519 (32 байта, компактно, но не постквантово), либо ML-KEM-768 (клиентский ключ занимает 1184 байта — на килобайт длиннее, зато квантово-стойко). Его задача — доказать клиенту, что на том конце действительно ваш сервер. **pfsKey — эфемерный сессионный обмен** (*perfect forward secrecy*, «совершенная прямая секретность»). Вот он **всегда** гибридный: ML-KEM-768 и X25519 выполняются оба, их секреты склеиваются. Именно этот обмен делает записанный сегодня трафик нерасшифровываемым завтра. Дальше оба результата склеиваются в `unitedKey` (96 байт), из которого функция BLAKE3 выводит все рабочие ключи. Трафик шифруется AEAD-шифром — **AES-256-GCM или ChaCha20-Poly1305**, выбор автоматический: клиент смотрит, есть ли у процессора аппаратное ускорение AES, а сервер при неудачной расшифровке первого блока молча переключается на второй вариант. Вариантов со 128-битным ключом нет сознательно — раз конструкция целится в постквантовую стойкость, ключи только 256-битные. Проще говоря: один ключ отвечает за вопрос «тот ли это сервер», второй — за вопрос «сможет ли кто-нибудь расшифровать это через десять лет». Первый можно выбрать коротким, второй постквантов в любом случае. ### Первое соединение: 1-RTT RTT (*round-trip time*) — один полный обмен «туда-обратно». «1-RTT» означает, что перед передачей полезных данных нужен один такой круг: 1. Клиент отправляет 16 байт случайного IV и материал nfs-обмена, затем — уже зашифрованные на nfsKey длину, свой эфемерный публичный ключ ML-KEM-768+X25519 и набивку. 2. Сервер отвечает своим эфемерным публичным ключом (тоже под nfsKey), а под общим `unitedKey` — **тикет** (16 байт, в первых двух зашита длительность жизни) и набивку. 3. Дальше сразу идут данные внутреннего VLESS под `unitedKey` — отдельного «предъявления тикета» в первом соединении нет, клиент просто запоминает выданный тикет на будущее. ### Последующие соединения: 0-RTT Получив тикет, клиент может открывать новые соединения **без круга согласования**: он сразу предъявляет тикет и пишет данные, а сервер отвечает шестнадцатью случайными байтами и зашифрованным внутренним протоколом. Это заметно ускоряет открытие вкладок, где каждое TCP-соединение обычно требовало собственного рукопожатия. Тут есть тонкость, которую часто передают неверно: при 0-RTT переиспользуется **только эфемерный pfsKey**, а nfs-обмен выполняется заново в каждом соединении. Поэтому фактический ключ шифрования у каждого соединения свой — RPRX подчёркивает это как преимущество перед схемами, где возобновление сессии означает буквально тот же ключ. Срок жизни тикета задаёт сервер; генератор ставит `600s`, а рекомендация RPRX — около десяти минут. Захардкоженного значения по умолчанию нет. ### Защита от повторов без синхронизации часов У [[protocols/vmess|VMess]] защита от replay-атак (повторной отправки перехваченного соединения) строилась на временных метках, из-за чего клиент и сервер должны были иметь синхронные часы — расхождение ломало связь. Здесь механика другая: по тикету за одно обращение находится сессия, а сам повтор ловится вторым множеством — сервер помнит уже виденные nfsKey внутри этой сессии и на совпадении возвращает `replay detected`. Часы не нужны вообще. Долгосрочный повтор отсекается двумя способами: тикет истекает, а при перезапуске Xray все тикеты становятся недействительными — состояние намеренно не сохраняется на диск. ## Что защищено, а что нет Это самая ценная часть для практики, потому что вокруг неё больше всего преувеличений. **Утечка приватного ключа сервера** не позволяет расшифровать ранее записанный трафик — за это отвечает эфемерный обмен. Но **позволяет провести MITM будущих соединений**: злоумышленник с этим ключом может выдать себя за сервер. Оговорка про гранулярность: прямая секретность действует с точностью до окна тикета (до десяти минут), потому что pfsKey всё это время живёт в памяти сервера. Компрометация памяти работающего процесса — это не то же самое, что утечка ключа из конфига. **Утечка клиентского конфига** (той самой `vless://`-ссылки) не даёт расшифровать ни прошлый, ни будущий трафик и не даёт возможности MITM. Причина простая: в клиентском конфиге лежит только публичный материал сервера. Это принципиальное отличие от [[protocols/shadowsocks|Shadowsocks]] и VMess, где ключ общий: там, заполучив конфиг с вашего телефона, можно расшифровать трафик и с вашего ноутбука. Но три вещи утечка конфига по-прежнему выдаёт полностью, и об этом стоит помнить всем, кто раздаёт ключи из публичных каналов: - **доступ к прокси** — утёкшая ссылка это рабочий клиент, чужой человек просто пользуется вашим сервером; - **адрес и порт сервера** — то есть цель для блокировки и активного зондирования; - при варианте аутентификации на X25519 — **отложенный квантовый риск**: имея конфиг, будущий квантовый компьютер сможет восстановить приватный ключ сервера и выдать себя за него. Вариант с ML-KEM-768 этого не допускает ценой лишнего килобайта в конфиге. ## Три внешних вида трафика: native, xorpub, random Параметр `appearance` (второй блок) определяет, как хендшейк и записи выглядят на проводе. - **`native`** — «как есть». Публичные ключи в хендшейке идут в открытом виде, а каждая запись данных предваряется пятибайтовым заголовком `17 03 03 LL LL` — тем самым, что у записи TLS 1.3. Это сделано не для маскировки соединения целиком, а чтобы наблюдатель не заметил момент, когда Vision переходит в сквозной режим передачи. - **`xorpub`** — то же самое, но публичные ключи в хендшейке замаскированы XOR-гаммой. Важно понимать границу: гамма выводится из **публичного** ключа сервера, то есть это обфускация, а не конфиденциальность — в коде это помечено комментарием прямым текстом. - **`random`** — вдобавок XOR-ит пятибайтовые заголовки записей потоковым шифром AES-256-CTR, и на проводе не остаётся никакой структуры. Лишних байтов он не добавляет — заголовок есть во всех трёх режимах, — а дополнительной работы получается около **0,06 %** от объёма потока: это те самые 5 байт на запись размером до 8 КБ, которые приходится прогонять через шифр. > [!warning] У `random` есть неочевидная цена: он выключает splice > Режимы `native` и `xorpub` оставляют соединение «пробиваемым» — [[xray/xtls-vision|Vision]] может уйти в zero-copy передачу через ядро (`splice`). Режим `random` оборачивает соединение в отдельный XOR-слой, и ядерный splice становится невозможен: данные обязаны пройти через процесс. Для нагруженного сервера это заметная разница, а выигрыш в незаметности, как показано ниже, спорный. > > Важная оговорка, которая часто теряется: «пробиваемость» `native` и `xorpub` работает **только когда под шифрованием лежит голый TCP без внешнего слоя безопасности**. Если под VLESS Encryption лежат TLS или REALITY, ядро запрещает splice — под шифрованием уже не сырой сокет. > > И теряется не только он. В коде стоит защита «avoids double penetration»: сняв слой VLESS Encryption, Vision **перестаёт разворачивать внешний TLS или REALITY** и пишет прямо в них. Значит, на классической схеме `TCP + REALITY + Vision` включение VLESS Encryption отнимает сразу две вещи — ядерный splice и сквозной проход без второго шифрования: REALITY снова шифрует проксируемый поток, чего до этого не делал. Экономия остаётся только на AEAD самого слоя Encryption. Полная таблица условий — в [[xray/vless-stack-map|карте слоёв]]. ## Как включить Ключи не собирают вручную — для этого есть генератор. Появился он не одновременно с самой функцией, а неделей позже, отдельным PR #5078, и попал в релиз v25.9.5: ```bash xray vlessenc ``` Команда печатает **две готовые пары** сразу: одну с аутентификацией на X25519, вторую на ML-KEM-768, с подписью «выберите одну, не смешивайте; эфемерный обмен постквантов в любом случае». Каждая пара — это строка `decryption` для сервера и парная `encryption` для клиента. Рядом живут более низкоуровневые команды: `xray x25519` (пара X25519, используется и в REALITY), `xray mlkem768` (постквантовая пара для VLESS Encryption) и `xray mldsa65` — последняя относится к постквантовым подписям [[xray/reality|REALITY]], а не к шифрованию VLESS, и их часто путают. Дальше строка `decryption` кладётся в `settings` VLESS-входа на сервере, а `encryption` — в outbound клиента либо в параметр `encryption=` share-ссылки. Формат ссылок при этом менять не пришлось: параметр `encryption` зарезервирован в стандарте `vless://` (обсуждение [#716](https://github.com/XTLS/Xray-core/discussions/716)) ещё пять лет назад, допустимые значения — `none` либо `mlkem768x25519...`, а пустой строкой он быть не может. > [!tip] `flow` при этом лучше не выключать > Частый вопрос: раз VLESS Encryption сам шифрует, нужен ли ещё `flow=xtls-rprx-vision`? В сентябре 2025 его задали RPRX напрямую — в контексте связки с XHTTP, — и ответ был односложным: «рекомендуется включать». Логика в том же PR: XTLS избавляет от повторного шифрования уже зашифрованного потока, то есть без него вы платите за двойную работу. Пустой `flow` вдобавок означает, что набивка внутреннего рукопожатия не применяется вовсе. > [!note] Генерируется один раз на вход, а не на пользователя > Пара `decryption`/`encryption` описывает **криптографию входа**, а не конкретного клиента — пользователи по-прежнему различаются своими UUID. Панелям и ботам, которые выдают ключи, не нужно вызывать `xray vlessenc` при создании каждого пользователя: строка генерируется один раз при создании входа и затем подставляется во все ссылки этого входа. ## Ограничения и совместимость **`fallbacks` использовать нельзя.** Если в VLESS-входе одновременно заданы `fallbacks` и непустой `decryption`, Xray **не запускается**: конфиг не проходит сборку с ошибкой `"fallbacks" can not be used together with "decryption"`. Это не «работает хуже», а полный отказ старта, что для боевого сервера означает падение всех входов из этого конфига. Практическое следствие: вход с маскировкой под настоящий сайт через nginx придётся либо перестроить, либо развести с зашифрованным входом по разным портам. **Поддержка клиентами разделилась по ядрам, а не по названиям приложений.** | Ядро | Поддержка VLESS Encryption | Что это за клиенты | |---|---|---| | Xray-core v25.9.5+ | Да | v2rayN, v2rayNG, v2RayTun, Happ, Streisand, V2Box, OneXray | | mihomo v1.19.13+ | Да, поле `encryption` | [[Clash/02-mihomo\|mihomo]] и клиенты на нём | | sing-box (upstream) | **Нет** (проверено на v1.13.16 и v1.14.0-beta.8, август 2026) | Hiddify, NekoBox for Android | | [[sing-box/sing-box-extended\|sing-box-extended]] | Да, и клиент, и сервер | сборки на этом форке | | Форк ядра KaringX | В коде ядра клиентская часть есть (с 26 мая 2026), но подтверждения, что приложение её использует, нет | Karing | | Собственные ядра | Shadowrocket — нет по состоянию на конец 2025; остальные проверять | Shadowrocket, Stash, Loon | Ключевое здесь — **версия ядра, а не версия приложения**. Параметр `encryption` графические клиенты на Xray протаскивали из ссылки в конфиг задолго до появления шифрования, потому что поле зарезервировано в стандарте ссылок давно; работать или нет решает бинарник Xray внутри. Отсюда типичная ловушка: приложение обновилось, а ядро в нём осталось прошлогодним. Мультиядерные клиенты (Throne, NekoRay на десктопе) поддерживают шифрование на профилях, идущих через Xray, и не поддерживают на профилях через sing-box. Любопытная деталь: mihomo получил поддержку **раньше** самого Xray — 27 августа 2025, портировав код прямо из непринятого ещё PR. > [!danger] Лишнее поле `encryption` может уронить всю подписку в upstream sing-box > Оригинальный sing-box от SagerNet разбирает конфигурацию строго: разбор идёт с запретом неизвестных полей, поэтому незнакомое поле ломает **весь** JSON-документ, а не один узел. Единственный профиль с VLESS Encryption в общей подписке способен оставить пользователя вообще без профилей. Две оговорки: это касается подписок, которые отдаются **в формате конфига sing-box** (клиент, самостоятельно разбирающий `vless://`-ссылку, лишний параметр просто отбросит), и это свойство любого неизвестного поля, а не конкретно `encryption`. > > **Форки ведут себя иначе, и их надо разделять.** [[sing-box/sing-box-extended|sing-box-extended]] от shtorm-7 поддерживает VLESS Encryption **полноценно, с обеих сторон**: в его `option/vless.go` есть и клиентское поле `encryption` в outbound, и серверное `decryption` в inbound, плюс отдельный пакет `protocol/vless/encryption`. То есть на нём можно и подключаться к зашифрованному входу, и поднимать такой вход самому. Поддержка появилась в феврале 2026 (первый стабильный релиз с ней — `v1.13.11-extended-2.0.0` от 29 апреля 2026), а код происходит из Xray-core через промежуточный форк starifly/sing-box. > > С Karing сложнее: в его форке ядра клиентское поле действительно добавили 26 мая 2026, но в списке изменений приложения об этом ни слова, а профильный запрос на эту функцию мейнтейнер закрыл со словами «функции ядра — в sing-box, Karing занимается интерфейсом». Так что записывать Karing в поддерживающие рано. > > На подписку всё это влияет напрямую: конфиг с полем `encryption` extended-сборка съест нормально, а upstream — нет. Осторожность нужна с Hiddify и NekoBox for Android (там upstream), а не со всем, что называется sing-box. **Старый клиент против нового сервера не «покажет ошибку», а зависнет или молча оборвётся.** Поведение зависит от типа ключа. При аутентификации X25519 сервер ждёт 48 байт, разбирает обычный VLESS-заголовок как хендшейк и мгновенно рвёт соединение — в логах видны ошибки расшифровки, для пользователя это выглядит как «подключилось и сразу отвалилось». При аутентификации ML-KEM-768 сервер ждёт 1104 байта, которых старый клиент не пришлёт, — соединение просто висит до таймаута, **и в логе сервера при этом не появляется ничего**. Второй случай особенно неприятен при диагностике: жалоба «не работает» не подкреплена никакими записями. **`security: "none"` разрешён не всегда.** С версии v26.7.11 (июль 2026) Xray отказывается собирать конфигурацию, где VLESS идёт без транспортного шифрования на неприватный адрес: `vless without TLS or other encryption is prohibited unless the server address is a private IP or domain`. Включённый VLESS Encryption снимает этот запрет — он официально признан заменой транспортного TLS для транзитных и non-TLS сценариев. Две границы этого запрета стоит знать точно. Во-первых, проверка применяется **только к исходящим соединениям** — то есть падает конфиг клиента, а серверный вход с `security: none` по-прежнему стартует. Во-вторых, v26.7.11 и более поздние сборки помечены как пре-релизы: последний релиз со стабильной меткой на 6 августа 2026 — v26.3.27 от 27 марта 2026, и в нём этой проверки ещё нет. > [!note] Этот запрет — часть объявленного плана, и важно понимать его границы > RPRX формулирует этот курс дважды. 28 августа 2025 года: «постепенно ограничивать по умолчанию незашифрованный трафик в публичной сети необходимо — это даёт пользователям гарантию безопасности и защищает от случайной ошибки в конфиге; кто точно понимает, что делает, сможет включить обход сам, а новичок просто не получит незашифрованный узел». 23 декабря 2025 года — уже с этапами: «первый шаг — добавить предупреждение, в том числе для Shadowsocks, VMess и insecure; второй шаг — блокировать незашифрованный трафик в публичной сети, обойти смогут только конфигурации, которые нельзя расшарить ссылкой». > > Мишень здесь — **`security: none` вместе с `encryption: none`**, то есть VLESS, у которого нет вообще никакой защиты. Обычный `encryption=none` поверх TLS или [[xray/reality|REALITY]] под это не подпадает и остаётся официально поддерживаемой схемой: документация прямо описывает два равноправных варианта — внешний защищённый транспорт **либо** VLESS Encryption. Подтверждённой даты, когда `encryption=none` перестанет работать в связке с TLS/REALITY, не существует. ## Главный вопрос: помогает ли это против ТСПУ и GFW Короткий ответ: **само по себе — нет**, и это позиция [[xray/authors-v2ray-xray|RPRX]], автора и самого VLESS, и этого шифрования, а не осторожная оценка со стороны. В описании PR #5067 стоит прямая фраза: «особо обратите внимание, это шифрование **не предназначено для того, чтобы вы напрямую проходили стену**; подобные протоколы давно не годятся для прямого прохода — для этого следует использовать REALITY, XHTTP, Vision». В сравнительной таблице того же PR есть строка «годится для прямого обхода», и напротив VLESS Encryption там стоит **❌**, а напротив VLESS+REALITY/TLS — ✔️. Механика объясняет, почему так, лучше ссылки на авторитет. VLESS Encryption лежит **под** протоколом и **над** транспортом. Всё, на что смотрит российский ТСПУ (Технические Средства Противодействия Угрозам) или китайский GFW снаружи, — TLS-отпечаток клиента, SNI, IP и ASN сервера, число соединений и их тайминги — определяется внешним слоем и от включения внутреннего шифрования не меняется. Соответственно против блокировок по фингерпринту, по подсети и по белым спискам (а именно так устроены зафиксированные в России схемы, см. [[VLESS/dpi-tls-june-2026|разбор схемы ограничений]]) эффект нулевой. Точности ради: собственный внешний вид у VLESS Encryption **есть** — это те самые `native`, `xorpub` и `random` плюс настраиваемая набивка рукопожатия. Он просто расположен внутри туннеля, поэтому виден лишь тому, кто уже снял внешний слой. Единственный сценарий, где эта настройка выходит наружу, — конфигурация вообще без внешнего TLS. Любопытно, что сам RPRX в ноябре 2025 года, разбирая российские блокировки, предлагает вложить VLESS Encryption с настраиваемой набивкой внутрь REALITY именно как способ поменять признаки трафика без правки кода — то есть рассматривает его и как рычаг влияния на форму, хотя от прямого обхода отговаривает. ### Про Китай и режим `random`: распространённая ошибка Логика «включу `random`, трафик станет случайным и неотличимым» в китайских условиях работает против пользователя. GFW с 2021 года применяет классификатор **полностью зашифрованного трафика**: он смотрит на первый пакет с данными и **пропускает** соединение, если срабатывает хотя бы одно из пяти исключений — доля единичных битов выходит за пределы 3,4–4,6 на байт; первые шесть или больше байт печатные; больше половины байтов печатные; есть цепочка длиннее двадцати подряд идущих печатных байт; начало похоже на TLS или HTTP. Случайные данные не удовлетворяют ни одному условию — и попадают под блокировку (работа USENIX Security 2023, [PDF](https://www.usenix.org/system/files/usenixsecurity23-wu-mingshi.pdf)). Сам RPRX это подтверждает: «GFW уже занёс полностью случайный внешний вид в чёрный список». > [!warning] `native` тоже не спасает от этого классификатора > Соблазнительно решить, что раз `native` «менее случаен», он безопаснее. Но классификатор GFW анализирует **только первый пакет с данными**, а первый пакет VLESS Encryption во всех трёх режимах начинается с 16 байт случайного IV и материала обмена ключами. TLS-подобный заголовок `17 03 03` в начало первого пакета не попадает: в режиме 1-RTT он появляется только со следующей записи, а в 0-RTT лежит внутри того же пакета, но уже за материалом рукопожатия — примерно на сотом байте. Правило, дающее освобождение по сигнатуре TLS, смотрит именно на начало, а на общую энтропию пять байт не влияют. Поэтому по энтропии `native`, `xorpub` и `random` для классификатора выглядят одинаково. Это вывод из кода и опубликованного алгоритма, а не результат измерения: опубликованных замеров VLESS Encryption против GFW нет. Масштаб угрозы стоит понимать точно, потому что его легко и преувеличить, и преуменьшить. Блокировка применяется **вероятностно — примерно к 26 % соединений, идущих к уже затронутым диапазонам адресов**, а не к четверти всего трафика: если ваш сервер попал под правило, повторные попытки быстро добьют оставшееся. Действует это только на TCP-трафик из Китая наружу и только для части адресов — заметно затронуты ASN хостеров, а Cloudflare и Akamai нет. Блокируется тройка «клиент — сервер — порт» на 120 или 180 секунд. Основные измерения относятся к ноябрю 2021 — сентябрю 2022, но авторы отдельно отмечают, что 16 февраля 2023 перепроверили эксперименты и все правила детекта подтвердились. Данных за 2026 год нет. ### Что реально даёт VLESS Encryption пользователю из России Три конкретных выигрыша, каждый со своей оговоркой. **Vision стал доступен на любом транспорте.** Раньше выбор был жёстким: либо `xtls-rprx-vision` на прямом TCP, либо CDN-транспорт вроде XHTTP и WebSocket — но без Vision. Документация Xray теперь описывает две ситуации, в которых XTLS доступен: `TCP + TLS/REALITY` и `VLESS Encryption` — причём во втором случае «ограничений на нижележащий транспорт нет». Оговорка: на не-TCP транспорте пропадает ядерный splice — но не весь выигрыш по скорости. Документация формулирует это так: если нижний транспорт не TCP, ядро «пробивает только слой Encryption, экономя его накладные расходы»; на TCP дополнительно пробует splice. То есть один полный проход шифрования по всему потоку снимается в любом случае. Подробности комбинаций — в [[xray/vless-stack-map|карте слоёв]]. **CDN больше не читает, кого и куда вы проксируете.** Это ровно тот сценарий, ради которого шифрование и создавалось: «применимо к CDN (избежать раскрытия UUID и проксируемого SNI), к транзиту, к non-TLS». Оговорка обязательная: CDN по-прежнему видит адрес вашего сервера, объёмы и тайминги, и располагает собственными эвристиками детекта туннелей — то есть корректно говорить «CDN не может прочитать содержимое», а не «CDN видит только шум». **Постквантовая защита сверх той, что уже есть.** Здесь важно не преувеличить: утверждение «REALITY не постквантов» на 2026 год неверно. REALITY поддерживает гибридный обмен X25519MLKEM768 (если его поддерживает сайт-донор) и с июля 2025 — опциональную постквантовую подпись ML-DSA-65. Так что VLESS Encryption даёт не закрытие дыры, а **эшелонирование**: его преимущество в том, что сам обмен ключами зашифрован (у TLS и REALITY key share лежит на проводе открытым), и в том, что защита не зависит от того, поддерживает ли ваш донор нужные алгоритмы. **Задокументированных случаев блокировки именно VLESS Encryption нет** — как и подтверждений, что связка с ним живёт дольше. Проверка форума net4people/bbs и русскоязычных публикаций за 2026 год не дала ни одного наблюдения в ту или другую сторону. Любые утверждения вида «с vlessenc не блокируют» на сегодня — домыслы. ## Как мигрировать существующий парк ключей Отдельная практическая тема: включить VLESS Encryption на новом входе просто, а вот перевести сотню уже выданных ключей — операция с реальным риском. Ключевое свойство, из которого всё следует: **уже скопированная пользователем строка `vless://` не изменится сама**. После серверной миграции старая ссылка перестаёт соответствовать входу, и клиент обязан заново получить ссылку — из бота, панели или обновлением подписки. Отсюда порядок, который снимает большинство граблей: - [ ] Разделить входы на три группы: совместимые (можно мигрировать), с `fallbacks` (мигрировать нельзя, Xray не стартует) и legacy, которые решено не трогать. - [ ] Не менять UUID пользователей, адрес, порт, SNI и параметры REALITY — миграция должна затрагивать только `decryption` на сервере и `encryption` в ссылках, иначе отладка превращается в гадание. - [ ] Проверить, что идентификаторы входов не вычисляются из изменяемых полей. Если панель или бот выводит числовой ID из тега входа, правка тега порвёт связи между базой, ключами и клиентами внутри Xray — признак совместимости лучше хранить отдельной пометкой, а тег оставить прежним. - [ ] Снять свежий план прямо перед применением и проверить, что состав клиентов не изменился с момента планирования, — если ключи выдаются параллельно, устаревший план затрёт новых пользователей. - [ ] Сделать резервную копию базы **до** изменений и проверить её целостность, а не просто скопировать файл. - [ ] После применения сверить сохранённую конфигурацию с реально загруженным состоянием Xray: перезапуск не должен потерять ни одного клиента. - [ ] Проверить не только конфиг, но и живое подключение существующим пользовательским ключом — через публичный адрес и порт, до реального HTTPS-ресурса. - [ ] Предупредить пользователей, что нужно переимпортировать ссылку, и отдельно — что владельцам клиентов на sing-box переходить нельзя. > [!example] Как это выглядит на практике > Опыт живой миграции трёх боевых входов (89 ключей, август 2026): связка `TCP + REALITY + VLESS Encryption + flow=xtls-rprx-vision` работает — реальные подключения существующими ключами прошли на всех трёх узлах, состав клиентов после перезапуска Xray совпал с сохранённым до единицы. А вот вход с `gRPC + TLS` и настоящими `fallbacks` пришлось оставить в старом формате: совместить его текущую схему с `decryption` без перестройки транспорта нельзя. ## Стоит ли включать > [!tip] Практический вывод > Включать имеет смысл там, где есть **посредник или отсутствует внешний TLS**: связки через CDN, транзит через чужой узел, каскады, конфигурации с `security: none`. Для классической схемы `TCP + REALITY + Vision` напрямую с клиента на свой сервер VLESS Encryption не обязателен: конфиденциальность там уже обеспечена, а прибавка — эшелонированная постквантовая защита ценой совместимости и, что менее очевидно, ценой двух вещей сразу: ядерный splice на этой схеме перестанет включаться, а REALITY снова начнёт шифровать проксируемый поток, который до этого проходил насквозь. > > Чего делать не стоит — массово менять `encryption=none` на существующих ключах без подготовки. Клиенты на sing-box отвалятся полностью, а входы с `fallbacks` вообще не поднимутся. Правильный порядок — отдельный новый вход или проверенная поэтапная миграция по чек-листу выше. ## 📚 См. также - [[xray/vless-stack-map|Слои VLESS-стека: кто за что отвечает]] — карта и матрица совместимости: что с чем работает, где включается splice, где Vision - [[xray/vless|Протокол VLESS]] — устройство протокола, формат заголовка, `flow`, `fallbacks`, XUDP - [[xray/xtls-vision|XTLS и Vision]] — что такое `flow`, паддинг рукопожатия и прямое копирование - [[xray/reality|REALITY]] — маскировка под чужой сайт, постквантовые X25519MLKEM768 и ML-DSA-65 - [[xray/xhttp|XHTTP]] — транспорт через CDN, ради которого шифрование в основном и нужно - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY]] — по каким признакам блокируют в России и почему шифрование содержимого на это не влияет - [[protocols/vmess|VMess]] — предшественник со встроенным шифрованием и синхронизацией часов - [[protocols/00-overview|Обзор протоколов]] — карта: какой протокол какую задачу решает - [[xray/authors-v2ray-xray|Кто стоит за V2Ray и Xray]] — про RPRX, автора VLESS, XTLS, REALITY и этого шифрования - 🔗 [PR #5067 «VLESS Post-Quantum Encryption»](https://github.com/XTLS/Xray-core/pull/5067) — первоисточник, описание от RPRX - 🔗 [config: inbounds/vless](https://xtls.github.io/en/config/inbounds/vless.html) · [outbounds/vless](https://xtls.github.io/en/config/outbounds/vless.html) — синтаксис `decryption`/`encryption` - 🔗 [xray vlessenc и другие команды](https://xtls.github.io/en/document/command.html) — генератор пар ключей - 🔗 [How the Great Firewall of China Detects and Blocks Fully Encrypted Traffic](https://www.usenix.org/system/files/usenixsecurity23-wu-mingshi.pdf) — USENIX Security 2023, эвристики против случайного трафика --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/vless-encryption.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).