Как ТСПУ ловит VLESS в 2026 и почему XHTTP

Разбор методов детекции, которые работают прямо сейчас. JA3/JA4-отпечатки, поведенческий анализ и архитектура XHTTP, которая закрывает именно эти дыры

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

Как пакет проходит через ТСПУ: слои детекции

Прежде чем разбирать почему падает Reality нужно понять архитектуру того, что её обнаруживает.

ТСПУ работает не как один монолитный фильтр. Это несколько последовательных слоёв проверки, каждый из которых дороже предыдущего по вычислительным ресурсам. Дешёвые проверки идут первыми.

Слой 1: сигнатурный анализ.
Первые 16–32 байта пакета сверяются с базой известных паттернов. Это быстро и дёшево. Чистый Shadowsocks умирает здесь: его первый байт статистически отличается от TLS. OpenVPN умирает здесь же — характерное рукопожатие, 16 байт, блокировка.

VLESS с нормальным TLS эту проверку проходит первые байты идентичны обычному HTTPS.

Слой 2: TLS-fingerprinting (JA3/JA4).
Это уже интереснее. JA3 — хэш, который вычисляется из параметров TLS ClientHello: список cipher suites, список TLS-расширений, поддерживаемые elliptic curves, форматы точек — всё в определённом порядке, всё конкатенируется и хэшируется в MD5.

Формула будет простая:

JA3 = MD5(SSLVersion, Ciphers, Extensions, EllipticCurves, EllipticCurvePointFormats)

Реальный Chrome 120 на Windows 11 имеет конкретный JA3-хэш. Если твой прокси-клиент использует собственную TLS-библиотеку — его хэш будет другим. Не «похожим на нехороший» — просто другим, и это уже аномалия.

JA4 — более новая версия того же подхода от FoxIO (2023). Менее чувствителен к порядку расширений, более устойчив к рандомизации, лучше классифицирует. Именно JA4 сейчас активно внедряется в промышленные DPI-системы.

Слой 3: активное зондирование.
Если предыдущие слои дали неопределённый результат — система отправляет к серверу разведчика. Пробует поговорить на HTTP, HTTPS, разных версиях TLS. Если сервер ведёт себя как легитимный веб-сайт — пропускает. Если не отвечает или отвечает нетипично — блокировка.

Слой 4: поведенческий анализ соединения.
Самый дорогой. Анализируется не содержимое пакетов, а их поведение во времени. Именно здесь Reality начинает проигрывать — и к этому мы вернёмся.

JA3/JA4: почему «fingerprint: chrome» — это не опция, это необходимость

Чтобы понять масштаб проблемы — небольшой эксперимент.

Зайди на scrapfly.io/web-scraping-tools/ja3-fingerprint из обычного Chrome и запомни хэш. Теперь подключись через Xray без параметра fingerprint и зайди снова. Хэши будут разными.

Xray без fingerprint: chrome использует Go-стандартную TLS-библиотеку (crypto/tls). У неё другой набор cipher suites, другой порядок расширений. JA3-хэш Go-клиента хорошо известен — он встречается в базах детекции.

С "fingerprint": "chrome" (или "firefox", "safari") Xray использует uTLS — библиотеку, которая буквально копирует ClientHello настоящего браузера вплоть до байта. JA3 совпадает с реальным Chrome. Это не «похоже на Chrome» — это Chrome.

Важный нюанс из 2024 года: браузеры начали рандомизировать порядок TLS-расширений. Это сделало JA3 менее уникальным как инструмент идентификации конкретного браузера. Но для детекции «это не браузер вообще» — JA3 по-прежнему работает отлично. Кастомный TLS-стек всё равно виден.

Reality: что она решала и почему перестало хватать

Reality появилась как ответ на JA3-детекцию.

Предыдущая проблема была именно там: даже при использовании fingerprint: chrome — TLS-сессия завершается на твоём сервере. Сертификат твоего сервера. DPI-система делает активное зондирование, получает сертификат, смотрит на ASN и IP-адрес сертификата — и видит что это не iCloud и не Spotify.

Reality решила это радикально: TLS-сессия буквально завершается на реальном сервере Apple или Microsoft. Клиент делает настоящее рукопожатие с настоящим icloud.com. Получает настоящий сертификат Apple, верифицированный через реальную цепочку CA. После завершения рукопожатия данные туннеля вшиваются в уже установленную сессию.

