todo/xray/vless-stack-map.md

date	tags	aliases	link
2026-08-06	xray vless xtls vision reality transport splice	Слои VLESS Что с чем работает VLESS Vision REALITY XHTTP разница Почему Vision не работает с WebSocket flow пустой что значит Чем отличается encryption от security Когда работает splice в Xray	https://xtls.github.io/en/config/outbounds/vless.html

🧩 Слои VLESS-стека: кто за что отвечает и что с чем работает

[!info] О чём заметка Пять параметров одной vless://-ссылки — type, security, flow, encryption и сам протокол — управляют пятью разными слоями, и путаница между ними даёт большинство ошибок настройки: «включил Vision, а он не работает», «зачем REALITY, если есть шифрование», «почему splice не включается». Эта заметка — карта: за что отвечает каждый слой, чего он не делает, и матрица реальных комбинаций (проверено по коду Xray-core v26.7.28, август 2026). Подробные разборы каждой технологии — в отдельных заметках: xray/vless, xray/xtls-vision, xray/reality, xray/xhttp, xray/vless-encryption.

TL;DR

• Пять осей независимы: протокол (кто вы), транспорт (во что упаковано), слой безопасности (что видит цензор), flow (как передаётся поток внутри), encryption (шифрование самого протокола VLESS).
• Ни один слой не заменяет другой. xray/reality прячет соединение, xray/xtls-vision убирает признак TLS-в-TLS, xray/vless-encryption защищает содержимое от посредника. Три разные задачи.
• Пустой flow — это не «безопасно по умолчанию», а рабочая, но детектируемая схема: внутренний TLS шифруется второй раз, и вложенное рукопожатие видно по длинам первых пакетов.
• Слух «в России без flow блокировки обходятся лучше» имеет реальную основу, но неверную причину: помогал не пустой flow, а mux, который без отказа от Vision не включить. Разбор ниже.
• Vision раньше требовал прямого TCP. С появлением VLESS Encryption это перестало быть правдой: XTLS доступен либо при TCP + TLS/REALITY, либо при включённом VLESS Encryption — и тогда транспорт любой.
• Splice ≠ Vision. Ядерный zero-copy включается в узком наборе условий: прямой TCP, без mux, appearance не random, и только в направлении «сервер → клиент». Vision работает и без splice, просто без ускорения.
• Три жёстких запрета, которые ломают запуск или соединение: fallbacks + decryption (Xray не стартует), Vision + UDP-команда, TCP-поток внутри mux при Vision (рвёт всё mux-соединение).

Пять осей: что за что отвечает

Самая полезная привычка — читать конфиг не как список настроек, а как пять независимых ответов на пять разных вопросов.

Ось	Параметр	Отвечает на вопрос	Значения
Протокол	protocol	Кто вы и куда несём трафик	vless, vmess, trojan…
Транспорт	method в конфиге (type в ссылке)	Во что упакован поток	raw (алиас tcp), xhttp, grpc, websocket, httpupgrade, mkcp, hysteria
Слой безопасности	security	Как соединение выглядит снаружи	tls, reality, none
Flow	flow	Как передаётся поток внутри туннеля	пусто, xtls-rprx-vision, xtls-rprx-vision-udp443
Шифрование протокола	encryption	Защищено ли содержимое VLESS само по себе	none, mlkem768x25519plus…

Проще говоря: транспорт — это коробка, слой безопасности — как коробка выглядит для наблюдателя, flow — правило укладки содержимого, а encryption — замок на самом содержимом. Меняя одну ось, вы не меняете остальные.

Две оговорки по именам транспортов. Во-первых, в июле 2026 (v26.7.11) ключ конфига network переименовали в method; старое имя не удалили, оно молча работает как синоним, но в документации теперь только новое. В share-ссылке параметр по-прежнему называется type. Во-вторых, канонические имена сменились: raw вместо tcp, websocket вместо ws, mkcp вместо kcp — прежние варианты остались алиасами. И отдельно: для WebSocket, gRPC и HTTPUpgrade ядро при старте печатает предупреждение об устаревании с советом переходить на XHTTP (появилось ещё в декабре 2024, формулировка мягкая — сроков удаления нет).

[!warning] Почему REALITY иногда ошибочно называют транспортом Путаница возникает из-за структуры официальной документации: страница REALITY лежит в разделе «Конфигурация транспорта» — рядом с RAW, XHTTP и WebSocket. Но внутри этого раздела она относится к подразделу «Безопасность транспорта», и в конфиге REALITY задаётся значением security, а не method. Это разные оси: транспорт отвечает за то, во что упакован поток, REALITY — за то, как этот поток выглядит снаружи. Потому они и комбинируются: REALITY поверх RAW, поверх XHTTP или поверх gRPC.

