VLESS TLS gRPC: как работает связка и почему она популярна в 2026 году

Что такое VLESS и чем он отличается от VMess

VLESS — это транспортный прокси-протокол, разработанный в рамках проекта Xray-core как облегчённый преемник VMess. Его название неформально расшифровывается как «VMess Less», то есть «VMess без лишнего». Основная задача VLESS — аутентифицировать клиента и сообщить серверу, куда переслать трафик. В отличие от VMess, VLESS не имеет собственного жёсткого криптографического контура и не требует синхронизации часов между клиентом и сервером. В VMess расхождение времени более чем на 90 секунд приводило к разрыву соединения, а также использовалась отдельная «аутентификация ответа». Всё это усложняло протокол и создавало проблемы на устройствах с неточными часами.

VLESS отказался от встроенного шифрования и временных меток. Вместо этого он полагается на внешние слои безопасности, такие как TLS или REALITY, которые обеспечивают конфиденциальность и маскировку трафика. Это делает VLESS более гибким и быстрым, поскольку он не тратит ресурсы на собственную криптографию, а использует уже проверенные механизмы. Протокол работает поверх различных транспортов, включая TCP, WebSocket, gRPC, XHTTP и mKCP, что позволяет адаптироваться к разным сетевым условиям и требованиям цензуры.

Как устроен VLESS на уровне байтов

Заголовок запроса VLESS состоит из нескольких полей. Первый байт — версия протокола (0 в тестовых сборках, 1 в релизах). Затем идёт 16-байтовый UUID, который идентифицирует пользователя. После UUID следуют Addons — protobuf-данные переменной длины, которые могут содержать, например, значение flow. Если addons не нужны, длина равна нулю, и накладные расходы отсутствуют. Далее идёт команда (TCP, UDP или MUX), порт назначения (2 байта) и адрес назначения (тип адреса и сам адрес).

Заголовок ответа минимален: версия, Addons и данные. Такая компактность важна, потому что заголовок VLESS не содержит криптографически «шумных» элементов, таких как временные метки или хеши, которые могли бы выдать протокол при анализе трафика. Всё, что видит DPI (deep packet inspection), — это уже обёрнутый TLS-трафик, а сам заголовок VLESS находится внутри зашифрованного канала и невидим для наблюдателя.

Роль TLS в связке VLESS

TLS (Transport Layer Security) — это внешний слой шифрования, который обеспечивает конфиденциальность и целостность данных, передаваемых между клиентом и сервером. В связке VLESS+TLS протокол VLESS работает внутри TLS-туннеля, что делает трафик неотличимым от обычного HTTPS-соединения. Это важно для обхода DPI, поскольку TLS-трафик выглядит как легитимный веб-трафик.

Однако использование TLS создаёт проблему «TLS-in-TLS»: когда VLESS-трафик уже зашифрован внутри TLS, а затем передаётся по TLS-соединению, возникает двойное шифрование. Это может быть обнаружено DPI по характерным длинам TLS-записей. Для решения этой проблемы используется механизм XTLS-Vision, который добавляет случайный паддинг во внутреннее рукопожатие, размывая паттерны. Также Vision может перехватывать UDP-трафик на порту 443 (QUIC), заставляя браузер использовать HTTPS поверх TCP, что уменьшает утечки и нагрузку.

Транспорт gRPC: особенности и преимущества

gRPC — это RPC-фреймворк от Google, основанный на HTTP/2. В контексте VLESS gRPC используется как транспорт, который мультиплексирует несколько потоков в одном HTTP/2-соединении. Это обеспечивает высокую эффективность и хорошую совместимость с CDN, особенно с Cloudflare, который официально поддерживает gRPC. gRPC отличается высокой стабильностью в мобильных сетях и хорошей совместимостью с TLS 1.3.

По сравнению с WebSocket, gRPC имеет более высокую пропускную способность и лучшую устойчивость к цензуре. Однако его задержка немного выше, чем у чистого TCP. В бенчмарках, проведённых в 2026 году, gRPC показал пропускную способность около 720 Мбит/с в тесте Токио-Сингапур, что ниже, чем у TCP (850 Мбит/с), но выше, чем у XHTTP (680 Мбит/с) и WebSocket (540 Мбит/с). Задержка gRPC составила 32 мс, что выше, чем у TCP (18 мс), но ниже, чем у WebSocket (38 мс).