С точки зрения любого анализатора первых трёх слоёв: идеальный, верифицируемый TLS к Apple. JA3 совпадает. Сертификат настоящий. Активное зондирование возвращает нормальный ответ.

Это было сильно. В 2022–2023 Reality работала почти без исключений.

Но в 2025 году в Санкт-Петербургском политехническом университете была защищена работа именно по детекции XTLS-Reality.
Методы, которые там описаны, перекликаются с тем, что фиксируют пользователи на практике:

GREASE-анализ. GREASE (Generate Random Extensions And Sustain Extensibility) — механизм Chrome для проверки совместимости TLS-серверов. Реальный Chrome вставляет случайные «мусорные» расширения в ClientHello. Xray с fingerprint: chrome имитирует это — но паттерн имитации не всегда совпадает с тем, что генерирует текущая версия Chrome.

IP/ASN несоответствие. Если клиент говорит «я iCloud», но IP-адрес сервера принадлежит датскому хостинг-провайдеру — это аномалия. Apple держит свои серверы в конкретных ASN. Хостинг на Hetzner с SNI icloud.com — детектируемое несоответствие.

Поведение после рукопожатия. Реальное iCloud-соединение от реального iPhone или Mac имеет характерный паттерн запросов: конкретные API-эндпоинты, конкретные заголовки, конкретные тайминги. VLESS-туннель, гоняющий через это соединение произвольный трафик, ведёт себя иначе. Постоянный двунаправленный поток без пауз, нетипичные размеры пакетов, отсутствие характерных для iCloud API-запросов.

Глава, которую обычно не пишут :)

Вот неудобная правда про Reality в 2026-м.

Рукопожатие идеальное. Детекция идёт не по нему. Детекция идёт по поведению соединения после него — и здесь Reality ничего не делает. Она маскирует установку соединения, но не маскирует то, что по этому соединению передаётся.

VLESS-туннель с активными пользователями генерирует паттерн трафика, который с реальным iCloud не имеет ничего общего. Нейросеть, обученная на реальном трафике Apple-сервисов, видит это сразу.

Именно поэтому серверы с высокой нагрузкой и активным использованием падают быстрее. Не потому что их «нашли» — а потому что их трафик-профиль слишком аномальный.

XHTTP: архитектура, которая решает эту проблему

XHTTP — транспортный протокол в Xray-core, построенный поверх HTTP/2 или HTTP/3. На первый взгляд похоже на старый WebSocket+TLS. Архитектурно — принципиально другое.

Почему WebSocket умер.

WebSocket-соединение начинается с HTTP Upgrade запроса, после которого переходит в постоянный двунаправленный поток. Этот паттерн (HTTP Upgrade + бесконечный поток без характерных HTTP запрос-ответных пар) детектируется давно и надёжно.

Что делает XHTTP иначе.

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

Второй ключевой момент: XHTTP поддерживает xPaddingBytes — добавление случайного паддинга к пакетам для нормализации их размеров. Классификатор, обученный на распределении размеров пакетов, видит «нормальный» HTTP-трафик.

Три режима XHTTP: какой когда использовать

Режимов три, и это важно понимать перед тем как трогать конфиг.

packet-up — много коротких HTTP-запросов клиент→сервер, одно соединение сервер→клиент. Самый совместимый режим: работает через любой CDN, через любой Nginx. Небольшой оверхед за счёт множества коротких соединений. Выбирай по умолчанию.

stream-up — одно долгоживущее соединение клиент→сервер, одно сервер→клиент. Быстрее за счёт меньшего оверхеда, но не проходит через все CDN и реверс-прокси. Для прямого соединения клиент-сервер без CDN.

stream-one — не разделяет направления, единое соединение для обоих направлений. По сути VLESS с HTTP-обёрткой. Медленнее, но это единственный режим, совместимый с XTLS-Vision.
Требует Nginx с конкретными директивами на стороне сервера:

location /your-path/ {
  grpc_pass unix:/dev/shm/xrxh.socket;
  grpc_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  grpc_read_timeout 315s;
  grpc_send_timeout 315s;
}

auto — клиент выбирает режим автоматически исходя из возможностей соединения. Разумный выбор если не знаешь точно что нужно.

XHTTP + Reality: они не конкурируют, они комбинируются

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

Reality закрывает детекцию на уровне TLS-рукопожатия и активного зондирования. XHTTP закрывает детекцию на уровне поведения соединения после рукопожатия.

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

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

