VLESS и XHTTP: как работает протокол, чем отличается от Reality и как защитить DNS-запросы

Что такое VLESS и почему он стал стандартом в Xray-core

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

Основная задача VLESS — установить соединение между клиентом и сервером, передав идентификатор пользователя (UUID) и небольшую служебную информацию. Рукопожатие минимально, что снижает задержки и упрощает маскировку под обычный HTTPS-трафик.

В Xray-core VLESS поддерживает два основных способа настройки: упрощённый (когда параметры сервера указываются на верхнем уровне) и подробный (через массив vnext). Оба варианта эквивалентны, но упрощённый удобнее для быстрой настройки, а подробный — для сложных конфигураций с несколькими серверами.

Важно отметить, что в настройках VLESS обязательно указывать decryption: "none" (для входящих) и encryption: "none" (для исходящих). Без этого Xray выдаст ошибку и откажется запускаться.

Как устроен VLESS: UUID, flow и дополнительные параметры

Каждый пользователь VLESS идентифицируется по UUID — уникальному идентификатору в формате 8-4-4-4-12. Этот UUID указывается и на сервере (в списке clients), и на клиенте (в настройках пользователя). Без совпадения UUID соединение не установится.

Помимо UUID, в настройках пользователя можно указать:

• email — метка для статистики и логов;
• level — уровень доступа, который сопоставляется с политиками;
• flow — алгоритм потока, например xtls-rprx-vision;
• testseed — служебные значения для тестового режима.

Параметр flow особенно важен: он включает XTLS Vision — механизм, который ускоряет обработку TLS-трафика, перекладывая часть работы на конечное приложение. Vision улучшает производительность и снижает нагрузку на прокси-сервер.

В Xray-core также появилась поддержка постквантового шифрования через параметр decryption/encryption вида mlkem768x25519plus. Этот режим пока экспериментальный, но он показывает направление развития протокола в сторону защиты от будущих квантовых атак.

Reality: как работает маскировка и почему её стало недостаточно

REALITY — это технология, которая решает проблему поддельных TLS-сертификатов. Вместо того чтобы использовать самоподписанный или купленный сертификат, REALITY позволяет прокси-серверу завершать TLS-рукопожатие на реальном сайте-доноре (например, microsoft.com или github.com). Клиент при этом получает настоящий сертификат, выпущенный доверенным центром сертификации.

Это даёт несколько преимуществ:

• TLS-отпечаток (JA3/JA4) совпадает с реальным браузером;
• активное зондирование (попытка подключиться к серверу как к обычному сайту) возвращает корректный ответ;
• сертификат не вызывает подозрений.

Однако, как показывает практика, REALITY уязвим к поведенческому анализу. Если через прокси идёт постоянный двунаправленный поток данных без пауз, это сильно отличается от типичного поведения реального сайта. Нейросети, обученные на трафике реальных сервисов, могут выявлять такие аномалии.

Кроме того, важно правильно выбирать сайт-донор. Он должен быть высоконагруженным, находиться в том же регионе, что и сервер, и иметь IP-адреса в известных ASN. Например, Apple — плохой донор, потому что её IP-адреса принадлежат собственным ASN, и несоответствие с хостингом сразу бросается в глаза.

XHTTP: новый транспорт, который маскирует поведение соединения

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

XHTTP поддерживает несколько режимов работы:

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

Дополнительно XHTTP поддерживает параметр xPaddingBytes, который добавляет случайный паддинг к пакетам, нормализуя их размеры. Это затрудняет анализ распределения размеров пакетов.

Важно: XHTTP и REALITY не конкурируют, а дополняют друг друга. REALITY маскирует TLS-рукопожатие, а XHTTP — поведение после него. При использовании XHTTP с REALITY автоматически выбирается режим stream-one.

Как ТСПУ и DPI обнаруживают прокси: от сигнатур до поведенческого анализа

