--- 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/ --- # 🔬 Гипотеза: ТСПУ ловит прокси по «вечному 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-отпечаток), которым ловят и обходные средства, и обычные браузеры.