VLESS XHTTP Reality: технология, настройка и сравнение с классическими схемами

Что такое XHTTP и зачем он нужен

XHTTP — это транспортный механизм, разработанный для Xray-core в 2024 году. Его ключевая идея — упаковка прокси-трафика в обычные HTTP-запросы (PUT/POST), которые внешне неотличимы от стандартных действий пользователя: загрузки файлов, отправки форм или вызовов API. В отличие от WebSocket или gRPC, XHTTP не требует специальных заголовков или фреймов, что делает его практически невидимым для систем глубокого анализа трафика.

Зачем это нужно? Классические схемы, такие как VLESS + Reality поверх TCP, создают долгоживущий TLS-туннель. Хотя Reality маскирует TLS-рукопожатие под реальный сайт, сам факт постоянного соединения с большим объёмом данных может быть выявлен по статистическим паттернам. XHTTP решает эту проблему, разбивая трафик на отдельные HTTP-запросы, каждый из которых выглядит как обычное действие браузера.

Важно понимать: XHTTP — это не самостоятельный протокол, а транспорт, который обычно используется вместе с VLESS. Он может работать как через CDN, так и напрямую к серверу, и в обоих случаях даёт преимущества в маскировке.

Три режима работы XHTTP: packet-up, stream-up, stream-one

XHTTP поддерживает три режима, которые определяют, как именно данные передаются между клиентом и сервером.

packet-up — самый совместимый режим. Данные от клиента к серверу отправляются множеством коротких HTTP-запросов, а обратно — одним длинным потоком. Это напоминает работу транспорта meek из Tor, но значительно быстрее. Режим подходит для любых веб-серверов и CDN, но имеет наибольшие накладные расходы.

stream-up — более скоростной режим, где и входящий, и исходящий трафик передаются через долгоживущие соединения. Требует поддержки потоковой передачи на промежуточных устройствах, поэтому совместимость ниже.

stream-one — самый производительный режим, в котором данные в обе стороны передаются по одному HTTP/2-потоку. По сути, это аналог старого VLESS с HTTP-заголовком, но с улучшенной маскировкой. Работает только через Nginx с grpc_pass или Cloudflare с включённой поддержкой gRPC (хотя фактически gRPC не используется).

При использовании XHTTP с Reality по умолчанию выбирается режим stream-one, если не указано иное. В конфигурации можно задать mode: auto, чтобы Xray сам выбирал оптимальный режим в зависимости от сети.

Преимущества XHTTP перед WebSocket и gRPC

WebSocket и gRPC долгое время были основными транспортами для маскировки прокси, но у каждого есть уязвимости.

WebSocket требует заголовков Upgrade: websocket и Connection: Upgrade, которые сразу выделяют соединение на фоне обычного веб-трафика. Кроме того, после установки соединения создаётся постоянный двунаправленный канал, чей паттерн (много мелких пакетов, постоянная активность) легко отличить от обычного просмотра сайтов.

gRPC использует специфический content-type: application/grpc, который практически не встречается у обычных пользователей. Дополнительно gRPC-фреймы имеют уникальную структуру с 5-байтовым префиксом длины, что служит дополнительным признаком для детектирования.

XHTTP лишён этих недостатков: он использует стандартные HTTP-запросы с обычными content-type, не имеет специальных заголовков и может работать в режиме без длинных соединений. С точки зрения DPI, это просто пользователь, загружающий файлы или общающийся с API. По сравнению с WebSocket и gRPC, XHTTP значительно сложнее обнаружить.

Роль XMUX в мультиплексировании и ротации соединений

Поскольку XHTTP разбивает трафик на множество HTTP-запросов, без оптимизации каждый запрос требовал бы отдельного TCP- и TLS-рукопожатия, что сильно увеличило бы задержки. Для решения этой проблемы был создан XMUX (eXtended Multiplexing).

XMUX позволяет нескольким прокси-потокам использовать одно общее HTTP/2-соединение. HTTP/2 изначально поддерживает мультиплексирование, и XMUX использует эту возможность: множество XHTTP-запросов передаются параллельно по одному каналу, экономя ресурсы и снижая задержки.

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

• maxConcurrency — максимальное число одновременных потоков на одном соединении;
• maxConnections — максимальное число параллельных соединений;
• cMaxReuseTimes — сколько раз можно переиспользовать соединение перед закрытием;
• cMaxLifetimeMs — максимальное время жизни соединения.

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

Совместимость XHTTP с Reality и ограничения

XHTTP отлично сочетается с Reality — технологией, которая маскирует TLS-соединение под реальный сайт, используя его настоящий сертификат. При использовании XHTTP + Reality клиент подключается с SNI какого-либо популярного домена, и сервер отвечает настоящим сертификатом этого домена, что делает соединение неотличимым от обычного HTTPS-запроса.

Однако есть важное ограничение: XHTTP несовместим с XTLS-Vision. Vision — это технология, которая используется в классической схеме VLESS + Reality + TCP для оптимизации передачи данных. В XHTTP защита от детектирования TLS-in-TLS обеспечивается за счёт мультиплексирования XMUX и разделения потоков, поэтому использование Vision невозможно. В конфигурации параметр flow должен быть пустым — это самая частая ошибка при миграции с TCP-схемы.

Ещё одно ограничение: XHTTP требует одинаковых версий Xray на клиенте и сервере. Протокол активно развивается, и расхождение версий может привести к сбоям или полной неработоспособности. Рекомендуется использовать последнюю стабильную версию Xray-core на обеих сторонах.

