Xray в 2026: XHTTP и VLESS Encryption

За 2026 год Xray заметно поменялся: голый VLESS без защиты теперь запрещён самим ядром, появилось встроенное шифрование VLESS Encryption, а транспорт XHTTP стал основным способом пройти через обратные прокси и CDN. Ниже то, что стоит знать владельцу личного сервера, и рабочая схема с XHTTP за nginx на сервере, где уже настроен self-steal.

Xray на OBLAKO

Свой Xray с XHTTP или Reality на OBLAKO держать разрешено, если сервер служит вам и вашим близким, а в SNI стоит ваш собственный домен. Серверы с сертификатом популярного чужого сайта система выключает автоматически. Надёжнее всего схема из наших инструкций: собственный домен, свой сайт на nginx и self-steal. Полный текст правил на странице AUP.

Статья опирается на исходный код и документацию Xray-core версии 26.10.31 (последний релиз на начало ноября 2026 года).

Сначала обновитесь

Два последних релиза Xray вышли как срочные исправления безопасности:

• 26.10.21 убрал из встроенного списка три корневых сертификата: ключи выпущенных под ними промежуточных сертификатов оказались взломаны. Старые сборки могут доверять поддельным сертификатам, если в системе устаревший список CA.
• 26.10.31 по умолчанию выключил MPTCP. В ядре Linux нашли уязвимость, через которую прослушивание MPTCP позволяло получить root удалённо, а Go с версии 1.24 включает MPTCP сам. Касается и серверов, и Android-клиентов с открытым для локальной сети входом.

Промежуточные сборки 26.10.10, 26.10.17 и 26.10.29 авторы отозвали. Если у вас одна из них, обновитесь. На сервере с официальным установщиком это одна команда:

bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install
xray version

Если Xray стоит внутри панели 3x-ui, обновите его на странице Дашборд через Выбор версии: 3x-ui 3.11.0 сама ставит Xray 26.10.21, без исправления MPTCP. Ядро Linux тоже стоит обновить: apt update && apt upgrade -y и перезагрузка.

Голый VLESS больше не запускается

VLESS сам по себе ничего не шифрует, он рассчитан на работу поверх TLS или Reality. Раньше ничто не мешало настроить его без защиты, и такие конфиги массово раздавались в сети. Теперь клиент Xray отказывается так подключаться. При загрузке конфига вы увидите ошибку:

vless without TLS or other encryption is prohibited unless the server address is a private IP or domain

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

• у исходящего подключения VLESS нет security (ни tls, ни reality);
• не включён VLESS Encryption;
• адрес сервера публичный, то есть не 127.0.0.1, не адрес из частных сетей вроде 10.x или 192.168.x и не локальное имя.

Для Trojan без TLS действует такое же правило. Если вы подключаетесь по Reality или TLS, как в наших инструкциях, ничего делать не нужно.

Ещё одно изменение, о котором стоит знать заранее: VLESS без flow объявлен устаревшим. Разработчики предупредили, что его будут переводить на режим с Vision. Если в вашей ссылке нет flow=xtls-rprx-vision при транспорте tcp (raw), стоит добавить его, пока это не стало обязательным.

VLESS Encryption

VLESS Encryption это шифрование внутри самого протокола, без TLS. Обмен ключами в нём гибридный, на основе X25519 и постквантового ML-KEM-768, есть защита от повторов и одноразовые сессии. Его можно использовать как второй слой поверх любого транспорта или как основную защиту там, где TLS снаружи нет.

Важно понимать, чего он не даёт. Шифрование скрывает содержимое, но не делает трафик похожим на обычный сайт. Маскировку по-прежнему обеспечивают Reality или TLS с вашим доменом.

Как включить

Пару настроек генерирует сам Xray:

xray vlessenc

Команда выводит сразу два варианта, каждый из пары строк decryption для сервера и encryption для клиента. Первый вариант использует для проверки сервера ключ X25519, второй постквантовый ML-KEM-768 (строки у него заметно длиннее). Выберите один и не смешивайте строки из разных вариантов. Обмен ключами для самой сессии постквантовый в обоих случаях.

Строки выглядят так: mlkem768x25519plus.native.600s.КЛЮЧ у сервера и mlkem768x25519plus.native.0rtt.КЛЮЧ у клиента. После названия метода идёт режим (native), затем у сервера время жизни сессии для быстрого повторного подключения, а у клиента разрешение этим подключением пользоваться (0rtt). Собирать строки вручную не нужно, берите готовые.

На сервере значение вставляется в настройки входящего VLESS вместо "decryption": "none". У клиента значение encryption пишется в настройки пользователя вместо "encryption": "none". Строки должны быть из одной пары, иначе клиент не пройдёт рукопожатие.

Два ограничения:

• поле decryption нельзя оставлять пустым. Если шифрование не нужно, явно пишите "none", иначе Xray не запустится с ошибкой please add/set "decryption":"none" to every settings;
• при включённом шифровании на входящем подключении нельзя использовать fallbacks.

Зато режим Vision (xtls-rprx-vision) с VLESS Encryption работает на любом транспорте, а не только на TCP с TLS или Reality.

XHTTP: что это и какой режим выбрать