Сравнение gRPC с другими транспортами: XHTTP, WebSocket, TCP

В 2026 году основными транспортами для VLESS являются gRPC, WebSocket (WS), XHTTP и TCP. Каждый из них имеет свои сильные и слабые стороны.

gRPC — лучший баланс между производительностью и устойчивостью к цензуре. Он хорошо работает через CDN и стабилен в мобильных сетях. Рекомендуется для умеренной цензуры и при использовании Cloudflare.

WebSocket — зрелый и простой в настройке, но его устойчивость к усиленному DPI постепенно снижается. Подходит для общих сценариев, но в условиях продвинутой цензуры (Китай, Иран, Россия) показывает худшие результаты.

XHTTP — новый транспорт на основе HTTP/2, официально принятый во второй половине 2025 года. Он максимально устойчив к цензуре и сложно отличим от обычного веб-трафика. Однако его совместимость с CDN ещё улучшается, и он менее зрел, чем WS и gRPC.

TCP — базовый транспорт без дополнительных обёрток. Обеспечивает максимальную производительность и минимальную задержку, но легко обнаруживается DPI. Подходит только для слабой цензуры или собственных серверов в странах с мягкими ограничениями.

В условиях продвинутой цензуры (Шанхай, Китай) реальные бенчмарки показали: XHTTP — 95% успешных подключений, gRPC — 87%, WS — 72%, TCP — 12%. В Юго-Восточной Азии: gRPC — 99%, XHTTP — 98%, WS — 95%, TCP — 78%.

Настройка VLESS TLS gRPC: пошаговое руководство

Для настройки VLESS с TLS и gRPC необходимо отредактировать конфигурационный файл Xray-core. Основные параметры:

• В секции streamSettings укажите network: "grpc".
• Добавьте security: "tls" и настройте TLS-сертификаты.
• В grpcSettings укажите serviceName — это имя службы, которое должно совпадать на клиенте и сервере.

Пример фрагмента конфигурации:

"streamSettings": {
  "network": "grpc",
  "security": "tls",
  "tlsSettings": {
    "serverName": "example.com",
    "certificates": [
      {
        "certificateFile": "/etc/ssl/example.com.crt",
        "keyFile": "/etc/ssl/example.com.key"
      }
    ]
  },
  "grpcSettings": {
    "serviceName": "vless-grpc"
  }
}

На клиенте необходимо указать тот же serviceName и serverName. Также важно, чтобы версии Xray-core на клиенте и сервере были совместимы. При использовании обратного прокси, например Nginx, нужно настроить location для gRPC-запросов и убедиться, что прокси передаёт заголовки правильно.

Работа через CDN: особенности gRPC и WebSocket

CDN (Content Delivery Network) позволяет скрыть реальный IP-адрес сервера и улучшить доступность. Для работы через Cloudflare с VLESS чаще всего используют gRPC или WebSocket, так как они официально поддерживаются. gRPC имеет официальную поддержку Cloudflare, что делает его предпочтительным выбором. WebSocket также широко поддерживается, но его производительность может быть ниже.

При настройке CDN необходимо:

• Настроить подключение к серверу-источнику (origin).
• Включить поддержку WebSocket/gRPC на стороне CDN.
• Установить TTL (время жизни кэша) — для VLESS-трафика кэширование не требуется, поэтому лучше отключить его.
• Выбрать подходящий план Cloudflare (бесплатный или платный).

Важно помнить, что XHTTP пока имеет ограниченную совместимость с CDN, поэтому для CDN-сценариев gRPC и WS остаются основными вариантами.

VLESS Encryption: пост-квантовая защита без TLS

С сентября 2025 года в Xray-core появился VLESS Encryption — встроенное шифрование, которое позволяет использовать VLESS без внешнего TLS. Метод называется mlkem768x25519plus и использует гибрид пост-квантового механизма ML-KEM-768 и классического X25519. Это обеспечивает защиту от атак «harvest now, decrypt later», когда злоумышленник записывает зашифрованный трафик сейчас, чтобы расшифровать его в будущем с помощью квантового компьютера.

VLESS Encryption включается параметрами decryption на сервере и encryption на клиенте. Он снимает ограничение Vision на транспорт: flow=xtls-rprx-vision теперь работает поверх XHTTP, WebSocket и gRPC, а не только на TCP. Однако VLESS Encryption не заменяет TLS полностью: он не создаёт стандартный HTTPS-сертификат и не обеспечивает маскировку под обычный веб-трафик. Для обхода цензуры по-прежнему рекомендуется использовать REALITY или XHTTP.

