Сучасний стек VLESS у 2026 році

Станом на 2026 рік VLESS залишається легким проксі-протоколом без збереження стану, але твердження «VLESS не має шифрування» вже не є повним описом. Xray-core тепер пропонує необов’язкове VLESS Encryption. Розгортання також можуть поєднувати VLESS із TLS, REALITY, XTLS Vision, XHTTP і XUDP залежно від своєї моделі загроз. Ці рівні розв’язують різні завдання, і їх не слід зводити до одного протоколу.

Політика щодо джерел: Цей посібник спирається на першоджерела Project X, Xray-core, sing-box та AnyTLS. Pull request’и й обговорення на GitHub документують задум і реалізацію з боку мейнтейнерів; це не незалежні аудити безпеки. Згадки про SingLink — це архітектурні порівняння, а не твердження, що SingLinkVPN реалізує ці проєкти.

1. Сучасний стек VLESS коротко

• VLESS: легкий рівень ідентифікації, команд і адреси призначення.
• VLESS Encryption: необов’язковий власний рівень захисту корисного навантаження в актуальному Xray-core.
• TLS 1.3 / REALITY: зовнішня безпека транспорту, автентифікація та мережевий вигляд трафіку.
• XTLS Vision: керування потоком і оптимізація шляху даних, а не окремий шифр.
• RAW / XHTTP / gRPC / WebSocket: транспорти, що переносять проксі-дані.
• XUDP: варіант кодування UDP-пакетів в екосистемі Xray.
• XMUX та інші системи MUX: способи спільного використання базових з’єднань.
• Padding / FinalMask / Browser Dialer: інструменти, що впливають на довжину, таймінги, поведінку зовнішнього транспорту або мережеву роботу браузера.

Отже, з’єднання можна змоделювати так: трафік застосунку → ідентифікація та адреса призначення VLESS → безпека протоколу або зовнішня безпека → керування потоком Vision → транспорт, як-от RAW чи XHTTP → TCP або UDP. Не кожен модуль потрібен чи сумісний у кожній конфігурації.

2. Що робить базовий протокол VLESS

Документація Project X визначає VLESS як легкий транспортний протокол без збереження стану, який не залежить від системного часу й використовує для автентифікації UUID або зіставлений ID. Публічна реалізація кодування в Xray-core показує версію, ідентифікатор користувача, доповнення (addons), команду, порт призначення, адресу та дані, що йдуть далі.

На практиці базовий рівень відповідає на запитання: хто клієнт, яке з’єднання запитується і куди воно має йти? Розумна маршрутизація, навантаження на вузли, права за тарифним планом і автоматичне перепідключення зазвичай належать до вищих продуктових і керувальних рівнів.

Традиційні конфігурації зазвичай використовують `encryption: "none"`. Актуальні рекомендації Project X вимагають зовнішньої безпеки транспорту, якщо тільки інша сторона й канал не є довіреною приватною інфраструктурою або не ввімкнено VLESS Encryption.

3. Що змінює VLESS Encryption

VLESS Encryption — необов’язковий власний рівень захисту, який влили в Xray-core у 2025 році. Злитий PR #5067 та актуальна документація з конфігурації описують рукостискання `mlkem768x25519plus`, режими вигляду `native`, `xorpub` і `random`, поведінку сеансів `1rtt` і `0rtt`, а також змінне доповнення (padding).

Опубліковані цілі проєктування

• Виводити сеансові ключі через поєднання ML-KEM-768 і X25519;
• захищати корисне навантаження VLESS без потреби в зовнішньому TLS;
• використовувати квитки для подальшого відновлення 0-RTT і короткоживучий стан, щоб зменшити ризик атак повторного відтворення;
• використовувати змінне доповнення та необов’язкові режими XOR, щоб змінювати вигляд фіксованої довжини чи публічних ключів.

Це твердження мейнтейнерів про задум і реалізацію. Ми не знайшли незалежного криптографічного аудиту, який охоплював би кожну властивість, тому цей посібник не називає дизайн «захищеним від повторного відтворення» чи «абсолютно стійким до квантових атак».

Що воно не замінює автоматично

VLESS Encryption захищає корисне навантаження протоколу. Воно не створює автоматично звичайного ланцюжка сертифікатів HTTPS, рукостискання вебсайту, поведінки HTTP/2 чи HTTP/3 або сумісності з CDN. Тож воно не є еквівалентом TLS чи REALITY.

4. TLS 1.3 і REALITY