Сама документация формулирует роль точно: REALITY — «модификация TLS, которая использует внешний вид и характеристики рукопожатия целевого сайта как маскировку» и «одна из самых сильных схем защиты транспорта». Защита транспорта — не транспорт. Там же разведены и соседние роли: REALITY отвечает за маскировку, а xray/xtls-vision — за управление потоком.

Простейшая проверка на симметрию: обычный TLS задаётся тем же самым параметром security и лежит в том же разделе документации — но транспортом его никто не называет. Значит, и REALITY им не является: это его прямая замена на той же оси. Разница между ними в другом — TLS шифрует и подтверждает подлинность вашего сервера, а REALITY делает то же самое, но вдобавок выдаёт ваш сервер за чужой. Маскировка у него не побочный эффект, а заявленная цель.

Что каждый слой решает и чего не решает

Именно эта таблица снимает большую часть путаницы: у каждой технологии есть узкая задача, а всё остальное — не её работа.

Технология	Решает	Не решает
xray/vless	Аутентификацию по UUID и доставку до адреса назначения	Ничего не шифрует и не маскирует сам по себе
xray/reality	Шифрование (это модификация TLS 1.3) плюс маскировку: сервер выглядит как чужой настоящий сайт и устойчив к активному зондированию	Не прячет форму трафика и не спасает от блокировки по IP/подсети
TLS	Шифрование и стандартный вид HTTPS-соединения — но своего, а не чужого	Ничего не маскирует: нужен свой домен и сертификат, а TLS-отпечаток клиента остаётся заметным
xray/xtls-vision	Сигнатуру длин первых пакетов (TLS-в-TLS) и лишнее двойное шифрование	Не шифрует, не прячет тайминги и объёмы, не даёт невидимости
xray/xhttp / WebSocket / gRPC	Проход через CDN и обычные веб-серверы	Не шифруют; содержимое видно тому, кто терминирует внешний TLS
xray/vless-encryption	Шифрование самого VLESS: постквантово, с прямой секретностью и защитой от повторов	Не меняет внешний вид соединения — против блокировок по отпечатку бесполезно
uTLS (fp)	Отпечаток клиентского TLS — соединение похоже на Chrome/Firefox	Не влияет ни на поведение, ни на длины пакетов внутри туннеля, ни на содержимое
mux	Схлопывает лавину TCP-соединений в одно	Ломает Vision-splice, а с Vision может оборвать всё мультиплексированное соединение

TLS-в-TLS: что это за проблема и при чём тут flow

Проблема, вокруг которой построен весь flow, называется TLS-in-TLS (двойное шифрование). Браузер идёт на сайт по HTTPS — это уже зашифрованный TLS-поток. Прокси заворачивает его в свой TLS-туннель до сервера. Получается TLS внутри TLS: и лишняя работа процессору, и характерная сигнатура — по длинам первых пакетов вложенного рукопожатия прокси отличается от обычного HTTPS.

flow управляет тем, что с этим делать:

• пусто — ничего. Внутренний поток шифруется второй раз, вложенное рукопожатие остаётся с характерными короткими пакетами.
• xtls-rprx-vision — добивает служебные пакеты рукопожатия случайной набивкой примерно до 900–1400 байт, а после того как убедится, что внутри пошёл настоящий TLS 1.3, перестаёт набивать и передаёт данные напрямую.
• xtls-rprx-vision-udp443 — то же самое, но QUIC на порт 443 не перехватывается. Значение только клиентское: суффикс отрезается перед отправкой, и сервер всегда видит обычный xtls-rprx-vision.

Механика паддинга и разбор по байтам — в xray/xtls-vision, здесь важна только граница ответственности: Vision работает поверх уже установленного шифрования и сам ничего не шифрует.

[!warning] Что даёт пустой flow и почему это не «безопасный дефолт» Конфигурация без flow полностью работоспособна и совместима со всем на свете — именно поэтому её так часто выдают панели и боты. Но она означает буквально следующее: двойное шифрование сохраняется, паддинг рукопожатия не применяется, а Xray сам помечает такое соединение как непригодное для ускорения. В коде сервера есть даже отдельное сообщение об отказе для входов с Vision: «клиент отклонён, потому что его flow пуст; учтите, что чистый TLS-прокси обладает определёнными признаками TLS-в-TLS». То есть пустой flow — осознанный компромисс ради совместимости, а не нейтральный выбор.

История отношения разработчиков к пустому flow за 2026 год успела качнуться в обе стороны, и это стоит знать администраторам больших серверов. 18 января 2026 года (релиз v26.1.18) ядро начало печатать предупреждение о том, что VLESS без flow устарел и скоро будет удалён. Через пять дней формулировку смягчили до «The feature VLESS (with no Flow, etc.) is deprecated, not recommended for using and might be removed. Please migrate to VLESS with Flow & Seed as soon as possible» — угрозу немедленного удаления убрали, релиз v26.1.23.

