todo/DPI/tspu-h2-h3-fingerprint-hypothesis.md

date	tags	aliases	link	description
2026-06-11	dpi tspu rkn quic http3 reality xhttp hypothesis	Гипотеза H2/H3 фингерпринт прокси Почему прокси выдаёт вечный HTTP/2 xhttp h3 против блокировки REALITY Alt-Svc HTTP/3 детект прокси	https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/	Гипотеза: ТСПУ вычисляет прокси по «вечному HTTP/2» без перехода на HTTP/3. Что в ней верно, что спекуляция и почему XHTTP+h3 живёт дольше REALITY.

[!mirror] Резервное зеркало Актуальная версия этой страницы — на основной вики: wiki.zapret.moe/DPI/tspu-h2-h3-fingerprint-hypothesis

🔬 Гипотеза: ТСПУ ловит прокси по «вечному HTTP/2» (отсутствию перехода на HTTP/3)

[!warning] Статус: НЕВЕРИФИЦИРОВАННАЯ ГИПОТЕЗА Это догадка одного наблюдателя из профильного чата (11 июня 2026), выведенная из личного наблюдения, а не задокументированный реверс-инжинирингом механизм. Отдельные технические предпосылки верны (см. ниже), но главный вывод — спекуляция и может оказаться ложной корреляцией. На момент написания независимых подтверждений не зафиксировано (раздел «Внешние подтверждения»). Не строй на этом боевую конфигурацию без собственной проверки.

[!info] О чём заметка Гипотеза о ещё одном поведенческом признаке, по которому ТСПУ (Технические Средства Противодействия Угрозам) Роскомнадзора может отличать обходные средства от настоящего браузера: реальный браузер на сайте с HTTP/3 быстро уходит на него, а прокси-клиент «навечно» остаётся на HTTP/2 — и это его выдаёт. Если гипотеза верна, из неё следует практический вывод: транспорт XHTTP с HTTP/3 маскируется лучше, а REALITY (работающий только по TCP) под такой признак уязвим. Общая модель блокировки — в обзорной заметке DPI/tspu-false-blocks-june-2026.

TL;DR

• Наблюдение: у автора гипотезы внезапно «заработали» проверялки QUIC в выдаче Google, что он связал с изменением стратегии блокировок ТСПУ.
• Гипотеза: ТСПУ ловит прокси по тому, что тот постоянно сидит на HTTP/2 и не переходит на HTTP/3, тогда как настоящий браузер при первой возможности на HTTP/3 уходит.
• Почему браузер уходит: правильно настроенный сервер шлёт заголовок Alt-Svc (Alternative Services — «у меня есть HTTP/3, переключайся»); браузер, в отличие от прокси-клиента, на нём не задерживается и мигрирует на HTTP/3.
• Следствие 1: прокси на транспорте XHTTP с h3 (HTTP/3) ведёт себя как браузер, ушедший на h3 — и под признак «вечный h2» не попадает.
• Следствие 2: REALITY работает только по TCP и в принципе не умеет HTTP/3 — поэтому всегда остаётся на h2 и (если гипотеза верна) уязвим.
• Большая оговорка: это не доказано. И даже если работает сейчас — приём временный (массовый уход прокси на h3 сам станет новым признаком).

На пальцах

[!example] Аналогия На вечеринке (сайт с HTTP/3) хозяин громко объявляет: «у нас открыт второй, VIP-зал!» (заголовок Alt-Svc). Настоящие гости (браузеры) тут же перетекают в VIP (HTTP/3). А один человек упорно стоит в первом зале и никуда не идёт (прокси-клиент на HTTP/2). Сам по себе он ничего не нарушает — но на фоне всех, кто ушёл, его неподвижность бросается в глаза. Охрана (ТСПУ) начинает присматриваться именно к тем, кто «не пошёл в VIP, хотя позвали».

(Это иллюстрация логики гипотезы, а не доказанный механизм — см. раздел «Что в гипотезе спекулятивно».)