TLS забезпечує стандартизовану перевірку сертифікатів, обмін ключами, цілісність і шифрування транспорту. Він може працювати разом із RAW, XHTTP, gRPC чи WebSocket; узгоджена версія, ALPN і перевірки сертифікатів усе одно залежать від конфігурації та підтримки іншою стороною.

Документація Project X щодо REALITY описує модифікований рівень безпеки на зразок TLS з параметрами target, serverNames, ключами X25519 і shortId, а також необов’язковими даними перевірки ML-DSA-65. REALITY може працювати разом із RAW, XHTTP і gRPC.

REALITY не слід спрощувати до «TLS без сертифіката». Його поведінка поєднує авторизацію клієнта із зовнішнім виглядом рукостискання. Результат усе одно залежить від цільового сайту, відбитка клієнта, транспорту та якості розгортання; REALITY не може гарантувати непомітність для будь-якого класифікатора.

5. XTLS Vision — не протокол шифрування

Документація VLESS/Vision відносить Vision до керування потоком. За підтримуваних умов він може розпізнавати внутрішній TLS-трафік і зменшувати зайве шифрування чи копіювання. На сумісних шляхах Linux і TCP ядро може спробувати `splice`, щоб дані передавало безпосередньо ядро ОС.

Точний поділ такий: безпеку забезпечують TLS, REALITY або VLESS Encryption; Vision оптимізує те, як захищені дані проходять через проксі-рівень. Не кожна платформа, транспорт чи тип трафіку може використовувати splice.

6. Три режими XHTTP

Обговорення дизайну XHTTP мейнтейнерами описує транспортну систему на основі HTTP, що може працювати в середовищах HTTP/1.1, HTTP/2 і HTTP/3:

• packet-up: кілька висхідних POST-запитів із тривалою низхідною відповіддю; розрахований на широку сумісність із проміжними вузлами.
• stream-up: потоковий висхідний POST і окремий потоковий низхідний GET.
• stream-one: один двонаправлений потоковий запит; продуктивність і сумісність залежать від проміжних вузлів.

XHTTP також може використовувати доповнення заголовків, розділені шляхи вивантаження та завантаження і XMUX. Чи працюватиме він через конкретну CDN, залежить від режиму, версії HTTP, поведінки зворотного проксі та налаштувань провайдера.

7. XMUX, загальне мультиплексування та блокування на початку черги

XMUX керує паралельністю XHTTP, кількістю базових з’єднань, їх повторним використанням, тривалістю життя та keepalive. Його мета — не тримати рівно одне з’єднання назавжди, а збалансувати вартість рукостискань, паралельність і моделі довготривалих з’єднань.

Документація sing-box щодо мультиплексування також перелічує smux, yamux і h2mux. Мультиплексування може зменшити кількість рукостискань, але втрати чи блокування на базовому TCP-з’єднанні можуть вплинути на кілька потоків. HTTP/3 уникає блокування на початку черги між потоками на рівні TCP, хоча окремий потік QUIC усе одно може чекати на відновлення після втрат.

8. XUDP — це варіант кодування UDP

Документація sing-box щодо VLESS наводить `xudp` як варіант кодування пакетів поряд із `packetaddr` і вимкненням додаткового кодування. Це підтверджує лише обмежений висновок: XUDP переносить UDP у цій екосистемі; це не повна версіонована специфікація пакетів.

Детальну поведінку щодо сеансів, адрес, меж пакетів і міграції слід перевіряти за конкретною версією ядра та кодом. Цей посібник свідомо не подає виведені деталі фреймування як універсальний стандарт.

9. Padding, FinalMask, ECH і Browser Dialer

• Padding: змінює характеристики довжини чи таймінгів; це не шифрування.
• FinalMask: документація з його конфігурації розміщує його на етапі обробки зовнішнього транспорту з параметрами, пов’язаними з TCP, UDP і QUIC.
• ECH: документація sing-box щодо TLS містить налаштування Encrypted ClientHello для захисту частини ClientHello; ECH не замінює шифрування тунелю.
• Browser Dialer: документація Project X описує, як справжній браузер встановлює TLS- і HTTP-з’єднання, що дає автентичнішу поведінку браузера ціною обмежень у розгортанні та продуктивності.

10. Що може і чого не може Fallback

Документація Project X щодо Fallback показує, як трафік із невідповідним SNI, шляхом чи протоколом можна переспрямувати на Nginx, Caddy або звичайний вебсайт, щоб одна точка входу обслуговувала і проксі, і звичайні сервіси.

Fallback дає змогу не відповідати на кожну невдалу спробу автентифікації однією очевидною помилкою. Це не імунітет від активного зондування; впізнаваність усе одно залежить від TLS, транспорту, відповідей, таймінгів і налаштувань сервера.