Полные рабочие конфиги

Критическое замечание перед использованием: XHTTP находится в активной разработке. Версии Xray на клиенте и сервере обязаны совпадать. Несовпадение версий даёт либо глюки, либо полную неработоспособность без каких-либо понятных ошибок. Это не предупреждение из разряда «желательно» - это обязательное условие.

Генерируем ключи для Reality:

xray x25519
# Выводит: Private key и Public key
# Сохраняем оба

Серверный конфиг (VLESS + XHTTP + Reality):

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

Клиентский конфиг:

{
  "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"
        }
      }
    }
  }]
}

Вариант с XTLS-Vision (stream-one + Vision):

// Сервер — clients добавляем flow
"clients": [{
  "id": "your-uuid-here",
  "flow": "xtls-rprx-vision"
}]

// xhttpSettings меняем mode
"xhttpSettings": {
  "path": "/api/v1/data",
  "mode": "stream-one"
}

// Клиент — users добавляем flow
"users": [{
  "id": "your-uuid-here",
  "encryption": "none",
  "flow": "xtls-rprx-vision"
}]

Правило одно: SNI-донор должен быть реальным сервисом с высоким трафиком в том же регионе, где стоит сервер.

Хорошие доноры для сервера в Европе:

www.microsoft.com    — огромный трафик, есть PoP везде
addons.mozilla.org   — стабильный, хорошо известный ASN
www.speedtest.net    — высокий трафик, глобальный CDN

Плохие доноры:

apple.com            — Apple держит IP в своих ASN, 
                       несоответствие сразу заметно
любой мелкий сайт    — DPI видит «icloud.com» 
                       на IP хостинга Hetzner

Как проверить что детекция не видит твой сервер

Шаг 1: JA3-проверка клиента.
Подключись через свой прокси и зайди на scrapfly.io/web-scraping-tools/ja3-fingerprint. Отпечаток должен совпадать с обычным Chrome без прокси.

Шаг 2: активное зондирование.
С другого IP сделай прямой curl к своему серверу:

curl -v https://your.domain.com \
  --resolve your.domain.com:443:<YOUR_IP>

Должен получить нормальный HTTP-ответ (если настроен masquerade), а не ошибку соединения и не TLS-ошибку.

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

Сравнение подходов в 2026-м

Параметр	VLESS + Reality	VLESS + XHTTP	VLESS + XHTTP + Reality
TLS-отпечаток	Идеальный	Хороший (uTLS)	Идеальный
Активное зондирование	Выдерживает	Выдерживает	Выдерживает
Поведенческий анализ	Уязвим при нагрузке	Устойчив	Устойчив
Работа через CDN	Нет	Да (packet-up)	Частично
Совместимость с Vision	Да	Только stream-one	Только stream-one
Сложность настройки	Средняя	Средняя	Выше средней
Устойчивость 2026	Снижается	Растёт	Лучшая из доступных

*мнение автора

Итог, которого все ждали

Итак, у тебя есть три варианта.

Вариант А: оставить всё как есть.
VLESS+Reality без XHTTP. Работает. Пока. Где-то. У некоторых. Иногда. Если сервер не под нагрузкой. И донор выбран правильно. И луна в правильной фазе.

Вариант Б: перейти на XHTTP.
Потратить вечер на настройку, выровнять версии Xray на клиенте и сервере, разобраться в трёх режимах, сгенерировать ключи, проверить JA3. Получить комбинацию, которая закрывает все текущие векторы детекции — до следующего обновления ТСПУ.

Вариант В: ничего не делать.
Подождать пока 20 миллиардов рублей государственных денег, Эшелон, Норси-Транс и нейросеть на стороне РКН сами решат за тебя. Спойлер: они решат не в твою пользу.

Выбор очевидный. Конфиги выше. Удачи.

¹ Автор данной статьи использовал для её написания зарубежный браузер, зарубежный процессор и протокол TLS, разработанный в США. Все упомянутые инструменты предназначены исключительно для изучения сетевых технологий в образовательных целях. Любое совпадение с реальным обходом блокировок случайно и не является целью публикации.

Если есть идеи для разбора, нашёл ошибку в конфиге
или хочешь предложить тему — пиши на
aleksandr@murzin.digital. Отвечаю.

Как ТСПУ ловит VLESS в 2026 и почему XHTTP — следующий шаг