Технические средства противодействия угрозам (ТСПУ) и системы глубокого анализа пакетов (DPI) используют многослойный подход к детекции прокси-трафика. Каждый следующий слой требует больше вычислительных ресурсов, поэтому фильтрация начинается с самых дешёвых методов.

Первый слой — сигнатурный анализ. Проверяются первые 16–32 байта пакета на соответствие известным паттернам. Например, чистый Shadowsocks или OpenVPN легко обнаружить по характерному рукопожатию. VLESS с TLS-обёрткой этот слой проходит, так как первые байты идентичны HTTPS.

Второй слой — TLS-фингерпринтинг. Вычисляется хэш JA3 или JA4 из параметров ClientHello: список cipher suites, расширения, эллиптические кривые. Если прокси-клиент использует собственную TLS-библиотеку, его отпечаток будет отличаться от браузерного. Именно поэтому в настройках VLESS важно указывать fingerprint: "chrome" — тогда Xray использует библиотеку uTLS, которая копирует ClientHello настоящего браузера.

Третий слой — активное зондирование. Система отправляет к серверу специальные запросы, пытаясь определить, является ли он настоящим веб-сервером. Если сервер не отвечает или отвечает нетипично, он блокируется.

Четвёртый слой — поведенческий анализ. Анализируются не отдельные пакеты, а их временные характеристики, размеры, частота. Это самый дорогой метод, но именно он позволяет выявлять даже хорошо замаскированные прокси.

Настройка VLESS + XHTTP + Reality: пошаговый пример конфигурации

Для создания рабочей конфигурации VLESS + XHTTP + Reality потребуется:

1. Сгенерировать ключи Reality командой xray x25519. Результат — приватный и публичный ключи.
2. Выбрать сайт-донор (например, www.microsoft.com) и убедиться, что он доступен и находится в подходящем регионе.
3. Создать UUID для клиента (можно использовать команду xray uuid).

Серверный конфиг (фрагмент):

{
  "inbounds": [{
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [{"id": "your-uuid-here"}],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "xhttp",
      "security": "reality",
      "realitySettings": {
        "dest": "www.microsoft.com:443",
        "serverNames": ["www.microsoft.com"],
        "privateKey": "<PRIVATE_KEY>",
        "shortIds": ["<SHORT_ID>"]
      },
      "xhttpSettings": {
        "path": "/api/v1/data",
        "mode": "auto",
        "extra": {"xPaddingBytes": "100-1000"}
      }
    }
  }]
}

Клиентский конфиг (фрагмент):

{
  "outbounds": [{
    "protocol": "vless",
    "settings": {
      "vnext": [{
        "address": "your.domain.com",
        "port": 443,
        "users": [{"id": "your-uuid-here", "encryption": "none"}]
      }]
    },
    "streamSettings": {
      "network": "xhttp",
      "security": "reality",
      "realitySettings": {
        "serverName": "www.microsoft.com",
        "fingerprint": "chrome",
        "shortId": "<SHORT_ID>",
        "publicKey": "<PUBLIC_KEY>"
      },
      "xhttpSettings": {
        "path": "/api/v1/data",
        "mode": "auto",
        "extra": {"xPaddingBytes": "100-1000"}
      }
    }
  }]
}

Важно: версии Xray на клиенте и сервере должны совпадать, иначе XHTTP может работать нестабильно или вообще не работать.

DNS-over-VLESS: защита DNS-запросов через прокси

Обычные DNS-запросы часто остаются незашифрованными и могут быть перехвачены или подменены. Решение — направить DNS-трафик через VLESS-прокси. Этот метод называют DNS-over-VLESS.

Для реализации потребуется:

1. Добавить входящее подключение dokodemo-door с поддержкой UDP и TProxy.
2. В исходящих подключениях vless и freedom указать domainStrategy: "ForceIP".
3. Создать DNS-сервер в Xray (например, 8.8.8.8).
4. Добавить правила маршрутизации, чтобы DNS-запросы шли через прокси.

Пример inbounds.json:

{
  "inbounds": [{
    "port": 1181,
    "protocol": "dokodemo-door",
    "settings": {"network": "tcp,udp", "followRedirect": true},
    "sniffing": {"enabled": true, "routeOnly": true, "destOverride": ["http","tls"]},
    "streamSettings": {"sockopt": {"tproxy": "tproxy"}},
    "tag": "tproxy"
  }]
}

Пример dns.json:

{
  "dns": {
    "tag": "dns-in",
    "servers": ["8.8.8.8"],
    "queryStrategy": "UseIP"
  }
}

Пример routing.json (фрагмент):

{
  "routing": {
    "rules": [
      {"inboundTag": ["dns-in"], "outboundTag": "proxy"},
      {"port": 53, "outboundTag": "dns-out"},
      {"domain": ["browserleaks", "ip.me"], "outboundTag": "proxy"},
      {"network": "tcp,udp", "outboundTag": "direct"}
    ]
  }
}

После настройки DNS-запросы будут передаваться на VPS-сервер через зашифрованный VLESS-туннель, что защищает их от перехвата и подмены.

Практические рекомендации по выбору SNI-донора и проверке работоспособности

Выбор SNI-донора — критически важный шаг. Он должен быть:

• высоконагруженным (чтобы трафик не выделялся);
• находиться в том же регионе, что и сервер;
• иметь IP-адреса в известных ASN.

Хорошие доноры для Европы и России: github.com, www.twitch.tv, www.microsoft.com. Плохие — apple.com (собственные ASN) и любые мелкие сайты.

После настройки рекомендуется проверить:

1. JA3-отпечаток: зайти на сайт типа scrapfly.io/web-scraping-tools/ja3-fingerprint через прокси и сравнить с обычным браузером.
2. Активное зондирование: с другого IP выполнить curl -v https://your.domain.com --resolve your.domain.com:443:<YOUR_IP> — должен вернуться нормальный HTTP-ответ.
3. Поведенческий профиль: через несколько недель посмотреть на соотношение входящего и исходящего трафика. У реального веб-сервера исходящий трафик сильно превышает входящий.

Сравнение подходов: VLESS+Reality, VLESS+XHTTP, VLESS+XHTTP+Reality

В 2026 году выбор между Reality и XHTTP зависит от задач. Ниже — сравнение по ключевым параметрам.

• TLS-отпечаток: Reality даёт идеальный отпечаток, XHTTP — хороший (uTLS), комбинация — идеальный.
• Активное зондирование: все три варианта выдерживают.
• Поведенческий анализ: Reality уязвим при нагрузке, XHTTP устойчив, комбинация — лучшая.
• Работа через CDN: Reality не работает, XHTTP работает (packet-up), комбинация — частично.
• Совместимость с Vision: Reality — да, XHTTP — только stream-one, комбинация — только stream-one.
• Сложность настройки: Reality — средняя, XHTTP — средняя, комбинация — выше средней.
• Устойчивость в 2026: Reality снижается, XHTTP растёт, комбинация — лучшая.

Таким образом, для максимальной устойчивости рекомендуется использовать VLESS + XHTTP + Reality, но это требует более тщательной настройки и поддержания версий Xray в актуальном состоянии.

Ограничения и важные замечания при использовании VLESS и XHTTP

Несмотря на все преимущества, у VLESS и XHTTP есть ограничения.

Во-первых, XHTTP находится в активной разработке. Версии Xray на клиенте и сервере должны совпадать, иначе возможны сбои. Это не рекомендация, а обязательное условие.

Во-вторых, DNS-over-VLESS не работает при проксировании через CDN, если не добавить в DNS-секцию hosts запись с IP-адресом VPS. В противном случае запросы будут уходить на CDN-сервер, который не является DNS-резолвером.

В-третьих, использование REALITY с неправильно выбранным донором может привести к быстрой блокировке. Несоответствие SNI и ASN хостинга — одна из главных причин.

Наконец, не стоит забывать о юридических аспектах. В некоторых странах использование средств обхода блокировок может быть ограничено законодательством. Ответственность за применение описанных технологий лежит на пользователе.

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