VLESS Protocol Keys: структура, параметры и настройка для защиты от DPI

Что такое VLESS и почему он использует ключи

VLESS — это облегчённый транспортный протокол без сохранения состояния, разработанный в экосистеме V2Ray и развитый в форке Xray-core. Его главная особенность — отсутствие встроенного шифрования и минимальная собственная логика: протокол лишь обрамляет пользовательский трафик в поток и передаёт его через выбранный транспортный уровень. Поэтому безопасность и маскировка соединения целиком зависят от внешних механизмов, таких как TLS или Reality.

Именно из-за этой архитектуры в VLESS так важны ключи. В отличие от протоколов со встроенной криптографией, где ключи генерируются автоматически и скрыты от пользователя, VLESS требует явной передачи нескольких параметров между клиентом и сервером. Эти параметры — UUID, публичный ключ Reality, короткий идентификатор, SNI-домен и отпечаток TLS — вместе образуют то, что в сообществе называют VLESS protocol keys.

Ключи выполняют разные функции: одни аутентифицируют пользователя, другие проверяют подлинность сервера, третьи маскируют соединение под обычный HTTPS-трафик. Понимание каждого параметра позволяет не только правильно настроить соединение, но и диагностировать проблемы, когда что-то перестаёт работать.

Основные ключи VLESS: UUID, pbk, sid, sni, fp

В конфигурации VLESS+Reality используется пять ключевых параметров, которые часто называют ключами:

• UUID — универсальный уникальный идентификатор пользователя. Это единственный credential, который клиент предъявляет серверу. UUID генерируется случайным образом и должен совпадать на клиенте и сервере.
• pbk (public key) — публичный ключ Curve25519 в base64url-кодировке. Сервер генерирует пару ключей (приватный и публичный) с помощью команды xray x25519. Клиент использует pbk для проверки подлинности сервера и шифрования сессии.
• sid (short ID) — короткий идентификатор в шестнадцатеричном формате (до 16 символов). Позволяет одному серверу обслуживать несколько логических endpoint'ов. Значение встраивается в TLS-рукопожатие и помогает серверу отличать легитимных клиентов от посторонних.
• sni (Server Name Indication) — домен, который подставляется в TLS ClientHello. Это должен быть реальный, публично доступный HTTPS-сайт, не заблокированный в вашем регионе. Именно на этот домен будет похоже ваше соединение.
• fp (fingerprint) — параметр, указывающий клиенту эмулировать TLS-отпечаток конкретного браузера (chrome, firefox, safari, edge, qq или random). Это делает ClientHello неотличимым от настоящего браузера.

Все эти параметры передаются в URI-ссылке VLESS, например: vless://UUID@host:port?flow=xtls-rprx-vision&encryption=none&type=tcp&security=reality&fp=chrome&sni=example.com&pbk=PUBLIC_KEY&sid=SHORT_ID#remark.

Как генерируются ключи VLESS+Reality

Генерация ключей для VLESS+Reality — это двухэтапный процесс. Сначала создаётся пара ключей Curve25519, затем — UUID пользователя.

Для генерации ключей Reality используется встроенная команда Xray:

xray x25519

Эта команда выводит приватный и публичный ключи. Приватный ключ остаётся на сервере и используется в конфигурации inbound, а публичный передаётся клиенту и указывается в параметре pbk.

UUID можно сгенерировать стандартными средствами: онлайн-генератором, командой uuidgen в Linux или cat /proc/sys/kernel/random/uuid. Важно, чтобы UUID был уникальным и не повторялся для разных пользователей на одном сервере.

Короткий идентификатор (sid) — это произвольная шестнадцатеричная строка длиной до 16 символов. Её можно сгенерировать случайно, например, командой openssl rand -hex 8. Если sid не указан, используется пустое значение, но для повышения безопасности рекомендуется задавать уникальный sid для каждого пользователя или группы пользователей.

После генерации ключей необходимо синхронизировать их между клиентом и сервером: приватный ключ и UUID прописываются в серверный конфиг, а публичный ключ, UUID, sid и sni — в клиентский.

Структура URI VLESS: как читать ключи в ссылке

URI VLESS — это стандартный формат передачи конфигурации, который используется в подписках и QR-кодах. Разобрать его несложно, если знать структуру.

Общий вид:

vless://UUID@HOST:PORT?PARAMETERS#REMARK