Что в гипотезе технически верно

Кирпичики, на которых она стоит, по отдельности корректны:

• Alt-Svc реально переводит браузер на HTTP/3. Заголовок Alt-Svc (или DNS-запись HTTPS/SVCB) анонсирует поддержку HTTP/3. Обычно первое соединение идёт по TCP/HTTP/2, после чего браузер мигрирует на HTTP/3; при закешированном Alt-Svc или DNS-записи HTTPS/SVCB он может пойти на HTTP/3 сразу. Это штатное поведение Chrome/Firefox.
• ТСПУ может доставать SNI из QUIC. Утверждение «научились расшифровывать QUIC» неточно по форме, но по сути отражает реальность: QUIC Initial-пакеты (с ClientHello и SNI — Server Name Indication, имя домена) защищены ключом, который вычисляется из публично известных данных (соль версии + Connection ID). Поэтому DPI всегда мог извлечь оттуда SNI — речь о том, что это стали применять, а не о взломе шифрования.
• REALITY — TCP-only. Протокол XTLS-REALITY перехватывает TLS-рукопожатие реального сайта и работает поверх TCP; HTTP/3 (поверх UDP) он не поддерживает. Значит REALITY-клиент физически не может уйти на h3 и всегда показывает h2 — под признак «вечный h2» он попадает целиком.
• XHTTP умеет HTTP/3. Транспорт XHTTP в Xray поддерживает h3, поэтому «настроить xhttp-tls с h3» — реальная, а не выдуманная опция.

Что в гипотезе спекулятивно

• Главный тезис — что блокировка нацелена ИМЕННО на «h2 без перехода на h3» — это интерпретация одного наблюдения («заработали QUIC-чекеры»). Корреляция не равна механизму: эффект мог дать и плавающий характер настроек ТСПУ, и региональные различия (QUIC, как известно, блокируется не везде).
• Нет независимого подтверждения. В отличие от трёхфакторной модели «Июньской блокировки» (разобранной по реверс-инжинирингу несколькими исследователями), эта связка пока опирается на один источник.
• Приём недолговечен по своей природе. Если заметная доля прокси уйдёт на h3, «одинокий/слишком ранний переход на h3» сам станет аномалией. Один поведенческий маркер просто меняется на другой — гонка щита и меча.

Если гипотеза верна: что делать

[!tip] Практический вывод (с оговоркой «если подтвердится»)

• XHTTP с h3 маскируется под браузер, ушедший на HTTP/3, — и не выделяется «вечным h2». Но работает только там, где QUIC вообще проходит (а ТСПУ режет его не везде — где UDP/QUIC заблокирован, h3-прокси просто не встанет).
• REALITY под этот признак уязвим: он всегда TCP/h2. Это не значит, что REALITY «сломан» — он по-прежнему силён против других сигналов; но конкретно от признака «нет перехода на h3» он не защищает.

Как проверить (а не верить на слово)

• Поднять xhttp-tls с h3 и REALITY на соседних портах одного сервера и сравнить, что живёт дольше под одним оператором и регионом.
• Снять дамп трафика и убедиться, что REALITY-клиент действительно остаётся на h2, а xhttp+h3 уходит на h3, и что блокировка коррелирует именно с этим.
• Повторить на нескольких операторах/регионах — «плавающие» настройки ТСПУ могут давать ложную картину на одном из них.

Внешние подтверждения

Поиск в профильных сообществах (net4people/bbs, Xray-issues) на 11 июня 2026 дал важный, но двойственный результат: наблюдаемый эффект подтверждается, а механизм из гипотезы — нет.

Что подтверждается (эффект):

