VLESS XHTTP Reality GitHub: настройка, режимы и примеры конфигураций

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

XHTTP — это транспортный механизм для прокси-протоколов, разработанный в экосистеме Xray. Он появился как развитие идей, заложенных в транспорте meek из проекта Tor, и предназначен для маскировки прокси-трафика под обычные HTTP-запросы. В отличие от полноценного протокола, XHTTP работает на уровне транспорта, то есть определяет, как именно данные передаются между клиентом и сервером, а не какой протокол используется внутри.

Основная задача XHTTP — сделать трафик неотличимым от обычного веб-серфинга. Это достигается за счёт того, что данные разбиваются на множество коротких HTTP-запросов и ответов, которые выглядят как обращения к веб-серверу. Такой подход позволяет обходить блокировки, которые анализируют характерные признаки прокси-соединений, например, длительные подключения к одному IP-адресу или нестандартные TLS-отпечатки.

XHTTP чаще всего используется вместе с протоколом VLESS, который обеспечивает шифрование и аутентификацию. В связке с REALITY — технологией, которая маскирует сервер под легитимный веб-сайт, — XHTTP создаёт многоуровневую защиту от детектирования. При этом XHTTP можно применять и без REALITY, например, при подключении через CDN, где маскировка обеспечивается самим CDN.

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

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

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

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

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

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

Выбор режима зависит от конкретной задачи. Если нужна максимальная совместимость — выбирайте packet-up. Если важна скорость и вы контролируете сервер — stream-up. stream-one подойдёт для простых конфигураций с Nginx или Cloudflare.

Преимущества XHTTP перед другими транспортами

XHTTP предлагает несколько ключевых преимуществ, которые делают его привлекательным для обхода блокировок и повышения безопасности.

Поддержка QUIC. XHTTP может работать через QUIC (протокол на основе UDP), если на клиенте явно указать ALPN h3. Это позволяет использовать преимущества QUIC: более быструю установку соединения, устойчивость к потере пакетов и меньшую задержку. В некоторых сетях QUIC может быть не заблокирован, даже если HTTPS заблокирован, что даёт дополнительную возможность для обхода.

Аутентичный TLS-отпечаток. При использовании XHTTP с TLS 1.2 можно получить отпечаток (fingerprint) настоящего веб-сервера. Это достигается тем, что на 443 порту работает реальный веб-сервер (например, Nginx), а Xray находится за ним. В результате TLS-отпечаток сервера неотличим от отпечатка обычного сайта, что затрудняет детектирование.

Работа через CDN. XHTTP может работать через CDN, которые не поддерживают WebSocket или gRPC. Это расширяет возможности выбора CDN и позволяет использовать domain fronting — технику, при которой запросы направляются на один домен, а фактически обслуживаются другим. Это делает маскировку ещё более эффективной.

Browser dialer. XHTTP поддерживает browser dialer — механизм, при котором клиент подключается к прокси через браузер. Это позволяет использовать настоящий браузер в качестве клиента, что делает отпечаток клиента идеальным. Такой подход практически исключает детектирование по клиентскому fingerprint.

Разделение потоков. В режимах packet-up и stream-up данные передаются по разным соединениям, что затрудняет анализ трафика. Можно настроить разные пути для входящего и исходящего трафика: например, отправлять данные через QUIC, а получать через HTTPS, или использовать разные IP-адреса и даже разные серверы. Это создаёт дополнительные сложности для систем анализа и блокировки.

Как XHTTP сочетается с REALITY и Vision

XHTTP и REALITY — это две технологии, которые решают схожие задачи, но на разных уровнях. REALITY маскирует сервер под легитимный сайт, подменяя TLS-отпечаток и используя настоящие сертификаты. XHTTP маскирует сам трафик, разбивая его на HTTP-запросы. Вместе они создают многоуровневую защиту.

Важно знать, что XHTTP нельзя использовать с XTLS-Vision. Vision — это технология, которая оптимизирует передачу данных, но она несовместима с XHTTP из-за особенностей реализации. Вместо этого XHTTP использует собственный механизм мультиплексирования XMUX, который обеспечивает защиту от детектирования TLS-in-TLS.