• UUID — идентификатор пользователя.
• HOST — IP-адрес или домен сервера.
• PORT — порт для подключения (обычно 443).
• PARAMETERS — query-параметры, разделённые &.
• REMARK — произвольная метка, например, страна или название конфигурации.

Основные query-параметры:

• security=reality — указывает, что используется Reality.
• encryption=none — VLESS не шифрует полезную нагрузку самостоятельно.
• type=tcp — транспортный протокол (может быть tcp, ws, grpc, xhttp).
• flow=xtls-rprx-vision — режим управления потоком (только для TCP).
• pbk=... — публичный ключ Reality.
• sid=... — короткий идентификатор.
• sni=... — домен для маскировки.
• fp=chrome — отпечаток TLS.
• alpn=h2,http/1.1 — список ALPN-протоколов (необязательно).

Пример реальной ссылки из публичных подписок:

vless://4292f5ab-8963-076c-8052-3615895ce4f1@37.139.33.187:52006?flow=xtls-rprx-vision&encryption=none&type=tcp&security=reality&fp=qq&sni=max.ru&pbk=4CH3o5zOMcFNMbnwXnkAg0FFepmsc0QzhahXkUzb1ik&sid=d8c6b58bcbb0c323#Austria VK

Здесь видно, что сервер находится в Австрии, маскируется под российский домен max.ru и использует отпечаток QQ Browser.

Параметр flow=xtls-rprx-vision: зачем он нужен

Параметр flow=xtls-rprx-vision — это режим управления потоком, который применяется в конфигурациях VLESS+Reality с TCP-транспортом. Он выполняет две важные функции.

Первая — TLS passthrough. Когда туннелируемый контент сам является HTTPS-трафиком, Vision пропускает внутренний TLS-слой напрямую, не оборачивая его в ещё один TLS. Это позволяет избежать паттерна «TLS-over-TLS», который давно детектируется DPI. Если бы трафик был зашифрован дважды, это создало бы характерную структуру пакетов, выдающую VPN.

Вторая — формирование трафика. Vision подгоняет размеры пакетов и тайминги под профиль обычного браузерного HTTPS-соединения. Это снижает статистическую различимость VPN-сессии: DPI видит поток, похожий на загрузку веб-страницы, а не на постоянный двунаправленный туннель.

Важно: flow=xtls-rprx-vision работает только с TCP-транспортом. Для WebSocket, gRPC и XHTTP этот параметр либо избыточен, либо несовместим. В конфигурациях с XHTTP используется режим stream-one, который обеспечивает аналогичную функциональность.

Существует также расширенный режим xtls-rprx-vision-udp443, предназначенный для неблокирующего UDP-трафика через порт 443 (например, для QUIC).

Reality: как ключи защищают от активного зондирования

Reality — это security-режим, который заменяет стандартный TLS и решает проблему сертификатов. Обычный TLS-VPN требует валидного сертификата на сервере, и DPI может проверить, кому он принадлежит. Reality же делает так, что TLS-сессия завершается на реальном сервере известного домена.

Ключевые параметры Reality — pbk, sid и sni — работают вместе. Когда клиент подключается, он отправляет TLS ClientHello с SNI, указывающим на реальный домен (например, www.microsoft.com). Сервер Reality принимает рукопожатие, но вместо того чтобы завершить его самостоятельно, он проксирует его к настоящему серверу Microsoft. Клиент получает настоящий сертификат, верифицированный через реальную цепочку CA.

Если к серверу обращается посторонний (зондирование), Reality возвращает ему настоящий ответ от SNI-домена. Это делает сервер неотличимым от обычного HTTPS-сайта: активное зондирование не выявляет прокси.

Публичный ключ pbk используется для аутентификации: только клиент, знающий правильный pbk, может установить туннель. sid позволяет серверу различать легитимных клиентов и посторонних, даже если они используют один и тот же SNI.

Выбор SNI-донора: на что обращать внимание

SNI-донор — это домен, под который маскируется ваше соединение. От правильного выбора зависит, насколько убедительно будет выглядеть трафик для DPI.

Основные критерии:

• Реальный и популярный сервис. Донор должен иметь высокий трафик, чтобы ваш трафик не выделялся на общем фоне.
• Географическое соответствие. IP вашего сервера должен находиться в том же регионе, что и CDN донора. Если SNI говорит icloud.com, а IP принадлежит датскому хостингу — это аномалия.
• Отсутствие блокировок в вашей стране. Донор должен быть доступен без VPN.

