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

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

> [!mirror] Резервное зеркало
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/DPI/tspu-h2-h3-fingerprint-hypothesis](https://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|про «Июньскую блокировку 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](https://github.com/net4people/bbs/issues/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](https://github.com/XTLS/Xray-core/issues/5332) («TCP + Reality gets blocked»).
- **H2/H3-фингерпринтинг как класс техники существует** (по SETTINGS-фреймам, порядку псевдо-заголовков, QUIC-параметрам) — используется в антибот-системах ([Scrapfly](https://scrapfly.io/blog/posts/http2-http3-fingerprinting-guide), `fingerproxy`).

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

- В [net4people/bbs #546](https://github.com/net4people/bbs/issues/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](https://habr.com/ru/articles/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»](https://ebyebots.ru/blog/kak-tspu-roskomnadzora-lomaet-legitimnye-sajty-i-servery-v-iyune-2026-goda-tehnicheskij-razbor/) | 7 июня 2026 | Контекст поведенческой блокировки ТСПУ, в которую гипотеза встраивается. |

## 📚 См. также

- [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: «Июньская блокировка 2026»]] — трёхфакторная модель триггера; эта гипотеза — возможный **дополнительный** поведенческий под-признак.
- [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — почему REALITY ловят по поведению, а не по содержимому; контекст про TCP-природу REALITY.
- [[DPI/tspu-disable-quic-chrome|Отключение QUIC (HTTP/3) в браузере]] — обратный контекст: для доступа к легальному сайту QUIC иногда отключают, а здесь прокси, наоборот, мог бы использовать h3.
- [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — другой фингерпринт-признак (TLS-отпечаток), которым ловят и обходные средства, и обычные браузеры.