todo/xray/vless.md

date	tags	aliases	link
2026-07-17	xray vless xtls reality protocol censorship	VLESS Протокол VLESS VLESS protocol	https://xtls.github.io/en/development/protocols/vless.html

🔷 Протокол VLESS: устройство и возможности

[!info] О чём заметка Подробный разбор протокола VLESS — транспортного прокси-протокола ядра xray/project-x, на котором сегодня строится большинство серверов обхода блокировок. Здесь — как устроен протокол на уровне байтов, что умеет поле flow, зачем нужны fallbacks, XUDP и новое встроенное пост-квантовое шифрование. История самого проекта и технологий REALITY/XTLS — в обзорной заметке xray/project-x; как современный DPI детектит связку VLESS+REALITY — в VLESS/dpi-tls-june-2026.

TL;DR

• VLESS — облегчённый (stateless) прокси-протокол, преемник VMess. Придуман разработчиком RPRX внутри проекта xray/project-x.
• Это прокси, а не VPN. VLESS переносит отдельные соединения («соедини меня с youtube.com:443»), а не IP-пакеты, и виртуальный сетевой интерфейс ему не нужен: хватает локального SOCKS5 на 127.0.0.1. TUN-адаптер — это отдельный механизм перехвата поверх протокола, тот самый «режим VPN» из интерфейсов: у Xray-core для него с января 2026 есть собственный инбаунд "protocol": "tun", а на мобильных интерфейс создаёт система и передаёт ядру. Разбор различия и его практических следствий — в protocols/00-overview.
• Ключевая идея: сам протокол ничего не шифрует и не маскирует. Аутентификация — по одному UUID, а конфиденциальность делегируется внешнему слою (TLS, xray/reality) и flow-контролю (xray/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 и коде proxy/vless/encoding в Xray-core.

Заголовок запроса идёт последовательно:

Поле	Размер	Что это
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).

Актуальные значения (config outbounds/vless):

• пусто / нет поля — обычное проксирование через 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. Механизм splice (zero-copy передача через ядро Linux) при этом никуда не делся — он остался внутренней оптимизацией Vision, а не отдельным значением flow.

XTLS-Vision доступен в двух случаях: в связке TCP+TLS или TCP+xray/reality (тогда для TLS 1.3 он умеет напрямую копировать уже зашифрованные данные без повторного шифрования) — либо при включённом xray/vless-encryption, и тогда ограничений на нижележащий транспорт нет вовсе. Сводная матрица «какая комбинация транспорта, security, flow и encryption работает» — в xray/vless-stack-map.

Fallbacks: маскировка под настоящий сайт

Fallback — механизм VLESS inbound, который перенаправляет «неправильный» трафик на другое назначение (обычно на настоящий веб-сервер вроде nginx). Требует связки TCP+TLS. Источник: features/fallback.

Зачем это нужно:

• Защита от активного зондирования (active probing). Цензор отправляет на подозрительный сервер обычный HTTP/TLS-запрос, чтобы проверить, прокси это или нет. Без fallback такой запрос ни на что не похож; с fallback он уходит на реальный сайт, и зонд получает нормальную веб-страницу — сервер выглядит как обычный HTTPS-хост.
• Разделение одного порта. На 443-м порту одновременно живут и прокси, и настоящий сайт.

Xray «подглядывает» первый пакет и выбирает наиболее точное правило FallbackObject по полям: name (сопоставление с TLS SNI), alpn (фактически согласованный ALPN), path (HTTP PATH, должен начинаться с /), dest (куда переслать), xver (отправлять ли PROXY protocol, чтобы бэкенд видел реальный IP клиента). Правило выбирается по точности совпадения, а не по порядку в конфиге.

[!warning] Fallbacks несовместимы с новым шифрованием fallbacks нельзя использовать одновременно с decryption, отличным от none, то есть с включённым xray/vless-encryption (см. ниже) — придётся выбрать что-то одно. Само по себе "decryption": "none" с fallbacks сочетается нормально. Причём это не мягкая деградация: конфиг не проходит сборку с ошибкой VLESS settings: "fallbacks" can not be used together with "decryption", и Xray не запускается вообще — вместе с ним падают все остальные входы из этого файла.

Транспорты и слой безопасности

VLESS — это только логика протокола; он работает поверх транспортного слоя (type/network):

• TCP (RAW) — базовый транспорт; единственный, где XTLS-Vision получает ядерный splice, и единственный, где Vision работает без xray/vless-encryption.
• xray/xhttp — новый HTTP-транспорт (пришёл на смену старому h2/SplitHTTP), дружит с CDN.
• WebSocket (ws) — совместим с CDN и обычными веб-серверами.
• gRPC — параметр serviceName.
• mKCP (kcp) — на базе UDP, с коррекцией ошибок (FEC).
• HTTPUpgrade — лёгкий транспорт на HTTP-Upgrade.

