Zapret Wiki

Недавно обновлено

время чтения ~7 мин.

.md

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

Статус: НЕВЕРИФИЦИРОВАННАЯ ГИПОТЕЗА

Это догадка одного наблюдателя из профильного чата (11 июня 2026), выведенная из личного наблюдения, а не задокументированный реверс-инжинирингом механизм. Отдельные технические предпосылки верны (см. ниже), но главный вывод — спекуляция и может оказаться ложной корреляцией. На момент написания независимых подтверждений не зафиксировано (раздел «Внешние подтверждения»). Не строй на этом боевую конфигурацию без собственной проверки.

О чём заметка

Гипотеза о ещё одном поведенческом признаке, по которому ТСПУ (Технические Средства Противодействия Угрозам) Роскомнадзора может отличать обходные средства от настоящего браузера: реальный браузер на сайте с HTTP/3 быстро уходит на него, а прокси-клиент «навечно» остаётся на HTTP/2 — и это его выдаёт. Если гипотеза верна, из неё следует практический вывод: транспорт XHTTP с HTTP/3 маскируется лучше, а REALITY (работающий только по TCP) под такой признак уязвим. Общая модель блокировки — в обзорной заметке про «Июньскую блокировку 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 сам станет новым признаком).

На пальцах

Аналогия

На вечеринке (сайт с 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» сам станет аномалией. Один поведенческий маркер просто меняется на другой — гонка щита и меча.

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

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

  • 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. Это второй источник, у которого тот же эффект объясняется без механизма гипотезы.

Вердикт по верификации

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

Источники

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

📚 См. также

Вид графа

Обратные ссылки