# 🔷 Протокол VLESS: устройство и возможности > [!info] О чём заметка > Подробный разбор **протокола VLESS** — транспортного прокси-протокола ядра [[xray/project-x|Xray-core]], на котором сегодня строится большинство серверов обхода блокировок. Здесь — как устроен протокол на уровне байтов, что умеет поле `flow`, зачем нужны fallbacks, XUDP и новое встроенное пост-квантовое шифрование. История самого проекта и технологий REALITY/XTLS — в обзорной заметке [[xray/project-x|Project X (Xray-core)]]; как современный DPI детектит связку VLESS+REALITY — в [[VLESS/dpi-tls-june-2026|разборе схемы ограничений июня 2026]]. ## TL;DR - **VLESS** — облегчённый (stateless) прокси-протокол, преемник **VMess**. Придуман разработчиком RPRX внутри проекта [[xray/project-x|Project X]]. - Ключевая идея: **сам протокол ничего не шифрует и не маскирует**. Аутентификация — по одному UUID, а конфиденциальность делегируется внешнему слою (TLS, [[xray/reality|REALITY]]) и flow-контролю ([[xray/xtls-vision|XTLS-Vision]]). - Убрана времязависимая аутентификация VMess: не нужна синхронизация часов, протокол проще и быстрее. - Умеет **flow** (`xtls-rprx-vision` против детекта TLS-in-TLS), **fallbacks** (маскировка под настоящий сайт и защита от зондирования), **XUDP** (полноценный UDP с Full Cone NAT), работает поверх TCP/XHTTP/WebSocket/gRPC/mKCP. - С сентября 2025 (релиз v25.9.5) у VLESS появилось **собственное пост-квантовое шифрование** (ML-KEM-768 + X25519) — оно снимает жёсткое требование внешнего TLS и защищает от расшифровки «сейчас запишем — потом расшифруем». ## Что такое VLESS и чем он отличается от VMess VLESS расшифровывается неформально как «VMess Less» — «VMess без лишнего». Это транспортный протокол: он отвечает только за то, чтобы аутентифицировать клиента и сказать серверу, куда переслать трафик. Всё остальное — шифрование, маскировку под легитимный трафик, обход DPI — берут на себя слои ниже. У предшественника, **VMess**, был собственный жёсткий криптографический контур с проверкой времени: клиент и сервер должны были иметь синхронизированные часы (расхождение более ±90 секунд ломало соединение), плюс отдельная «аутентификация ответа». Это усложняло протокол и создавало проблемы на устройствах с плывущими часами. VLESS от этого отказался. Вместо временной метки — простое поле версии в начале запроса, вместо встроенного шифрования — расчёт на внешний TLS/REALITY. Проще говоря: VMess пытался быть «самодостаточной крепостью» со своим шифрованием и часами, а VLESS — это лёгкий «скелет», который сознательно отдаёт защиту специализированным слоям, которые делают её лучше (настоящий TLS 1.3 неотличим от обычного HTTPS, а собственное шифрование VMess — нет). ## Формат протокола на уровне байтов Разбор основан на [dev-документации VLESS](https://xtls.github.io/en/development/protocols/vless.html) и коде `proxy/vless/encoding` в [Xray-core](https://github.com/XTLS/Xray-core/tree/main/proxy/vless/encoding). Заголовок **запроса** идёт последовательно: | Поле | Размер | Что это | |---|---|---| | Version | 1 байт | Версия протокола (0 в тестовых сборках, 1 в релизах) | | UUID | 16 байт | Идентификатор пользователя; сервер сверяет его при каждом соединении | | Addons Length + Addons | 1 байт + N | Protobuf-данные переменной длины; несут, в частности, значение `flow`. Если addons не нужны — длина 0, накладных расходов нет | | Command | 1 байт | Команда: TCP / UDP / MUX | | Port | 2 байта | Порт назначения | | Address Type + Address | 1 байт + N | Тип адреса (IPv4 / домен / IPv6) и сам адрес | Заголовок **ответа** минимален: версия (совпадает с запросом), затем Addons и данные. > [!note] Почему это важно для маскировки > Заголовок VLESS предельно компактен и не содержит ничего криптографически «шумного» — никаких временных меток или хешей, выдающих протокол. Всё, что видит DPI снаружи, — это уже обёрнутый TLS/REALITY-трафик. Сам заголовок VLESS появляется только *внутри* зашифрованного канала, где его не видно. ## Поле flow: XTLS-Vision против детекта TLS-in-TLS `flow` — поле в addons, которое включает режим XTLS flow-control. Именно оно решает проблему двойного шифрования «TLS внутри TLS» (подробный разбор самой идеи XTLS, механики паддинга/splice и разграничения терминов — в заметке [[xray/xtls-vision|XTLS и Vision]]). Актуальные значения ([config outbounds/vless](https://xtls.github.io/en/config/outbounds/vless.html)): - **пусто / нет поля** — обычное проксирование через TLS без XTLS. Простое и совместимое, но паттерн «TLS-in-TLS» детектируем. - **`xtls-rprx-vision`** — текущий рекомендуемый режим. Добавляет случайный паддинг во внутреннее рукопожатие (inner handshake random padding), размывая характерные длины TLS-записей вложенного соединения. Дополнительно перехватывает UDP на порт 443 (QUIC), заставляя браузер откатываться на обычный HTTPS поверх TCP — иначе часть трафика ушла бы мимо туннеля. - **`xtls-rprx-vision-udp443`** — то же самое, но **без** перехвата UDP 443: QUIC пропускается как есть. > [!warning] Старые значения flow удалены > Ранние режимы `xtls-rprx-origin`, `xtls-rprx-direct`, `xtls-rprx-splice` **устарели и удалены**. Примерно с версии 1.7.5 они выдавали предупреждение, а с 1.8.0 `direct` объявлен deprecated в пользу Vision. Современный Xray-core при загрузке конфига со старым flow падает с ошибкой вроде `Please use VLESS flow "xtls-rprx-vision" with TLS or REALITY`. Точную привязку к версиям стоит сверять по [Releases](https://github.com/XTLS/Xray-core/releases). Механизм `splice` (zero-copy передача через ядро Linux) при этом никуда не делся — он остался внутренней оптимизацией Vision, а не отдельным значением flow. XTLS-Vision работает в связках TCP+TLS или TCP+[[xray/reality|REALITY]]; для TLS 1.3 он умеет напрямую копировать уже зашифрованные данные без повторного шифрования. ## Fallbacks: маскировка под настоящий сайт **Fallback** — механизм VLESS inbound, который перенаправляет «неправильный» трафик на другое назначение (обычно на настоящий веб-сервер вроде nginx). Требует связки TCP+TLS. Источник: [features/fallback](https://xtls.github.io/en/config/features/fallback.html). Зачем это нужно: - **Защита от активного зондирования (active probing).** Цензор отправляет на подозрительный сервер обычный HTTP/TLS-запрос, чтобы проверить, прокси это или нет. Без fallback такой запрос ни на что не похож; с fallback он уходит на реальный сайт, и зонд получает нормальную веб-страницу — сервер выглядит как обычный HTTPS-хост. - **Разделение одного порта.** На 443-м порту одновременно живут и прокси, и настоящий сайт. Xray «подглядывает» первый пакет и выбирает наиболее точное правило `FallbackObject` по полям: `name` (сопоставление с TLS SNI), `alpn` (фактически согласованный ALPN), `path` (HTTP PATH, должен начинаться с `/`), `dest` (куда переслать), `xver` (отправлять ли PROXY protocol, чтобы бэкенд видел реальный IP клиента). Правило выбирается по точности совпадения, а не по порядку в конфиге. > [!note] Fallbacks несовместимы с новым шифрованием > `fallbacks` нельзя использовать одновременно с параметрами `decryption`/`encryption` встроенного VLESS Encryption (см. ниже) — придётся выбрать что-то одно. ## Транспорты и слой безопасности VLESS — это только логика протокола; он работает поверх транспортного слоя (`type`/`network`): - **TCP (RAW)** — базовый транспорт; **единственный**, где работает XTLS-Vision. - **[[xray/xhttp|XHTTP]]** — новый HTTP-транспорт (пришёл на смену старому h2/SplitHTTP), дружит с CDN. - **WebSocket (ws)** — совместим с CDN и обычными веб-серверами. - **gRPC** — параметр `serviceName`. - **mKCP (kcp)** — на базе UDP, с коррекцией ошибок (FEC). - **HTTPUpgrade** — лёгкий транспорт на HTTP-Upgrade. Слой безопасности (`security`): **`none`**, **`tls`** или **`reality`**. На практике VLESS почти всегда используют с `tls` или `reality`; `none` допустимо только для доверенного/приватного назначения или когда включено собственное VLESS Encryption. ## XUDP и Mux.Cool: полноценный UDP По умолчанию проксировать UDP (игры, звонки, P2P) сложно из-за NAT. **XUDP** — расширение мультиплексора Mux.Cool, которое даёт **Full Cone NAT** поверх VLESS. Источники: [Discussion #252](https://github.com/XTLS/Xray-core/discussions/252), [Mux.Cool spec](https://xtls.github.io/en/development/protocols/muxcool.html). - XUDP появился в **Xray-core v1.3.0**: агрегирует UDP-потоки в туннель и переносит адрес/порт внутри Mux-фрейма. При v1.3.0+ на обоих концах VLESS по умолчанию работает в режиме Full Cone через публичный IP сервера, независимо от локального NAT клиента. - **Global ID / настоящий Full Cone** (примерно с v1.8.1): даже после разрыва TCP (например при смене сети) сервер сохраняет тот же исходящий порт для UDP-источника — критично для P2P-приложений. - **UDP 443 (QUIC):** параметр `xudpProxyUDP443` (`skip`/`allow`/`reject`) управляет судьбой QUIC-трафика. Часто его намеренно не пускают в туннель — Vision вынуждает браузер использовать HTTPS поверх TCP, что уменьшает утечки и нагрузку. Проще говоря: без XUDP UDP-приложения за прокси часто ломались из-за строгого NAT; XUDP делает так, что все они видят «открытый» интернет через публичный IP сервера. ## VLESS Encryption: встроенное пост-квантовое шифрование (2025) Долгое время у VLESS не было **никакого** собственного шифрования — только внешний TLS/REALITY. Это меняет **VLESS Encryption**, добавленный в [PR #5067](https://github.com/XTLS/Xray-core/pull/5067) (автор RPRX, влит в конце августа 2025) и вышедший в релизе **Xray-core v25.9.5**. Официальное описание — [xraycore.org/en/misc/vless-encryption](https://xraycore.org/en/misc/vless-encryption/). Что это даёт: - **Собственное шифрование без внешнего TLS.** VLESS может работать при `security: none`, сохраняя конфиденциальность и forward secrecy. Формат называется `mlkem768x25519plus`. - **Пост-квантовая стойкость.** Обмен ключами — гибрид **ML-KEM-768** (пост-квантовый механизм инкапсуляции ключа) **+ X25519**. Даже если сегодня записать весь трафик, будущий квантовый компьютер его не расшифрует — это защита от атаки «harvest now, decrypt later» («сейчас запишем — потом расшифруем»). - **Режимы внешнего вида (appearance):** - **`native`** — базовый, поддерживает splice в XTLS-Vision. - **`xorpub`** — XOR-ит публичный ключ, чтобы рукопожатие выглядело как случайные байты; работает с XHTTP и другими транспортами. - **`random`** — полностью случайный вид, минимальная нагрузка на ресурсы. - **Развёртывание.** Достаточно обновить Xray-core и сгенерировать ключи (`./xray x25519`, `./xray mlkem768`, готовый конфиг — `./xray vlessenc`). Параметр `encryption` в схеме share-ссылок зарезервирован давно, так что менять формат ссылок не нужно. > [!warning] Молодость и оговорки > VLESS Encryption появился только в сентябре 2025 года — поддержка в сторонних GUI-клиентах и независимый криптоаудит на момент июля 2026 ещё догоняют. Кроме того, `encryption`/`decryption` несовместимы с `fallbacks`. ## Формат ссылок vless:// Стандарт share-ссылок ([Discussion #716](https://github.com/XTLS/Xray-core/discussions/716)): ``` vless://<uuid>@<host>:<port>?<параметры>#<название> ``` Значения параметров URL-кодируются. Ключевые параметры: - `type` — транспорт: `tcp`, `kcp`, `ws`, `http`, `grpc`, `httpupgrade`, `xhttp`. - `security` — `none` / `tls` / `reality`. - `encryption` — по умолчанию `none`; может нести `mlkem768x25519plus...`. - `flow` — например `xtls-rprx-vision`. - REALITY/TLS: `sni`, `fp` (fingerprint, по умолчанию `chrome`), `pbk` (публичный ключ REALITY, обязателен), `sid` (short ID). - Транспортные: `path`, `host`, `serviceName`. ## Ограничения и критика > [!warning] Что стоит держать в голове > - **Без внешнего TLS/REALITY (или без VLESS Encryption) трафик уязвим** — «голый» VLESS ничего не шифрует. Документация прямо требует слой безопасности. > - **UUID — единственная аутентификация**, статичная и без временной метки. При утечке UUID доступ получает кто угодно; защита от повторов (anti-replay) есть только в 0-RTT-режиме нового VLESS Encryption, но не в базовом протоколе. > - **Устойчивость к DPI зависит от обвязки, а не от протокола.** Неправильная связка (без Vision, без REALITY) детектируется по TLS-паттернам — см. [[VLESS/dpi-tls-june-2026|разбор DPI-эвристик июня 2026]]. > - **Историческая путаница с flow.** Быстро устаревавшие `origin`/`direct`/`splice` → `vision` создавали проблемы совместимости конфигов между версиями Xray. ## 📚 См. также - [[xray/project-x|Project X (Xray-core)]] — история проекта, XTLS, REALITY, экосистема - [[xray/xtls-vision|XTLS и Vision]] — что такое поле `flow` и чем XTLS отличается от VLESS/REALITY - [[xray/reality|REALITY]] — слой безопасности, маскировка под чужой сайт - [[xray/xhttp|XHTTP]] — транспорт через CDN - [[xray/clients-and-routing|Клиенты и маршрутизация]] — как подключиться клиентом и развести трафик - [[VLESS/dpi-tls-june-2026|DPI TLS heuristics 2026]] — как DPI детектит VLESS+REALITY поведенчески - [[VLESS-SOCKS5-vulnerability]] и [[VLESS-localhost-protection-guide]] — риски неправильной настройки - 🔗 [Спецификация VLESS (dev docs)](https://xtls.github.io/en/development/protocols/vless.html) — первоисточник формата - 🔗 [config: inbounds/vless](https://xtls.github.io/en/config/inbounds/vless.html) · [outbounds/vless](https://xtls.github.io/en/config/outbounds/vless.html) — справка по конфигу - 🔗 [VLESS Encryption](https://xraycore.org/en/misc/vless-encryption/) — пост-квантовое шифрование --- > [!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ > При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны на GitHub: [исходник этой заметки](https://github.com/youtubediscord/todo/blob/main/xray/vless.md) · [весь репозиторий](https://github.com/youtubediscord/todo/tree/main).