Важно: VLESS Encryption несовместим с fallbacks (конфигурация не запустится), и его не поддерживает ядро sing-box, что ограничивает использование в некоторых клиентах.

REALITY и XTLS-Vision: как они работают вместе

REALITY — это технология, которая позволяет имитировать TLS-соединение с реальным сайтом, не имея собственного сертификата. Она использует target (реальный сайт), serverNames (список доменов), ключи X25519 и shortId. REALITY обеспечивает аутентификацию и маскировку, делая трафик неотличимым от обычного HTTPS.

XTLS-Vision — это механизм управления потоком, который решает проблему «TLS-in-TLS». Он добавляет случайный паддинг во внутреннее рукопожатие и может использовать splice (zero-copy передачу через ядро Linux) для оптимизации производительности. Vision работает в связке с TLS или REALITY. При использовании REALITY и TLS 1.3 Vision может напрямую копировать уже зашифрованные данные без повторного шифрования, что снижает нагрузку на CPU.

Ранние режимы flow (xtls-rprx-origin, xtls-rprx-direct, xtls-rprx-splice) устарели и удалены. Современный Xray-core требует использовать xtls-rprx-vision.

XUDP и мультиплексирование: поддержка UDP и оптимизация

XUDP — это расширение мультиплексора Mux.Cool, которое обеспечивает Full Cone NAT поверх VLESS. Это позволяет UDP-приложениям (игры, звонки, P2P) работать через прокси, несмотря на строгий NAT. XUDP появился в Xray-core v1.3.0 и агрегирует UDP-потоки в туннель, перенося адрес и порт внутри Mux-фрейма. Начиная с v1.8.1, реализован настоящий Full Cone: даже после разрыва TCP (например, при смене сети) сервер сохраняет тот же исходящий порт для UDP-источника.

Параметр xudpProxyUDP443 управляет судьбой QUIC-трафика (UDP 443). Часто его намеренно не пускают в туннель, чтобы Vision заставлял браузер использовать HTTPS поверх TCP, уменьшая утечки.

Мультиплексирование (Mux.Cool) позволяет объединять несколько потоков в одно TCP-соединение, снижая накладные расходы и улучшая производительность. Однако при использовании Mux потери и блокировка TCP могут затронуть несколько потоков одновременно, поэтому его нужно настраивать осторожно.

Критерии выбора транспорта в зависимости от сценария

Выбор транспорта VLESS зависит от условий использования. Вот рекомендации на основе реальных бенчмарков 2026 года:

• Продвинутая цензура (Китай, Иран, Россия): XHTTP или gRPC. XHTTP обеспечивает максимальную устойчивость, gRPC — стабильность и совместимость с CDN.
• Умеренная цензура (Центральная Азия, Юго-Восточная Азия): gRPC — лучший баланс, XHTTP — максимальная устойчивость, WS — общий вариант.
• Слабая цензура (Япония, США, Европа): TCP — максимальная производительность, gRPC — при использовании CDN.
• Работа через CDN (Cloudflare): gRPC (официальная поддержка) или WS (широкая поддержка).
• Игры и коммуникации в реальном времени: TCP (минимальная задержка), QUIC (высокая скорость UDP), XHTTP (баланс).

Для критически важных сценариев рекомендуется использовать несколько транспортов параллельно и автоматически переключаться между ними в зависимости от сети.

Устранение неполадок и практические советы

При настройке VLESS TLS gRPC могут возникнуть проблемы. Основные шаги для диагностики:

1. Проверьте журналы Xray-core на сервере и клиенте.
2. Используйте Wireshark для анализа захвата пакетов.
3. Проверьте, успешно ли проходит TLS-рукопожатие.
4. Убедитесь, что DNS-запросы разрешаются правильно.
5. Сверьте версии транспорта на клиенте и сервере.

Также важно правильно настроить TLS и SNI: выбирайте домен для подмены SNI среди крупных сервисов с высокой надёжностью, используйте последние версии отпечатков uTLS (например, Chrome 130 или Firefox 130) и следите за сроками действия сертификатов.

При работе через CDN проверьте настройки origin, поддержку WebSocket/gRPC, TTL и отключение кэша. Для старых клиентов настройте fallback, чтобы они могли подключаться через другие транспорты.

Вопросы и ответы