• Поведенческая блокировка VLESS+REALITY в РФ реальна и задокументирована. В net4people/bbs #546 описана «TLS connection-based policing» на домашних ISP (по репортам в треде — MTS/MGTS в Москве, RTK в Ижевске и др.), стартовавшая ещё ~12 ноября 2025 (то есть «Июньская блокировка 2026» — новая волна давней тенденции). Бьёт прежде всего по VLESS+REALITY+vision на порту 443; соединение рвётся, как только через туннель пошёл реальный трафик.
• XHTTP с H3 действительно помогает, а REALITY+vision на 443 — действительно страдает. Это совпадает с практическим выводом гипотезы. Среди работающих обходов в том же треде: смена порта с 443, mux (мультиплексирование), XHTTP/H2/H3 + mux, ShadowSocks 2022 и другие не-TLS протоколы. См. также XTLS/Xray-core #5332 («TCP + Reality gets blocked»).
• H2/H3-фингерпринтинг как класс техники существует (по SETTINGS-фреймам, порядку псевдо-заголовков, QUIC-параметрам) — используется в антибот-системах (Scrapfly, fingerproxy).

Что НЕ подтверждается (механизм):

• В net4people/bbs #546 HTTP/2 vs HTTP/3, Alt-Svc и «вечный h2» как признак прокси не упоминаются вообще. Наблюдаемый там механизм — блокировка по числу одновременных TLS-соединений к одному эндпоинту (после ~60 секунд переподключение снова возможно) и привязка к порту 443.
• Это даёт более простое конкурирующее объяснение того же эффекта: XHTTP+H3 помогает не потому, что «выглядит как браузер, ушедший на h3», а потому, что QUIC сворачивает всё в одно соединение, а mux мультиплексирует потоки — то есть снижается число распознаваемых TLS-соединений (третье условие модели). А REALITY+vision на 443 страдает из-за паттерна одиночного TLS-потока на стандартном порту, а не из-за «отсутствия перехода на h3».
• Применение H2/H3-фингерпринтинга именно ТСПУ нигде не задокументировано — техника существует у антибот-сервисов, но это не доказывает её использование цензором.
• Ещё один независимый разбор блокировок VLESS/Xray (Habr 990236) тоже не упоминает h2/h3 или Alt-Svc, а указывает на совсем другие факторы: привязку к порту 443 (на высоких портах проходит ~80% трафика), реакцию на пустой SNI и на TLS-fingerprint. Это второй источник, у которого тот же эффект объясняется без механизма гипотезы.

[!important] Вердикт по верификации Гипотеза права в наблюдении (xhttp+h3 маскируется лучше, REALITY+vision на 443 уязвим), но её объяснение причины (alt-svc / «вечный h2 / нет перехода на h3») независимыми источниками не подтверждается и имеет более экономное конкурирующее объяснение — блокировку по числу/паттерну TLS-соединений и порту. Поэтому практический совет (перейти на XHTTP+H3 или mux, уйти с порта 443) рабочий, но обоснование «потому что h2 выдаёт прокси» — пока спекуляция.

Источники

Источник	Дата	Что отсюда взято
Наблюдение участника профильного чата по обходу DPI	11 июня 2026	Сама гипотеза: связь блокировки с «вечным h2», роль Alt-Svc, вывод про xhttp+h3 vs REALITY. Один источник, не верифицировано.
eByeBots — технический разбор «Июньской блокировки 2026»	7 июня 2026	Контекст поведенческой блокировки ТСПУ, в которую гипотеза встраивается.

📚 См. также

• DPI/tspu-false-blocks-june-2026 — трёхфакторная модель триггера; эта гипотеза — возможный дополнительный поведенческий под-признак.
• VLESS/dpi-tls-june-2026 — почему REALITY ловят по поведению, а не по содержимому; контекст про TCP-природу REALITY.
• DPI/tspu-disable-quic-chrome — обратный контекст: для доступа к легальному сайту QUIC иногда отключают, а здесь прокси, наоборот, мог бы использовать h3.
• DPI/browser-ja4-fingerprint-block — другой фингерпринт-признак (TLS-отпечаток), которым ловят и обходные средства, и обычные браузеры.