Zapret Wiki

Недавно обновлено

время чтения ~10 мин.

.md

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

О чём заметка

Подробный разбор протокола VLESS — транспортного прокси-протокола ядра Xray-core, на котором сегодня строится большинство серверов обхода блокировок. Здесь — как устроен протокол на уровне байтов, что умеет поле flow, зачем нужны fallbacks, XUDP и новое встроенное пост-квантовое шифрование. История самого проекта и технологий REALITY/XTLS — в обзорной заметке Project X (Xray-core); как современный DPI детектит связку VLESS+REALITY — в разборе схемы ограничений июня 2026.

TL;DR

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

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

ПолеРазмерЧто это
Version1 байтВерсия протокола (0 в тестовых сборках, 1 в релизах)
UUID16 байтИдентификатор пользователя; сервер сверяет его при каждом соединении
Addons Length + Addons1 байт + NProtobuf-данные переменной длины; несут, в частности, значение flow. Если addons не нужны — длина 0, накладных расходов нет
Command1 байтКоманда: TCP / UDP / MUX
Port2 байтаПорт назначения
Address Type + Address1 байт + NТип адреса (IPv4 / домен / IPv6) и сам адрес

Заголовок ответа минимален: версия (совпадает с запросом), затем Addons и данные.

Почему это важно для маскировки

Заголовок VLESS предельно компактен и не содержит ничего криптографически «шумного» — никаких временных меток или хешей, выдающих протокол. Всё, что видит DPI снаружи, — это уже обёрнутый TLS/REALITY-трафик. Сам заголовок VLESS появляется только внутри зашифрованного канала, где его не видно.

Поле flow: XTLS-Vision против детекта TLS-in-TLS

flow — поле в addons, которое включает режим XTLS flow-control. Именно оно решает проблему двойного шифрования «TLS внутри TLS» (подробный разбор самой идеи XTLS, механики паддинга/splice и разграничения терминов — в заметке 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 пропускается как есть.

Старые значения 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+REALITY (тогда для TLS 1.3 он умеет напрямую копировать уже зашифрованные данные без повторного шифрования) — либо при включённом VLESS Encryption, и тогда ограничений на нижележащий транспорт нет вовсе. Сводная матрица «какая комбинация транспорта, security, flow и encryption работает» — в карте слоёв VLESS-стека.

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 клиента). Правило выбирается по точности совпадения, а не по порядку в конфиге.

Fallbacks несовместимы с новым шифрованием

fallbacks нельзя использовать одновременно с decryption, отличным от none, то есть с включённым 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 работает без VLESS Encryption.
  • 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. Серверный вход с такой схемой пока стартует. Снять запрет можно двумя способами — приватный адрес назначения либо включённое 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. Полный разбор — формат строки параметра, криптография, режимы внешнего вида, совместимость клиентов и польза против блокировок — в отдельной заметке 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 работает поверх XHTTP, WebSocket и gRPC, а не только на прямом TCP.
  • Главный сценарий — посредник. Через CDN и транзитные узлы внешний TLS терминируется не на вашем сервере, и открытый заголовок VLESS (UUID, адрес назначения) виден посреднику. Внутреннее шифрование это закрывает.

Оговорки, о которые спотыкаются на практике

Автор прямо пишет, что 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.

Ограничения и критика

Что стоит держать в голове

  • Без внешнего TLS/REALITY (или без VLESS Encryption) трафик уязвим — «голый» VLESS ничего не шифрует. С июля 2026 ядро прямо запрещает такую конфигурацию на публичный адрес.
  • UUID — единственная аутентификация, статичная и без временной метки. При утечке UUID доступ получает кто угодно; защита от повторов (anti-replay) есть только в 0-RTT-режиме нового VLESS Encryption, но не в базовом протоколе.
  • Устойчивость к DPI зависит от обвязки, а не от протокола. Неправильная связка (без Vision, без REALITY) детектируется по TLS-паттернам — см. разбор DPI-эвристик июня 2026.
  • Историческая путаница с flow. Быстро устаревавшие origin/direct/splice → vision создавали проблемы совместимости конфигов между версиями Xray.

📚 См. также

🤖 Эти статьи открыты — можно обучать на них ИИ

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

Вид графа

Обратные ссылки