XHTTP можно использовать с REALITY. В этом случае по умолчанию выбирается режим stream-one, если явно не указано другое. Это означает, что при настройке XHTTP + REALITY нужно учитывать, что stream-one требует поддержки gRPC на сервере (Nginx или Cloudflare). Если вы хотите использовать другие режимы, это нужно указать в конфигурации.

На практике связка XHTTP + REALITY позволяет получить максимальную маскировку: REALITY скрывает сервер, а XHTTP скрывает трафик. Однако такая конфигурация сложнее в настройке и требует более новых версий Xray. Поэтому для большинства пользователей рекомендуется использовать проверенную связку VLESS + TCP + REALITY + Vision, а XHTTP оставить для экспериментов.

Настройка XHTTP на сервере: пошаговое руководство

Для настройки XHTTP на сервере потребуется установить Xray и сконфигурировать его. Рассмотрим базовую конфигурацию для работы XHTTP с REALITY.

Сначала установите Xray. Это можно сделать через официальный скрипт или вручную. После установки отредактируйте файл конфигурации /etc/xray/config.json. Пример конфигурации для входящего соединения с XHTTP и REALITY:

{
  "inbounds": [
    {
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "UUID",
            "flow": "xtls-rprx-vision"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "reality",
        "realitySettings": {
          "dest": "example.com:443",
          "serverNames": ["example.com"],
          "privateKey": "PRIVATE_KEY",
          "shortIds": ["SHORT_ID"]
        },
        "xhttpSettings": {
          "mode": "stream-one"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom"
    }
  ]
}

Обратите внимание, что в этом примере используется flow: xtls-rprx-vision, но, как упоминалось, XHTTP несовместим с Vision. В реальной конфигурации для XHTTP нужно использовать flow: "" (пустое значение) или не указывать его вовсе. Также важно, чтобы версии Xray на клиенте и сервере совпадали, иначе возможны ошибки.

После сохранения конфигурации перезапустите Xray и проверьте логи. Если всё настроено правильно, соединение должно установиться. Для проверки можно использовать клиент, например, v2rayNG или v2raN, и попробовать подключиться к серверу.

Настройка клиента для XHTTP

Клиентская настройка XHTTP зависит от используемого приложения. Наиболее популярные клиенты на базе Xray — v2rayNG (Android), v2raN (Windows) и другие. Они поддерживают XHTTP без дополнительных модулей.

В клиенте необходимо указать следующие параметры:

• Адрес сервера — IP или домен.
• Порт — обычно 443.
• Протокол — VLESS.
• UUID — идентификатор пользователя.
• Транспорт — XHTTP.
• Режим XHTTP — packet-up, stream-up или stream-one (должен совпадать с серверным).
• Security — reality (если используется REALITY).
• SNI — домен, на который маскируется сервер.
• Public Key — публичный ключ REALITY.
• Short ID — короткий идентификатор.
• Fingerprint — например, chrome.

Если вы используете browser dialer, то в клиенте нужно указать адрес локального браузера, который будет использоваться для подключения. Это делается через настройки транспорта.

Важно, чтобы версии Xray на клиенте и сервере были одинаковыми. Разработчики активно развивают XHTTP, и несовместимость версий может привести к сбоям. Поэтому перед обновлением клиента убедитесь, что сервер также обновлён.

Клиенты на базе Sing-box не поддерживают XHTTP, поэтому для использования этой технологии нужно выбирать клиенты на базе Xray.

Примеры конфигураций из GitHub

В репозитории xray-examples на GitHub можно найти официальные примеры конфигураций для XHTTP. Эти примеры помогут быстро разобраться в настройке и избежать типичных ошибок.

Один из примеров показывает настройку XHTTP с REALITY на сервере и клиенте. В нём используются следующие параметры:

• Сервер: порт 443, протокол VLESS, транспорт XHTTP, режим stream-one, security reality.
• Клиент: те же параметры, но с указанием публичного ключа и SNI.

Также в репозитории есть примеры для Nginx, которые показывают, как настроить веб-сервер для работы с XHTTP. Это необходимо, если вы используете режим stream-one, так как он требует поддержки gRPC.

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

Кроме того, на GitHub можно найти сторонние проекты, которые упрощают настройку XHTTP. Например, генераторы конфигураций, которые автоматически создают файлы для клиента и сервера. Один из таких генераторов упоминается в инструкции по настройке Xray на OpenWrt с Podkop. Он позволяет сгенерировать конфиг, который затем нужно вставить в файл /etc/xray/config.json.

XHTTP на роутерах с OpenWrt и Podkop

XHTTP можно использовать не только на компьютерах и смартфонах, но и на роутерах с OpenWrt. Это позволяет организовать проксирование всего трафика в локальной сети без настройки каждого устройства отдельно.

Для установки Xray на OpenWrt выполните команды:

opkg update
opkg install xray-core nano

Затем сгенерируйте конфигурацию с помощью онлайн-генератора или вручную и сохраните её в файл /etc/xray/config.json. После этого создайте скрипт инициализации, который будет запускать Xray при загрузке роутера. Пример такого скрипта можно найти в инструкции по настройке Podkop.

Podkop — это инструмент для маршрутизации трафика на OpenWrt. Он позволяет направлять трафик через прокси в зависимости от правил. Для интеграции с Xray нужно настроить исходящее соединение в Podkop, указав SOCKS5-прокси на 127.0.0.1:10808 (порт, на котором слушает Xray).

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

curl --socks5 127.0.0.1:10808 https://ifconfig.me

Если вы увидите IP-адрес вашего сервера, значит, всё работает. Такая схема позволяет использовать XHTTP на всей домашней сети, включая устройства, которые не поддерживают настройку прокси.

Ограничения и подводные камни XHTTP

Несмотря на все преимущества, XHTTP имеет ряд ограничений, которые важно учитывать.

Несовместимость с Vision. Как уже упоминалось, XHTTP нельзя использовать с XTLS-Vision. Это ограничение связано с архитектурными различиями. Если вам нужна максимальная производительность, лучше использовать классическую связку VLESS + TCP + REALITY + Vision.

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

Совместимость с клиентами. Не все клиенты поддерживают XHTTP. Клиенты на базе Sing-box не работают с XHTTP. Поэтому нужно выбирать клиенты на базе Xray, например, v2rayNG или v2raN.

Сложность настройки. XHTTP имеет больше параметров, чем обычный TCP-транспорт. Это увеличивает вероятность ошибок при настройке. Для новичков рекомендуется начинать с более простых конфигураций.

Производительность. В режиме packet-up скорость может быть ниже, чем у других транспортов, из-за накладных расходов на множество коротких соединений. stream-up быстрее, но требует поддержки длительных соединений.

Ограничения CDN. Не все CDN поддерживают длительные соединения, необходимые для stream-up. stream-one работает только с Nginx и Cloudflare. Поэтому выбор режима зависит от используемого CDN.

Сравнение XHTTP с классической связкой VLESS + TCP + REALITY + Vision

Многие пользователи задаются вопросом, что выбрать: современный XHTTP или проверенную временем связку VLESS + TCP + REALITY + Vision. Ответ зависит от ваших приоритетов.

Стабильность. Классическая связка считается более стабильной, так как она использует меньше переменных и имеет больше документации. XHTTP — более новая технология, которая может содержать ошибки и требовать частых обновлений.

Совместимость. Классическая связка поддерживается практически всеми клиентами, включая Sing-box. XHTTP требует клиентов на базе Xray и не работает с Vision.

Маскировка. XHTTP обеспечивает более высокий уровень маскировки благодаря разделению потоков и возможности использования CDN. Это делает его более устойчивым к детектированию.

Производительность. В режиме stream-up XHTTP может быть быстрее, чем классическая связка, особенно при нестабильном соединении. Однако в режиме packet-up скорость ниже.

Сложность настройки. Классическая связка проще в настройке, так как требует меньше параметров. XHTTP требует более тщательной настройки и понимания режимов работы.

В итоге, если ваша цель — максимальная стабильность и простота, выбирайте классическую связку. Если вы готовы к экспериментам и нужна максимальная маскировка, попробуйте XHTTP. Многие эксперты рекомендуют использовать классическую связку в качестве основного узла, а XHTTP — как дополнительный для особых случаев.

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