Подготовка сервера: установка Xray и генерация ключей

Для развёртывания XHTTP + Reality на Ubuntu 24.04 потребуется VPS с административным доступом, открытый порт TCP/443 и точное системное время (допускается отклонение не более 60 секунд).

Установка Xray выполняется через официальный скрипт, но перед запуском его нужно скачать и проверить, чтобы не выполнять неизвестный код от имени root. Рекомендуется устанавливать конкретную версию, например v26.3.27, чтобы избежать случайного обновления до нестабильной версии. Скрипт создаёт системного пользователя xray, проверяет SHA-256 сумму архива и может быть запущен без создания файловых логов (логи будут доступны через systemd journal).

После установки необходимо сгенерировать учётные данные:

• UUID для клиента VLESS — команда /usr/local/bin/xray uuid;
• пара ключей X25519 для Reality — команда /usr/local/bin/xray x25519 (выводит private key и public key);
• короткий идентификатор (shortId) — команда openssl rand -hex 8;
• случайный путь для XHTTP — команда openssl rand -hex 16.

Все эти данные нужно сохранить в надёжном месте. Важно: private key никогда не должен попадать в клиентскую конфигурацию или QR-код, только в серверную часть. Public key (Password) передаётся клиенту.

Выбор и проверка целевого сайта для Reality

Reality маскирует трафик под реальный сайт, поэтому важно правильно выбрать целевой хост (target). Это должен быть популярный сайт с поддержкой TLS 1.3 и HTTP/2, который не вызывает подозрений. Нельзя просто скопировать имя из чужого туториала — нужно проверить, что сайт действительно доступен с вашего сервера и что его сертификат принимает нужный SNI.

Для проверки используется команда /usr/local/bin/xray tls ping :443, которая выполняет TLS-рукопожатие и показывает, какие домены разрешены в сертификате. Если рукопожатие успешно и нужный SNI присутствует, можно использовать этот хост.

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

Конфигурация сервера: профили TCP+Reality+Vision и XHTTP+Reality

Рекомендуется хранить два профиля конфигурации: основной — TCP + Reality + Vision, и альтернативный — XHTTP + Reality. Оба используют порт 443, но одновременно может работать только один. Это позволяет быстро переключаться между схемами в зависимости от ситуации.

Профиль TCP + Reality + Vision — классическая схема, которая остаётся надёжной и производительной. В конфигурации указывается network: tcp, security: reality, а в настройках клиента — flow: xtls-rprx-vision. Этот профиль подходит для большинства сценариев, включая игры и стриминг, где важна низкая задержка.

Профиль XHTTP + Reality — использует network: xhttp, xhttpSettings с путём и режимом, а flow оставляется пустым. В тестах использовался режим stream-one, который выбирается автоматически при использовании Reality, но в клиентской ссылке его указывали явно, чтобы избежать проблем с импортом в некоторых GUI.

Оба профиля должны храниться в каталоге с правами root (например, /usr/local/etc/xray/profiles), а активный файл — в /usr/local/etc/xray/config.json. Для переключения можно написать скрипт, который проверяет конфигурацию перед активацией, перезапускает службу и откатывает изменения при сбое.

Настройка клиента и проверка работоспособности

Клиент должен поддерживать XHTTP. Наиболее полная поддержка — в Xray-core и основанных на нём GUI (v2rayN, v2rayNG). Sing-box имеет частичную поддержку, но XMUX может работать некорректно. Перед использованием убедитесь, что версия клиента совпадает с серверной.

Клиентская конфигурация для XHTTP + Reality включает:

• адрес сервера и порт 443;
• UUID и public key (Password) от Reality;
• SNI — тот же домен, что и target на сервере;
• путь (path) — должен совпадать с серверным;
• режим XHTTP — рекомендуется auto или stream-one;
• client-fingerprint — например, chrome для имитации браузера.

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

• совпадение версий Xray на клиенте и сервере;
• правильность пути и SNI;
• отсутствие flow в XHTTP-профиле;
• доступность порта 443 снаружи (фаервол).

Также стоит проверить, что системное время на сервере и клиенте синхронизировано, иначе Reality может не пройти аутентификацию.

Сравнение XHTTP с другими транспортами и рекомендации

Выбор транспорта зависит от ваших приоритетов: максимальная скрытность, производительность или совместимость с CDN.

TCP + Reality + Vision — классика, которая остаётся отличным выбором для большинства пользователей. Она проста в настройке, имеет минимальные накладные расходы и хорошо работает в играх и стриминге. Если вас не беспокоит детектирование по длительности соединений, этот вариант оптимален.

XHTTP + Reality + XMUX — технологический максимум на 2026 год. Он обеспечивает наилучшую маскировку за счёт разбиения трафика на HTTP-запросы и ротации соединений. Подходит для регионов с агрессивным DPI, где длинные TLS-туннели блокируются. Недостатки — более высокая сложность настройки и несовместимость с Vision.

WebSocket — по-прежнему лучший выбор для CDN-транзита, так как большинство CDN поддерживают WebSocket. Однако его легко детектировать по заголовкам, поэтому для прямых подключений он менее предпочтителен.

gRPC — имеет специфический content-type, что делает его уязвимым для DPI. Используется редко, в основном для специфических задач.

Рекомендация: если вы новичок, начните с TCP + Reality + Vision. Если вам нужна максимальная скрытность и вы готовы разбираться, переходите на XHTTP + Reality. В любом случае, следите за обновлениями Xray и тестируйте конфигурацию после изменений.

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