Дальше вмешалась реализация: сообщение выводилось на каждого пользователя входа, и сервер с десятью тысячами ключей получал десять тысяч одинаковых строк при старте, раздувая логи и задерживая запуск настолько, что у некоторых панелей срывались таймауты (issue #5667, подан на v26.2.6 и закрыт как not planned). Предупреждение всё же сняли — PR #5671 влит 3 марта 2026 и вышел в сборке v26.3.23, а в списке изменений релиза v26.3.27 (27 марта 2026) это записано как «Remove "with no flow" warning for now».

Формулировка «пока что» здесь важнее самого отката: направление на вытеснение VLESS без flow разработчики обозначили, но подтверждённой даты удаления нет, и на сегодня конфигурация без flow остаётся официально поддерживаемой.

«В России без flow работает лучше» — что за этим стоит на самом деле

Утверждение ходит по чатам с осени 2025 года, и у него есть реальная основа — но причина не та, которую обычно называют. Разбор стоит того, чтобы прочитать целиком, потому что из неверной причины следуют неверные решения.

Что произошло. С 12 ноября 2025 года у части домашних провайдеров (MTS/МГТС в Москве, JustLan, LanInterCom, есть свидетельство по «Ростелекому» в Ижевске от 1 ноября) появилось новое поведение фильтрации: соединение устанавливалось нормально, но как только по туннелю шли настоящие данные, передача замирала — причём тем быстрее, чем больше трафика. Примерно через 60 секунд к тому же серверу снова можно было подключиться. Обычный HTTPS-сёрфинг при этом не страдал, а сам сервер продолжал пинговаться и отдавать страницу в браузере. Всё это описано в net4people/bbs #546.

Что проверил автор темы — пользователь под ником 0x3mp7y. В списке «уже проверено и не помогает» первым пунктом стоит именно «включение и выключение flow (xtls-rprx-vision)». А среди рабочих обходов перечислены: сменить порт с 443 на любой другой; чтобы остаться на 443 — убрать flow и включить mux; XHTTP (или старые H2/H3), тоже вместе с mux; пускать через прокси только нужные адреса; наконец, любой не-TLS протокол, который ещё не блокируют. В обновлении от 15 ноября механизм сформулирован прямо: провайдер применяет шейпинг при достижении некоторого числа одновременных соединений с одним адресом, поэтому «должны работать и любые другие приёмы, уменьшающие количество TLS-соединений».

Отсюда настоящая причинно-следственная цепочка — пустой flow здесь техническое условие, а не средство:

цель: уменьшить число внешних TLS-соединений к серверу
   ↓
это делает Mux.Cool — классический мультиплексор протокола
   ↓
Mux.Cool несовместим с Vision (TCP-поток внутри mux рвёт mux-соединение)
   ↓
приходится выставить flow пустым
   ↓
соединений становится меньше — фильтр по их количеству не срабатывает

[!important] Эта дилемма касается только Mux.Cool — у XHTTP мультиплексор другой Мультиплексоров в Xray два, и их постоянно смешивают. Mux.Cool — классический мультиплексор уровня протокола VLESS; именно он несовместим с Vision, и именно про него весь разбор выше. XMUX — мультиплексор транспорта xray/xhttp: много проксируемых соединений делят одно HTTP/2 или HTTP/3-соединение, но каждое из них остаётся отдельным обычным запросом, и Vision над ними работает штатно. Поэтому с появлением xray/vless-encryption выбор «или паддинг Vision, или мультиплексирование» исчез: рекомендация xray/authors-v2ray-xray для CDN звучит как «VLESS Encryption + XTLS Vision + XHTTP XMUX» — всё сразу.

То есть «no flow» сам по себе ничего не обходит. Самая недвусмысленная формулировка принадлежит тому же человеку, который первым описал проблему: 21 ноября 2025 года в обсуждении PR #5102 он пишет — «я пробовал в тестах отключать flow вообще как угодно, но без добавления mux это не помогало». Выдать пользователю ключ с пустым flow и не включить mux — значит не получить вообще ничего из описанного эффекта.

Причём mux задаётся настройкой клиента, а не параметром vless://-ссылки: в стандарте share-ссылок поля для него нет вовсе, и в разных клиентах он включается по-разному. Это главная практическая ловушка такой «оптимизации» — профиль выглядит «как советовали», а механизм, который единственный и работал, не включён.

Насколько это больно, зависит от клиента, и разброс тут неприятный:

Клиент	Можно ли доставить mux удалённо	Область настройки
v2rayNG	Нет вообще — поле намеренно не читается ни из ссылки, ни из подписки	глобально на всё приложение
v2rayN	Только своим форматом v2rayn://	на профиль
Happ	Да — документированные строки подписки mux-enable, mux-tcp-connections, mux-xudp-connections, mux-quic (нужен Provider ID)	глобально, перезаписывает выбор пользователя
v2RayTun	Да, но через вендорский бэкенд провайдера, недокументированно	глобально
Throne	Да — нестандартные параметры ссылки mux, mux_concurrency	на профиль, перебивает глобальную
mihomo, sing-box, Hiddify, Karing	Мультиплексор есть, но чужой — не Mux.Cool	—

Две ловушки из этой таблицы стоят отдельного упоминания. Первая: у самого массового в России клиента, v2rayNG, включить mux дистанционно невозможно в принципе — пользователю придётся лезть в настройки руками, и настройка эта глобальная, то есть заденет и остальные его профили, где mux бесполезен. Вторая: у mihomo, sing-box и клиентов на них мультиплексирование — это smux/yamux/h2mux из семейства sing-box, несовместимые с Mux.Cool на уровне протокола (разные магические адреса, разный формат кадров). Если включить smux в подписке против Xray-сервера, клиент честно попросит проксировать sp.mux.sing-box.arpa:444, Xray этого адреса не узнает, попытается его отрезолвить, получит NXDOMAIN — и узел будет выглядеть просто мёртвым, без единого внятного сообщения на клиентской стороне.

[!note] «Включите mux, чтобы соединение не рвалось по простою» — на текущем коде не работает Отдельный миф из той же области. В протоколе Mux.Cool с самого начала определён кадр keepalive, но, как выяснилось в PR #6561 (31 июля 2026), ни один путь кода его никогда не отправлял — простаивающее mux-соединение на проводе действительно простаивает. Патч, добавлявший отправку, мейнтейнер отклонил со словами «такой способ правки неверен, и момент отправки нужно продумать». Так что mux сокращает число соединений, но не поддерживает их живыми.

[!warning] Средство оказалось временным и не универсальным — счёт шёл на дни Уже в обновлении от 22 ноября 2025 автор темы 0x3mp7y пишет, что mux и XHTTP помогают не всем пользователям. 23 ноября он же в issue #5332 добавляет короче: «похоже, mux сейчас тоже не помогает». Саму волну откатили около 25 ноября 2025 — то есть весь эпизод, породивший слух, уложился примерно в две недели.

Дальше было хуже. 7 февраля 2026 года в той же теме сообщают о новой волне (начавшейся, судя по репликам, на три-четыре дня раньше), под которую попали и VLESS + REALITY + Vision, и VLESS с пустым flow. В тот же день другой участник описывает симптом иначе: «Server Hello не возвращается» — то есть блокировка сработала уже на рукопожатии, а на этой стадии значение flow не может повлиять ни на что в принципе, оно живёт внутри туннеля.

Параллельно в России работают совсем другие механизмы: белые списки SNI и подсетей, ограничения по региону и оператору. Против них выбор flow не влияет ни на что.

[!danger] Второе российское правило работает ровно наоборот, и mux под него попадает хуже Есть вторая, независимая схема фильтрации, описанная в net4people/bbs #490: при подозрительной подсети сервера соединение «замораживают» после того, как в нём прошло определённое количество пакетов. Изначально порог описывали в байтах — 15–20 КБ, — но позже автор темы уточнил механику: считаются не байты, а пакеты, обычно 25 в каждую сторону, что в среднем и даёт те самые ~16 КБ полезной нагрузки. Правило применяется и к TCP, и к UDP, поэтому правило предложено переименовать из «tcp 16-20» в «l4-25» — но в самих чекерах старое имя пока осталось. Проверить, есть ли правило у вашего провайдера, можно утилитой l4-25_prober.py: по умолчанию она шлёт всего 64 байта, разбитые на 32 пакета по два, и этого хватает, чтобы поймать заморозку — что и показывает, что дело в пакетах, а не в объёме. Бюджет привязан к соединению и по времени не восстанавливается: попытка выждать паузу, не разрывая соединение, результата не дала.

Отсюда следует неприятное: два правила требуют противоположного. Правило по числу соединений (#546) лечится их сокращением, то есть mux. Правило по числу пакетов (l4-25, #490) наказывает как раз за длинные соединения, и его штатный обход — наоборот, размазать трафик по многим коротким. Мультиплексирование по определению максимизирует пакеты на соединение: восемь потоков делят один 25-пакетный бюджет и умирают разом. Прямых замеров «mux против l4-25» нет — в треде #490 мультиплексирование не обсуждается вовсе, — так что это вывод из механики правила, а не измерение. Но проверять, какое из двух правил действует именно у вас, нужно до того, как раздавать профиль: они лечатся взаимоисключающими способами.

[!warning] Мультиплексирование само по себе — тоже фингерпринт Продолжение работы USENIX 2024 той же группы — NDSS 2025 «The Discriminative Power of Cross-layer RTTs in Fingerprinting Proxy Traffic» — атакует уже не начало соединения, а расхождение RTT транспортного и прикладного уровней в любой его момент. Про мультиплексирование там сказано прямо: оно снижает детект, «однако может вводить новые типы отпечатков — мультиплексированные потоки живут дольше и несут больше пакетов, а медианное число пар запрос-ответ в них выше, чем у 97 % всех потоков, наблюдаемых у провайдера, что уже само по себе делает их выбросами и более заметными». Вывод авторов: «мы советуем с осторожностью относиться к мультиплексированию как к единственной мере защиты».

Vision в той же работе тестировался и не помог: «за исключением obfs4, результаты по всем протестированным прокси-протоколам оказались практически идентичными» — атака протокольно-агностична, потому что ни один из них не меняет тайминги. Детект на уровне отдельного потока около 20 %, но на уровне визита на сайт — выше 70 %.

[!note] Побочная гипотеза, которую тоже стоит знать: «Vision палится по своему паддингу» Разбирая ту же ноябрьскую волну, xray/authors-v2ray-xray — автор и Vision, и самого VLESS — 21 ноября 2025 года предположил, что оператор мог нацелиться именно на параметры набивки в коде Vision, те самые пороги 900 500 900 256, не менявшиеся три года. Догадкой это названо сразу («поэтому я так и предположил»), а основанием послужило то, что помог mux. Через два дня — уточнение: неясно даже принципиальное, обучен ли фильтр как чёрный список по трафику Vision или как белый список по браузерному. А ещё через день появилась третья версия: дело вообще не в признаках отдельного соединения, потому что, по сообщению одного из участников, под фильтр попадал и настоящий Chrome — то есть считают только соединения. Правда, тут же выяснилось, что и это объяснение шаткое — другой разработчик возразил, что браузер сам ограничен шестью соединениями на домен, поэтому «кратные шести» цифры в наблюдении могут быть артефактом самого Chrome, и нужен отдельный тест.

Практическим следствием всё равно стала настройка testseed, позволяющая менять эти пороги (PR #5270, влит 1 декабря 2025), но публичных отчётов «поменял параметры — блокировка ушла» с тех пор не появилось. Подробности — в xray/xtls-vision. Пока это непроверенное предположение, от которого отступил и сам RPRX.

Что в 2026 году крутят вместо flow

Полезный ориентир для тех, кто хочет действующий рычаг, а не фольклор: в самом Xray настройка, которую подкручивают под российские блокировки, — это число соединений XHTTP-мультиплексора, и дефолт у неё за один месяц поменяли дважды. 27 июня 2026 года дефолт maxConnections подняли до 6 с прямой пометкой в коммите «for anti-RKN» (релиз v26.6.27), а 28 июля снизили с 6 до 3 — «for anti-TSPU» (релиз v26.7.28). Поводом ко второму изменению стала жалоба из России о том, что лимит одновременных соединений у оператора упал с двенадцати до четырёх, а за превышение следует бан на несколько минут.

Единого правильного значения нет, и полевые отчёты прямо расходятся. 28 июля 2026 пользователь из Москвы сообщает, что maxConnections: 3 держится больше месяца без вмешательства ТСПУ, выше трёх начинаются блокировки на мобильной сети МТС, а выше шести — и на проводной. А 4 августа другой пользователь из России пишет обратное: после массовых блокировок ему стало заметно лучше, когда он вручную вернул значение к 6, и предполагает, что фильтр реагирует уже на слишком малое и слишком частое число ClientHello, потому что это не похоже на естественное поведение браузера. Ответа разработчиков на это сообщение нет, коммитов в ядро после 28 июля тоже. Вопрос на 6 августа 2026 открыт.

Практический вывод для администратора: подбирать значение под свою сеть и следить за обновлениями, но крутить именно его, а не flow — и он совместим с Vision. Следующий кандидат на настройку уже предложен и пока не принят: hMinSocketInterval (issue #6547), который разносил бы установку соединений по времени на 400–600 мс, чтобы не попадать под порог «более трёх параллельных TLS к одному SNI с интервалом менее 350–400 мс».

[!danger] Не спутайте блокировку с обновлением ядра: дефолт minClientVer Ловушка, на которую летом 2026 попались многие. В Xray-core v26.7.11 (11 июля 2026) у REALITY появился дефолт minClientVer: 26.3.27: сервер отказывает клиентам со старым ядром. Отказ при этом молчаливый — соединение просто прозрачно уходит на настоящий сайт-донор, как будто это активный зонд. Клиент видит ошибку проверки сертификата, пинг может отображаться, трафик не идёт. Симптом неотличим от блокировки.

Под нож попали Shadowrocket, старые сборки клиентов и, что особенно неприятно, mihomo — навсегда: он жёстко сообщает версию клиента 1.8.2, и запрос на изменение закрыт с меткой «не будем», так что чинить приходится на сервере. Мотив разработчиков не криптографический, а антицензурный: старое ядро означает устаревший отпечаток uTLS, который сам повышает риск блокировки IP сервера — в коде рядом стоит предупреждение о том, что понижение порога «повышает вероятность блокировки IP вашего сервера».

Как отличить за минуту: свежий клиент на том же конфиге работает, старый — нет; откат серверного бинарника на v26.6.27 чинит всё без правки конфига; проверочная мера — прописать "minClientVer": "1.0.0" в realitySettings и перезапустить. Учтите, что затронуты только те, кто ставит пре-релизные сборки (панели вроде 3x-ui тянут их автоматически) — последний релиз со стабильной меткой, v26.3.27, этого поведения не содержит.

Что из этого следует для конфигурации. Vision остаётся более сильным основным режимом: он единственный, кто вообще что-то делает с сигнатурой TLS-в-TLS, тогда как пустой flow не делает ничего. Разумная схема — держать Vision основным профилем, а связку «пустой flow + реально включённый mux» иметь отдельным запасным профилем для сетей, которые считают соединения. И проверять их надо сравнением из самой российской сети, не меняя одновременно IP, порт, SNI и домен, иначе результат ничего не покажет.

[!note] Осторожно с цифрами из USENIX Security 2024 — их часто сравнивают неправильно В работе «Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes» действительно есть числа и про паддинг, и про мультиплексирование, но они относятся к разным конфигурациям и получены разными классификаторами в разных рабочих точках, так что ставить их рядом нельзя. Набивка у vmess поверх WebSocket и TLS снижает долю верно распознанных потоков (TPR) с 0,859 до 0,687 — и авторы тут же поясняют, что схема набивки у vmess узкая (0–63 байта). Для XTLS-Vision исследователям пришлось переучивать модель так, чтобы она опиралась на направления и порядок пакетов, а не на их индивидуальные размеры; там TPR вышел 0,513, но уже при почти вчетверо большем допуске ложных срабатываний — 0,199 % против 0,054 %, отношение 3,7. Мультиплексирование выглядит сильнее: у голого vmess объединение даже двух прикладных потоков роняет TPR с 0,771 до 0,225 — более чем на 70 %, — а vmess поверх WebSocket и TLS при восьми параллельных потоках и без всякой набивки опускается до 0,125. Строки с VLESS и mux в таблице нет вообще: авторы такую комбинацию не мерили.

У выигрыша от mux есть жёсткое условие, о котором обычно забывают: когда активен один-единственный прикладной поток, перемешивать нечего, и защита деградирует до уровня обычного немультиплексированного соединения. Так что «no-flow + mux» — это не «TPR 0,125», а «TPR 0,125 при живом параллельном трафике». Отдельно авторы отмечают довод в пользу Vision: сама необходимость писать под него выделенный классификатор повышает для цензора стоимость детекта.

Побочная деталь того же класса: у Vision по умолчанию блокируется QUIC на UDP/443 (чтобы браузер не утёк мимо туннеля), при пустом flow — нет. Рассчитывать на это не стоит: блокировки QUIC в российских сетях фиксируются с 2022 года (net4people/bbs #108). Если нужен именно Vision с разрешённым QUIC, для этого есть отдельное значение xtls-rprx-vision-udp443, а не отказ от flow.

И отдельно: Vision не делает прокси невидимым. Работа USENIX Security 2024 «Fingerprinting Obfuscated Proxy Traffic with Encapsulated TLS Handshakes» тестировала именно xtls-rprx-vision и показала, что выделенный классификатор всё равно распознаёт заметную долю таких потоков: он опирается на направления и порядок пакетов, на размеры всплесков и число обменов, а индивидуальные длины пакетов — ровно то, что прячет набивка Vision, — перестаёт учитывать. Подробнее о поведенческом детекте — в VLESS/dpi-tls-june-2026.

Матрица: какие комбинации работают

Главная таблица заметки. Проверено по коду Xray-core v26.7.28 (август 2026) и документации.

Транспорт	security	encryption	flow	Работает?	Что получаем
RAW TCP	REALITY или TLS	none	xtls-rprx-vision	✅	Классика: маскировка + паддинг рукопожатия + ядерный splice
RAW TCP	REALITY или TLS	none	пусто	✅	Работает, но TLS-в-TLS не скрыт, splice выключен
XHTTP / WS / gRPC	TLS (REALITY — не для WS)	none	пусто	✅	Проход через CDN, Vision недоступен
XHTTP / WS / gRPC	TLS (REALITY — не для WS)	none	xtls-rprx-vision	❌	Ошибка: «XTLS only supports TLS and REALITY directly for now»
XHTTP / WS / gRPC	TLS (REALITY — не для WS)	VLESS Encryption	xtls-rprx-vision	✅	Vision поверх CDN-транспорта; splice недоступен
RAW TCP	none	VLESS Encryption	xtls-rprx-vision	✅	Без внешнего TLS: шифрует сам VLESS; splice работает при native/xorpub
RAW TCP	REALITY	VLESS Encryption	xtls-rprx-vision	✅	Двойная защита; splice выключается
Любой	любой	VLESS Encryption	любой	❌ при fallbacks	Xray не стартует: "fallbacks" can not be used together with "decryption"
Любой публичный адрес	none	none	любой	❌ у клиента	С v26.7.11 (пре-релиз) исходящее соединение не собирается: VLESS без шифрования разрешён только на приватный адрес. Серверный вход такую схему пока принимает

[!warning] REALITY работает не с любым транспортом Отдельное ограничение, о которое спотыкаются при сборке конфига: REALITY поддерживает только RAW (то есть прямой TCP), XHTTP и gRPC. С WebSocket, HTTPUpgrade и mKCP его собрать нельзя — ядро отвергает конфигурацию с сообщением REALITY only supports RAW, XHTTP and gRPC for now. Для WebSocket остаётся обычный TLS.

Строка, ради которой таблица и нужна: XHTTP + Vision без VLESS Encryption не заработает, а с ним — заработает. Это и есть та связь, которую чаще всего формулируют неточно. Точная формулировка из документации: XTLS доступен в двух случаях — TCP + TLS/REALITY либо VLESS Encryption, и во втором «ограничений на нижележащий транспорт нет».

[!note] Почему сообщение об ошибке вводит в заблуждение Строка «XTLS only supports TLS and REALITY directly for now» по-прежнему живёт в коде Xray, но она стала последней веткой проверки: сначала ядро смотрит, не завёрнуто ли соединение в VLESS Encryption, потом — TLS, потом REALITY, и только если ничего не подошло, выдаёт эту ошибку. Сам текст не трогали с апреля 2023 года (до этого он звучал ещё иначе — «XTLS only supports TCP, mKCP and DomainSocket for now»), поэтому читать его буквально нельзя.

Когда включается splice (и почему обычно не включается)

splice(2) — системный вызов Linux, который перекидывает данные между сокетами прямо в ядре, без копирования в память процесса. Это то, что даёт Xray с Vision почти нулевой оверхед на слабом железе. Но условий много, и почти каждое «лишнее» улучшение конфига его выключает.

Условие	Splice
Прямой TCP, flow=xtls-rprx-vision, внутри настоящий TLS 1.3	✅
VLESS Encryption поверх прямого TCP, appearance native или xorpub, security: none	✅
VLESS Encryption с appearance random	❌ — отдельный XOR-слой нельзя «пробить»
VLESS Encryption, а поверх него ещё TLS или REALITY	❌ — под шифрованием уже не голый TCP
Транспорт XHTTP, WebSocket, gRPC, mKCP	❌ — не RAW-транспорт
Пустой flow	❌
Соединение внутри mux	❌
Внутри TLS 1.2 или шифр TLS_AES_128_CCM_8_SHA256	❌ — прямое копирование не включится
Направление «клиент → сервер» (uplink)	❌ — в коде промоушен закомментирован пометкой «TODO: enable uplink splice»

Проще говоря: splice — это премия за самую простую конфигурацию, а не свойство Vision. Как только между Vision и сокетом появляется что-то ещё — CDN-транспорт, второй слой шифрования, мультиплексор — премия пропадает, но сам Vision продолжает работать: паддинг рукопожатия применяется в любом случае, теряется только ускорение.

Одна деталь, важная для понимания: xorpub splice не ломает, хотя его часто записывают в один ряд с random. Отдельный XOR-слой создаёт только random; xorpub лишь маскирует публичные ключи внутри рукопожатия и оставляет соединение обычным.

Три запрета, о которые спотыкаются чаще всего

fallbacks и VLESS Encryption вместе — отказ старта. Не деградация, не предупреждение: конфиг не собирается, и Xray не поднимет вообще ни одного входа из этого файла. Если вход маскируется под настоящий сайт через nginx, включить на нём decryption нельзя — нужен отдельный вход.

Vision и UDP. VLESS-команда UDP при flow=xtls-rprx-vision отклоняется с ошибкой «xtls-rprx-vision doesn't support UDP». Это не значит, что UDP-приложения не работают: они едут через XUDP поверх мультиплексора. А QUIC на порт 443 Vision намеренно блокирует, чтобы браузер откатился на HTTPS поверх TCP и трафик не ушёл мимо туннеля; снять это поведение можно значением xtls-rprx-vision-udp443.

Vision и mux. Формального запрета в конфиге нет — более того, именно через mux работает XUDP. Но обычный TCP-поток внутри mux при Vision обрывает всё мультиплексированное соединение: в коде это прокомментировано словами «we will break Mux connections that contain TCP requests». Плюс любой mux-воркер безусловно выключает splice. Практический вывод: mux и Vision в одном профиле — источник плавающих обрывов, а не оптимизация.

Частые заблуждения

[!warning] «REALITY уже шифрует, значит encryption не нужен» Верно ровно до тех пор, пока между вами и сервером нет посредника, который расшифровывает внешний слой. Через CDN или транзитный узел REALITY/TLS заканчивается не на вашем сервере, и там VLESS-заголовок с UUID и адресом назначения виден в открытом виде. Разбор — в xray/vless-encryption.

[!warning] «Включу encryption вместо REALITY — станет незаметнее» Наоборот. VLESS Encryption не меняет внешний вид соединения, а RPRX прямо пишет, что для прохода через файрвол нужны REALITY, XHTTP и Vision. Более того, при security: none соединение выглядит как поток случайных байтов — а именно такой трафик китайский GFW детектирует энтропийным классификатором.

[!warning] «Vision — это шифрование» Нет. Vision — правило передачи уже зашифрованного потока: набивка рукопожатия и отказ от повторного шифрования. Название сбивает с толку из-за букв «TLS» в слове XTLS. Три значения слова «XTLS» разведены в xray/xtls-vision.

[!warning] «Vision работает только на TCP» Так было до конца августа 2025. Сейчас точнее так: Vision работает на прямом TCP с TLS/REALITY или на любом транспорте, если включён VLESS Encryption. А вот splice действительно остался привилегией прямого TCP, причём голого — без надстроенных сверху TLS и REALITY.

Как собрать конфиг под задачу

• Свой сервер, прямое подключение, максимум скорости — RAW TCP + REALITY + flow=xtls-rprx-vision, encryption=none. Здесь Vision разворачивает соединение до сырого сокета и включается ядерный splice.
• Через CDN (Cloudflare) — XHTTP + TLS + VLESS Encryption + flow=xtls-rprx-vision и XMUX. Шифрование здесь не роскошь: без него CDN читает ваш UUID и адреса назначения. WebSocket тоже работает, но это запасной вариант: RPRX советует для CDN именно XHTTP с XMUX, а не «WS + Mux», ядро с декабря 2024 печатает для WebSocket предупреждение об устаревании, и REALITY с ним всё равно не собрать — только обычный TLS.
• Транзит через чужой узел, каскад, окружение без TLS — любой транспорт + VLESS Encryption; security может быть none, этот запрет ядра снимается именно наличием шифрования.
• Максимальная совместимость с разнородными клиентами — RAW TCP + REALITY, encryption=none, flow по возможности xtls-rprx-vision. Клиенты на upstream-версии sing-box не поймут VLESS Encryption вовсе.

[!note] Где splice всё-таки включается Конфигураций две, и обе требуют голого TCP: RAW TCP + TLS или REALITY + Vision при encryption=none — и RAW TCP + security: none + VLESS Encryption в режиме native либо xorpub с Vision. Совместить внешний REALITY и внутреннее шифрование, сохранив splice, нельзя: ядро разворачивает ровно один слой.

📚 См. также

• xray/vless-encryption — что это за слой, как читать строку параметра, помогает ли против ТСПУ и GFW
• xray/xtls-vision — механика паддинга и прямого копирования по байтам, четыре поколения XTLS
• xray/vless — формат заголовка, fallbacks, XUDP, стандарт ссылок
• xray/reality — маскировка под чужой сайт и защита от активного зондирования
• xray/xhttp — как транспорт проходит через CDN и чем режимы отличаются
• VLESS/dpi-tls-june-2026 — поведенческий детект, uTLS, mux и практические шаги
• xray/authors-v2ray-xray — про RPRX, чьи решения определяют почти все настройки из этой карты
• protocols/00-overview — те же три слоя, но для всех протоколов сразу
• 🔗 config: outbounds/vless — официальная формулировка про доступность XTLS
• 🔗 config: inbounds/vless — синтаксис decryption, flow, fallbacks

---

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