Хорошие примеры для европейских серверов: github.com (Azure, глобальный CDN), www.twitch.tv (AWS), www.microsoft.com. Плохой пример — apple.com, потому что Apple использует собственные ASN, и несоответствие с хостингом сразу заметно.

В российских реалиях часто используют домены VK (sun6-22.userapi.com, m.vk.com), Яндекс (api-maps.yandex.ru), а также max.ru, kinopoisk.ru, avito.st. Эти домены не блокируются и имеют высокий трафик.

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

XHTTP: новый транспорт и его ключи

XHTTP — это транспортный протокол в Xray-core, который работает поверх HTTP/2 или HTTP/3. Он был разработан как ответ на детекцию WebSocket и стал популярным после блокировок VLESS+TCP в ноябре 2025 года.

В отличие от WebSocket, который после Upgrade переходит в постоянный двунаправленный поток, XHTTP разделяет восходящий и нисходящий трафик на отдельные HTTP-транзакции. Каждая транзакция выглядит как обычный HTTP-запрос/ответ с нормальными заголовками и временем жизни. Это делает трафик статистически неотличимым от браузерного.

XHTTP поддерживает три режима:

• packet-up — много коротких HTTP-запросов клиент→сервер, одно соединение сервер→клиент. Работает через CDN и Nginx, небольшой оверхед.
• stream-up — одно долгоживущее соединение в каждую сторону. Быстрее, но не проходит через все CDN.
• stream-one — единое соединение для обоих направлений. Единственный режим, совместимый с XTLS-Vision.

Ключи VLESS (UUID, pbk, sid, sni, fp) используются в XHTTP так же, как и в TCP. Дополнительно можно задать параметр xPaddingBytes для нормализации размеров пакетов.

Важное ограничение: версии Xray на клиенте и сервере должны совпадать при использовании XHTTP. Несовпадение приводит к неработоспособности без понятных ошибок.

Как проверить, что ключи работают корректно

После настройки VLESS+Reality важно убедиться, что все ключи и параметры работают правильно. Есть несколько способов проверки.

Проверка TLS-отпечатка. Подключитесь через прокси и зайдите на сайт типа scrapfly.io/web-scraping-tools/ja3-fingerprint. Отпечаток должен совпадать с тем, который вы видите при обычном подключении без прокси. Если он отличается — значит, fingerprint настроен неверно.

Проверка активного зондирования. С другого IP-адреса выполните прямой запрос к вашему серверу:

curl -v https://your.domain.com --resolve your.domain.com:443:YOUR_SERVER_IP

Вы должны получить нормальный HTTP-ответ, а не TLS-ошибку. Это подтверждает, что Reality корректно отвечает посторонним.

Проверка поведенческого профиля. Через несколько недель работы посмотрите статистику трафика на сервере. Если входящий и исходящий трафик примерно равны при обычном браузинге — это аномалия. У реального веб-сервера исходящий трафик значительно превышает входящий.

Проверка UUID. Убедитесь, что UUID на клиенте и сервере совпадают. Ошибка в UUID — самая частая причина неработоспособности.

Если что-то не работает, проверьте в первую очередь соответствие версий Xray, правильность ключей и доступность SNI-домена.

Безопасность ключей: как защитить свои VLESS-конфигурации

Ключи VLESS — это чувствительная информация. Если они попадут в чужие руки, злоумышленник сможет пользоваться вашим сервером или, хуже, подменить его.

Не передавайте ключи в открытом виде. Используйте защищённые каналы: мессенджеры с шифрованием, зашифрованные архивы или менеджеры паролей.

Регулярно меняйте ключи. Если вы подозреваете утечку, перегенерируйте UUID, pbk и sid. Для этого достаточно обновить конфиги на сервере и у клиентов.

Используйте уникальные ключи для каждого пользователя. Не раздавайте один UUID всем. Это упростит отзыв доступа при необходимости.

Не публикуйте приватные ключи. Приватный ключ Reality должен храниться только на сервере. Публичный ключ можно передавать клиентам, но приватный — никогда.

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

Помните: безопасность VLESS зависит не только от протокола, но и от того, как вы обращаетесь с ключами.

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