aca6bc8824
All checks were successful
Published content check / validate (push) Successful in 4s
Утверждение «у Xray-core собственного TUN нет вообще, его добавляют обёртки» было неверным. Инбаунд "protocol": "tun" появился в Xray-core 7 января 2026 (PR #5464) и поддерживает Windows, Linux, macOS и FreeBSD. Позже добавлена автоматическая маршрутизация: autoSystemRoutingTable прописывает маршруты в системную таблицу (Windows — апрель 2026, macOS и Linux — июнь), autoOutboundsInterface привязывает исходящие к физическому интерфейсу, чтобы трафик самого ядра не зацикливался. Уточнено поведение на мобильных: там интерфейс создаёт система, а ядро получает готовый файловый дескриптор — Xray принимает его через XRAY_TUN_FD. Именно поэтому на телефоне запрашивается VPN-разрешение. Ошибку заметили читатели канала; исправлено в обзоре протоколов, заметке о VLESS и словаре терминов Clash. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
169 lines
25 KiB
Markdown
169 lines
25 KiB
Markdown
---
|
||
date: 2026-07-17
|
||
tags:
|
||
- xray
|
||
- vless
|
||
- xtls
|
||
- reality
|
||
- protocol
|
||
- censorship
|
||
aliases:
|
||
- VLESS
|
||
- Протокол VLESS
|
||
- VLESS protocol
|
||
link: https://xtls.github.io/en/development/protocols/vless.html
|
||
---
|
||
|
||
# 🔷 Протокол 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]].
|
||
- **Это прокси, а не 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|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 он умеет напрямую копировать уже зашифрованные данные без повторного шифрования) — либо при включённом [[xray/vless-encryption|VLESS Encryption]], и тогда ограничений на нижележащий транспорт нет вовсе. Сводная матрица «какая комбинация транспорта, `security`, `flow` и `encryption` работает» — в [[xray/vless-stack-map|карте слоёв VLESS-стека]].
|
||
|
||
## 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 клиента). Правило выбирается по точности совпадения, а не по порядку в конфиге.
|
||
|
||
> [!warning] Fallbacks несовместимы с новым шифрованием
|
||
> `fallbacks` нельзя использовать одновременно с `decryption`, отличным от `none`, то есть с включённым [[xray/vless-encryption|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|VLESS Encryption]].
|
||
- **[[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`. С версии 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|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, влит 28 августа 2025) и вышедший в стабильном релизе **Xray-core v25.9.5** от 5 сентября 2025. Полный разбор — формат строки параметра, криптография, режимы внешнего вида, совместимость клиентов и польза против блокировок — в отдельной заметке [[xray/vless-encryption|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|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](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 (или без [[xray/vless-encryption|VLESS Encryption]]) трафик уязвим** — «голый» VLESS ничего не шифрует. С июля 2026 ядро прямо запрещает такую конфигурацию на публичный адрес.
|
||
> - **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/vless-encryption|VLESS Encryption]] — подробный разбор встроенного пост-квантового шифрования: строка параметра, криптография, миграция, польза против блокировок
|
||
- [[xray/vless-stack-map|Слои VLESS-стека]] — матрица «что с чем работает»: транспорт, `security`, `flow`, `encryption` и когда включается splice
|
||
- [[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 поведенчески
|
||
- [[protocols/vmess|VMess]] — предшественник VLESS: `alterId`, режим AEAD и почему от собственного шифрования отказались
|
||
- [[protocols/00-overview|Обзор протоколов]] — карта: какой протокол какую задачу решает и какое ядро его поддерживает
|
||
- [[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-архивом доступны в Forgejo: [исходник этой заметки](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main/xray/vless.md) · [весь репозиторий](https://git.zapret.moe/zapretdiscordyoutube/todo/src/branch/main).
|