XHTTP это транспорт, который превращает туннель в обычные HTTP-запросы: загрузки идут POST-запросами, ответы приходят потоком. Такой трафик спокойно проходит через nginx, Caddy и CDN, которые понимают HTTP, а наружу выглядит как работа обычного веб-приложения. Подробное описание от автора есть в обсуждении XHTTP: Beyond REALITY.

У XHTTP три режима передачи:

Режим	Как идут данные	Где уместен
packet-up	исходящие данные режутся на отдельные POST-запросы, входящие идут потоком	самый совместимый: проходит через любые HTTP-прокси и CDN
stream-up	и отправка, и получение потоком, двумя запросами	HTTP/2 до сервера без посредников, которые буферизуют тело запроса
stream-one	всё в одном двунаправленном запросе	прямое подключение через Reality

По умолчанию стоит auto. В исходниках Xray 26.10.31 клиент в этом режиме выбирает так: с Reality берёт stream-one (или stream-up, если задан отдельный канал загрузки downloadSettings), во всех остальных случаях, включая TLS с HTTP/2, берёт packet-up. Сервер в режиме auto принимает все три. Для схемы ниже менять ничего не нужно: мы проверили её в режиме auto, клиент сам выбрал packet-up.

Схема: XHTTP за nginx на сервере с self-steal

Если вы настроили self-steal, у вас уже есть всё нужное: домен, сертификат и nginx на 127.0.0.1:8443, к которому Reality отправляет посторонних. На этот же nginx можно повесить XHTTP по секретному пути. Получится второй, независимый вход на тот же сервер:

• обычный клиент Reality подключается как раньше;
• клиент XHTTP подключается к вашему домену по обычному TLS. Reality не узнаёт в нём своего и пересылает соединение на nginx, а nginx по секретному пути отдаёт его Xray.

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

Шаг 1. Добавьте входящее подключение XHTTP

В конфиг Xray (/usr/local/etc/xray/config.json) добавьте в массив inbounds ещё один объект. Он слушает только локальный адрес, поэтому TLS ему не нужен: шифрование обеспечивает nginx.

{
  "listen": "127.0.0.1",
  "port": 10080,
  "protocol": "vless",
  "settings": {
    "clients": [{ "id": "ВАШ_UUID" }],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "xhttp",
    "xhttpSettings": { "path": "/СЕКРЕТНЫЙ_ПУТЬ", "mode": "auto" }
  }
}

UUID можно взять тот же, что у Reality, или создать новый командой xray uuid. Путь придумайте длинный и бессмысленный, например из openssl rand -hex 8. В новых версиях документации массив пользователей называется users, старое имя clients тоже работает.

Шаг 2. Отдайте путь из nginx

В блок server вашего сайта на 127.0.0.1:8443 добавьте location с тем же путём:

location /СЕКРЕТНЫЙ_ПУТЬ {
    client_max_body_size 0;
    client_body_timeout 5m;
    grpc_read_timeout 1h;
    grpc_send_timeout 1h;
    grpc_pass grpc://127.0.0.1:10080;
}

Почему grpc_pass, а не привычный proxy_pass: так nginx общается с Xray по HTTP/2, как советует автор XHTTP в обсуждении 4113, и запросы ходят без лишнего перевода между версиями протокола. Буферизацию ответов Xray выключает сам: он отправляет nginx заголовок X-Accel-Buffering: no.

Ваш сайт уже слушает 127.0.0.1:8443 с HTTP/2 (ssl http2), без этого схема не заработает.

Проверьте конфиги и перезапустите службы:

xray run -test -c /usr/local/etc/xray/config.json
nginx -t
systemctl restart xray
systemctl reload nginx

Шаг 3. Подключите клиента

Клиенту нужна ссылка с TLS, а не с Reality: он должен выглядеть как обычный браузер, который идёт на ваш сайт.

vless://ВАШ_UUID@ВАШ_ДОМЕН:443?encryption=none&security=tls&sni=ВАШ_ДОМЕН&fp=chrome&alpn=h2&type=xhttp&path=%2FСЕКРЕТНЫЙ_ПУТЬ&mode=auto#oblako-xhttp

flow здесь не указывается: без VLESS Encryption сервер отклонит Vision на XHTTP с ошибкой XTLS only supports TLS and REALITY directly for now. XHTTP понимают клиенты на ядре Xray: v2rayN, v2rayNG, Happ. Клиенты на ядре sing-box, например Hiddify, такую ссылку могут не принять. Если клиент не подключается, первым делом проверьте, что путь в ссылке совпадает с путём в Xray и в nginx до символа.

Если хочется ещё и VLESS Encryption

Сгенерируйте пару xray vlessenc, на сервере в XHTTP-подключении замените "decryption": "none" на строку decryption, а в ссылке клиента encryption=none на строку encryption. Тогда даже при компрометации TLS содержимое останется зашифрованным, а Vision станет доступен и на XHTTP.

Что ещё полезно знать

• Xray предупреждает в логе, если Reality слушает не 443-й порт: на других портах такой сервер заметнее.
• В Reality поле target теперь основное имя, dest оставлен как синоним. У клиента публичный ключ сервера в новых версиях называется password, старое publicKey понимается по-прежнему.
• Сломалось после обновления: сверьте версии ядра на сервере и в клиенте и пройдите по шагам статьи VLESS Reality перестал работать.