Слой безопасности (security): none, tls или reality. На практике VLESS почти всегда используют с tls или reality. С версии v26.7.11 (июль 2026, пока пре-релиз) значение none перестало быть просто нежелательным и стало ошибкой конфигурации на стороне клиента: ядро отказывается собирать исходящее соединение с сообщением vless without TLS or other encryption is prohibited unless the server address is a private IP or domain. Серверный вход с такой схемой пока стартует. Снять запрет можно двумя способами — приватный адрес назначения либо включённое xray/vless-encryption.

XUDP и Mux.Cool: полноценный UDP

По умолчанию проксировать UDP (игры, звонки, P2P) сложно из-за NAT. XUDP — расширение мультиплексора Mux.Cool, которое даёт Full Cone NAT поверх VLESS. Источники: Discussion #252, Mux.Cool spec.

• 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 (автор RPRX, влит 28 августа 2025) и вышедший в стабильном релизе Xray-core v25.9.5 от 5 сентября 2025. Полный разбор — формат строки параметра, криптография, режимы внешнего вида, совместимость клиентов и польза против блокировок — в отдельной заметке xray/vless-encryption. Здесь только суть.

• Собственное шифрование без внешнего TLS. VLESS может работать при security: none, сохраняя конфиденциальность и forward secrecy. Метод называется mlkem768x25519plus, задаётся полем decryption на сервере и encryption на клиенте, генерируется командой xray vlessenc.
• Пост-квантовая стойкость. Эфемерный обмен ключами — гибрид ML-KEM-768 (пост-квантовый механизм инкапсуляции ключа) и X25519; аутентификация сервера отдельным ключом, на выбор X25519 или ML-KEM-768. Это защита от атаки «harvest now, decrypt later» («сейчас запишем — потом расшифруем»).
• Снимает ограничение Vision на транспорт. С VLESS Encryption flow=xtls-rprx-vision работает поверх xray/xhttp, WebSocket и gRPC, а не только на прямом TCP.
• Главный сценарий — посредник. Через CDN и транзитные узлы внешний TLS терминируется не на вашем сервере, и открытый заголовок VLESS (UUID, адрес назначения) виден посреднику. Внутреннее шифрование это закрывает.

[!warning] Оговорки, о которые спотыкаются на практике Автор прямо пишет, что VLESS Encryption не предназначен для прямого обхода цензуры: собственный внешний вид у него есть (native, xorpub, random плюс настраиваемая набивка), но лежит он внутри туннеля, поэтому наблюдателю снаружи виден внешний слой — для маскировки нужны REALITY, XHTTP и Vision. Кроме того: decryption несовместим с fallbacks (Xray вообще не стартует), ядро sing-box этот механизм не поддерживает (то есть Hiddify, NekoBox for Android, Karing), а старые клиенты после серверной миграции обрываются или зависают без внятной ошибки.

Формат ссылок vless://

Стандарт share-ссылок (Discussion #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 (или без xray/vless-encryption) трафик уязвим — «голый» VLESS ничего не шифрует. С июля 2026 ядро прямо запрещает такую конфигурацию на публичный адрес.
• UUID — единственная аутентификация, статичная и без временной метки. При утечке UUID доступ получает кто угодно; защита от повторов (anti-replay) есть только в 0-RTT-режиме нового VLESS Encryption, но не в базовом протоколе.
• Устойчивость к DPI зависит от обвязки, а не от протокола. Неправильная связка (без Vision, без REALITY) детектируется по TLS-паттернам — см. VLESS/dpi-tls-june-2026.
• Историческая путаница с flow. Быстро устаревавшие origin/direct/splice → vision создавали проблемы совместимости конфигов между версиями Xray.

📚 См. также

• xray/vless-encryption — подробный разбор встроенного пост-квантового шифрования: строка параметра, криптография, миграция, польза против блокировок
• xray/vless-stack-map — матрица «что с чем работает»: транспорт, security, flow, encryption и когда включается splice
• xray/project-x — история проекта, XTLS, REALITY, экосистема
• xray/xtls-vision — что такое поле flow и чем XTLS отличается от VLESS/REALITY
• xray/reality — слой безопасности, маскировка под чужой сайт
• xray/xhttp — транспорт через CDN
• xray/clients-and-routing — как подключиться клиентом и развести трафик
• VLESS/dpi-tls-june-2026 — как DPI детектит VLESS+REALITY поведенчески
• protocols/vmess — предшественник VLESS: alterId, режим AEAD и почему от собственного шифрования отказались
• protocols/00-overview — карта: какой протокол какую задачу решает и какое ядро его поддерживает
• VLESS-SOCKS5-vulnerability и VLESS-localhost-protection-guide — риски неправильной настройки
• 🔗 Спецификация VLESS (dev docs) — первоисточник формата
• 🔗 config: inbounds/vless · outbounds/vless — справка по конфигу
• 🔗 VLESS Encryption — пост-квантовое шифрование

---

[!quote] 🤖 Эти статьи открыты — можно обучать на них ИИ При желании вы можете натренировать ИИ на наших статьях. Исходное форматирование и скачивание всего репозитория одним zip-архивом доступны в Forgejo: исходник этой заметки · весь репозиторий.