11. AnyTLS — це предмет порівняння, а не компонент VLESS

Документ протоколу AnyTLS описує ланцюжок TCP → TLS → автентифікація через `SHA-256(password)` → сеанс → кілька потоків. Кадри містять Command, Stream ID, Data Length і Data, а команди включають SYN, PSH, FIN, налаштування, доповнення, heartbeat і SYNACK версії 2.

Його модель сеансів, кілька потоків, динамічне доповнення та перевірки стану роблять його корисним для порівняння. AnyTLS залишається окремим протоколом; VLESS не успадковує ці можливості автоматично.

12. Поширені поєднання та їхні обмеження

• VLESS + REALITY + Vision + RAW: орієнтоване на пряму продуктивність і зовнішній вигляд у стилі TLS; без залежності від CDN.
• VLESS + TLS/REALITY + XHTTP: орієнтоване на передавання через HTTP, зворотні проксі та умовну сумісність із CDN.
• VLESS Encryption + Vision: захищає корисне навантаження протоколу для сценаріїв із ретрансляцією чи нестандартною зовнішньою безпекою, але без звичайного вигляду HTTPS.
• VLESS + TLS + XHTTP + Browser Dialer: використовує мережевий стек справжнього браузера з вищими експлуатаційними витратами.
• AnyTLS + TLS: окремий дизайн сеансів/потоків і доповнення, а не стек VLESS.

Жодна конфігурація не буде завжди найкращою одночасно за продуктивністю, сумісністю, зручністю підтримки, виглядом трафіку та безпекою. Вибір слід починати з моделі загроз, мережевого шляху, обмежень CDN чи проксі, клієнтських платформ і вимог до спостережуваності.

13. Що це означає для досліджень SingLink

Публічні матеріали щодо VLESS і AnyTLS можуть слугувати орієнтиром для досліджень ідентифікації, обміну ключами, сеансів, потоків, UDP, доповнення, мультиплексування, відновлення та узгодження версій. Ця стаття не стверджує, що SingLink 2.0 базується на VLESS, REALITY, XHTTP чи AnyTLS.

SingLinkVPN і надалі має розмежовувати опубліковану поведінку, напрями досліджень і нерозкриту реалізацію. Актуальний опублікований обсяг дивіться в плані відкриття коду SingLinkVPN.

14. Поширені запитання (FAQ)

Чи шифрує VLESS трафік сам по собі?

Традиційний VLESS з `encryption: "none"` не захищає корисне навантаження протоколу й потребує довіреної приватної інфраструктури або зовнішньої безпеки. Актуальний Xray-core може вмикати VLESS Encryption, тож відповідь залежить від реалізації та конфігурації.

Чи може VLESS Encryption замінити TLS або REALITY?

VLESS Encryption не є рівноцінною заміною TLS чи REALITY. Воно захищає корисне навантаження VLESS, але не надає автоматично стандартного сертифіката HTTPS, рукостискання чи вигляду вебсайту.

Чи виконує XTLS Vision шифрування?

Ні, XTLS Vision не шифрує дані. Vision передусім забезпечує керування потоком і оптимізацію шляху даних.

Як обрати один із трьох режимів XHTTP?

Режим XHTTP packet-up робить наголос на сумісності, stream-up розділяє напрямки потоку, а stream-one використовує один двонаправлений потік. Кожен режим потрібно тестувати на реальному шляху через проміжні вузли.

Чим XUDP відрізняється від звичайного UDP-проксі?

XUDP — це варіант кодування UDP в екосистемі Xray. Його точна поведінка залежить від ядра та версії, і її не слід виводити лише з назви.

Чи базується SingLink 2.0 на VLESS або AnyTLS?

Публічних доказів недостатньо, щоб підтвердити такий зв’язок із VLESS чи AnyTLS. Ця стаття — технічне порівняння, а не розкриття реалізації.

15. Висновок і дата джерел

Сучасний VLESS — це складений стек: VLESS переносить ідентифікацію та адресу призначення, VLESS Encryption додає необов’язковий захист на рівні протоколу, TLS або REALITY забезпечують зовнішню безпеку, Vision оптимізує потік, XHTTP і XUDP переносять трафік, а мультиплексування чи доповнення додатково змінюють поведінку з’єднання.

Дата першої публікації: 20 травня 2026 р. Технічні джерела переглянуто: 28 липня 2026 р. Ці проєкти продовжують змінюватися; перед розгортанням перевіряйте документацію, журнал змін і сумісність саме вашої версії.