Zapret Wiki

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

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

.md

🕵️ Когда DPI блокирует сайт по JA4-отпечатку браузера: разбор кейса wireflow.space

О чём заметка

Документированный полевой случай: сайт открывается в Firefox, Safari и curl, но не открывается ни в одном Chromium-браузере (Chrome, Edge) — и причина не в самом сайте, а в TLS-отпечатке браузера, по которому его опознаёт DPI. Это конкретная иллюстрация «Сигнала 2» (фингерпринт клиента) из теоретического разбора схемы ограничений июня 2026 и того, как от него страдают обычные пользователи, а не только обходные средства.

Статус данных

В основе — наблюдения нескольких участников форумного обсуждения (захваты трафика Wireshark/tshark, тесты в разных браузерах, июнь 2026). Это воспроизводимый, но community-источник, а не официальная спецификация блокировки. Конкретные JA4-хеши и «триггер по github» — то, что увидели и описали очевидцы; параметры различаются от оператора к оператору и со временем меняются. Сайт wireflow.space в кейсе — чужой (это сторонний VPN-сервис), он использован лишь как удобный «подопытный», на котором эффект стабильно повторяется.

TL;DR

  • Сайт https://www.wireflow.space (IP 82.24.123.105, Hostkey B.V., Амстердам) не открывается в Chrome и Edge, но открывается в Firefox, Safari и через curl.
  • В Chromium соединение не доходит до ответа сервера: после Client Hello идёт серия TCP Retransmission, а затем RST — при этом сам IP не блокирован. Реакция идёт на TLS-отпечаток, а не на адрес.
  • Блокируется один конкретный JA4: t13d1516h2_8daaf6152771_d8a2da3f94cd. Это не «Chrome вообще», а отпечаток Chrome 134-поколения (в базах JA4 числится как «Chrome 134, macOS») — ровно тот, что использует MTPROTO FakeTLS Telegram. Та же сигнатура попадала и в часть сборок Chrome/Edge на Windows у очевидцев.
  • Свежий Chrome 148 на Windows даёт другой JA4 — t13d1514h2_8daaf6152771_827b515c4f52 (14 расширений вместо 16) — и под блок не попадает.
  • Обновление страницы (F5) часто «лечит» доступ: Chromium добавляет расширение pre_shared_key (возобновление TLS-сессии), отпечаток меняется на t13d1517h2_8daaf6152771_b6f405a00624 — и под правило он уже не попадает.
  • Firefox и curl не блокируются, потому что у них другие JA4 (другой «почерк»).
  • Это тот же механизм, что бьёт по VLESS+REALITY с fingerprint: chrome и по MTProto-прокси: DPI ловит конкретный устаревший отпечаток, а не содержимое трафика.

На пальцах: что вообще происходит

Аналогия

Представьте охранника на входе, который не проверяет, что у вас в сумке (это бесполезно — всё зашифровано), а смотрит на фасон вашей одежды. У него есть ориентировка: «не пускать людей в куртке такого-то фасона к такому-то зданию». Chrome, Edge и весь Chromium «одеты» в один и тот же фасон (одинаковый TLS-«почерк»). Firefox и curl одеты иначе — их пускают. А стоит человеку в «той самой» куртке просто переодеть шарф (обновить страницу — добавляется одно TLS-расширение), как фасон формально перестаёт совпадать с ориентировкой, и его пропускают.

Ключевой сдвиг: цензор давно перестал заглядывать внутрь TLS-пакета (там всё зашифровано) и опознаёт клиента по форме самого первого пакета рукопожатия — Client Hello. Свёртка этого пакета в короткую строку и называется JA4-отпечатком.

Что такое JA4 — в одну строку

JA4 — это устойчивый отпечаток TLS-клиента: версия TLS, отсортированный список шифров и расширений, ALPN. Записывается строкой из трёх частей a_b_c. Подробный разбор формата (и чем JA4 лучше старого JA3) — в заметке воронка анализа DPI и в разделе про uTLS в разборе схемы июня 2026.

Для понимания кейса достаточно прочитать первый блок хеша:

t   13   d   15   16   h2
│   │    │   │    │    └─ ALPN: http/2
│   │    │   │    └────── число расширений: 16
│   │    │   └─────────── число шифров (cipher suites): 15
│   │    └─────────────── SNI присутствует (d = domain)
│   └──────────────────── версия TLS: 1.3
└──────────────────────── транспорт: TCP

Что наблюдали в кейсе

Где открывалиTLS-движокРезультат
ChromeChromium / BoringSSL❌ Client Hello → ретрансмиссии → RST
EdgeChromium / BoringSSL❌ то же самое
FirefoxGecko / NSS✅ открывается
SafariWebKit / coreTLS (BoringSSL)✅ открывается
curlOpenSSL✅ открывается

В Chromium захват трафика показывает картину «глухой стены»: уходит Client Hello (SNI=www.wireflow.space), дальше — серия TCP Retransmission (ответа нет), и в конце RST. Ответ сервера до клиента не доходит: Client Hello уходит впустую, клиент его повторяет, а DPI глушит соединение по JA4-отпечатку — финальный RST приходит уже в конце этого «шторма» ретрансмиссий, а не мгновенно. При этом сам IP 82.24.123.105 не блокирован: на прямое обращение к нему «никакой реакции нет».

Отпечатки, которые решают всё

Именно разница в JA4 объясняет, почему одни браузеры проходят, а другие нет:

Клиент / ситуацияJA4Под блок?
Chrome 134-поколения / Telegram FakeTLSt13d1516h2_8daaf6152771_d8a2da3f94cd❌ блок
Chromium после обновления страницы (F5)t13d1517h2_8daaf6152771_b6f405a00624✅ проходит
Свежий Chrome 148 на Windowst13d1514h2_8daaf6152771_827b515c4f52✅ проходит
Firefoxt13d1717h2_5b57614c22b0_3cbfd9057e0d✅ проходит
curl (OpenSSL)другой (начинается с t13d14…)✅ проходит

Правило DPI заточено под один конкретный отпечаток — …d8a2da3f94cd. Любой клиент с другим JA4 правило не активирует.

Блокируется не «Chrome», а конкретная версия отпечатка

Легко решить, что DPI ловит «браузер Chrome». На самом деле под правило попадает строго один JA4 — t13d1516h2_8daaf6152771_d8a2da3f94cd. В публичных базах сопоставления он числится как «Chrome 134, macOS», но различает JA4 в первую очередь версию клиента, а не ОС: ключевое отличие — число расширений (16 у Chrome 134-поколения против 14 у Chrome 148), метка ОС в базе — лишь ярлык наиболее похожего профиля. Поэтому свежий Chrome 148 (t13d1514h2_…) проходит, а более старые сборки Chrome/Edge — нет. Тот же …d8a2da3f94cd зашит и в FakeTLS-маскировку Telegram (см. ниже).

Почему обновление страницы «лечит» доступ

Сравните первые блоки двух Chromium-отпечатков: t13d15**16**h2 против t13d15**17**h2. Различие — число TLS-расширений: 16 → 17, при том что список шифров (8daaf6152771) тот же.

Когда вы заходите на сайт повторно (или обновляете страницу), Chromium пытается возобновить TLS-сессию и добавляет в Client Hello расширение pre_shared_key. Это меняет и счётчик расширений (16→17), и хеш-часть отпечатка (d8a2da3f94cd → b6f405a00624). Получается другой JA4, под который правило блокировки не написано, — поэтому со второго раза сайт нередко открывается.

Это не «обход», а побочный эффект

Возобновление сессии — штатное поведение браузера, а не приём против DPI. Поэтому «лечение обновлением» нестабильно: при холодном заходе (нет сессии для возобновления) снова уходит «голый» …d8a2da3f94cd, и сайт опять не открывается.

Спорный триггер: связь с обращением к GitHub

Часть очевидцев описала любопытную закономерность: блок на wireflow.space в Chrome «взводится» примерно на 10 минут после обращения к GitHub — причём триггером называют SNI самого GitHub, а не его IP. Логика-гипотеза: у тех, кто сидит за провайдерским NAT, рабочим Wi-Fi и т.п. (где кто-то постоянно ходит на GitHub, а часть опенсорс-софта периодически проверяет там обновления), такой блок может «висеть» практически круглосуточно.

Это наблюдение, а не подтверждённый факт

Связь именно с GitHub перепроверить трудно: на проблемных сетях (приводят пример университетского МГТС) блокировки триггерит постоянно и много чего, поэтому выделить GitHub как однозначную причину не удалось. Относитесь к «10-минутному окну после GitHub» как к рабочей гипотезе, а не к установленному правилу. Достоверно воспроизводится только базовый факт: блок включается на JA4-отпечаток Chrome, и смена отпечатка его снимает.

Тот же отпечаток палит и Telegram (MTPROTO FakeTLS)

Заблокированный t13d1516h2_8daaf6152771_d8a2da3f94cd — не случайный. Это тот самый отпечаток, которым маскируется MTPROTO-прокси Telegram в режиме FakeTLS: чтобы притвориться обычным HTTPS, клиент Telegram (Android и Windows) отправляет Client Hello, который в базах JA4 опознаётся как профиль Chrome 134/macOS (macOS здесь — ярлык совпавшего профиля, а не платформа клиента). Об этом — открытый issue telegramdesktop/tdesktop#30733 «Обновить fingerprint MTPROTO FakeTLS».

Из issue следует прямая связь с этим кейсом:

  • Telegram FakeTLS использует устаревший профиль Chrome 134 (…d8a2da3f94cd) — тот же, что попал под блок wireflow.space.
  • Тесты блокировки MTPROTO-прокси по этому JA4 начались в Сибири 22 мая 2026.
  • Предложение в issue — обновить FakeTLS-отпечаток до актуального (например, Chrome 148 / Windows t13d1514h2_8daaf6152771_827b515c4f52) и ротировать его между профилями Chrome Windows / Chrome Android / Firefox, чтобы не торчать статичной сигнатурой.

Вывод: DPI ведёт чёрный список конкретных JA4 обходных средств. Поскольку этот же отпечаток случайно отдавали и старые сборки настоящего Chrome/Edge, под раздачу попали и обычные сайты — это и есть наблюдаемый эффект wireflow.space. Разбор MTProto-стороны — в логах DPI по telemt и обзоре MTProto.

Как это связано с блокировкой VLESS и обычного веба

Этот кейс — наглядная демонстрация того, о чём говорит разбор схемы июня 2026: DPI ловит массовый отпечаток Chrome и применяет правило к подозрительному направлению.

  • wireflow.space — это сторонний VPN-сервис на зарубежном хостинге (Hostkey, Нидерланды). Для DPI такое направление «подозрительное» по адресу/подсети — ровно как ваш личный VLESS-сервер на «народном» хостинге.
  • Дефолтный фингерпринт Chrome — «подозрительный по почерку» сам по себе.
  • Совпадение «подозрительное направление + почерк Chrome» и активирует обрыв.

Отсюда же — сопутствующий ущерб для обычных пользователей: страдает не обходное средство, а человек, который просто открыл чужой сайт в Chrome. Тот же эффект очевидцы наблюдают и на других ресурсах — биллинги хостеров, bing.com, отдельные российские сайты «через раз», особенно по IP. Подробнее механика «почему обычный Chrome обычно работает, но иногда ломает сайты» разобрана в парной заметке.

Главный вывод

Если сайт упорно не открывается только в Chrome/Edge, но открывается в Firefox/Safari/curl — это с большой вероятностью блокировка по JA4-отпечатку браузера, а не проблема сайта, DNS или вашей сети. Проверяется за минуту: откройте тот же адрес в Firefox.

Что это значит для обхода

Для обычного браузера есть несколько клиентских способов сменить отпечаток (от простого к сложному):

  • Открыть в Firefox/Safari — другой TLS-стек, другой JA4.
  • Обновить Chrome до свежей версии (148 даёт t13d1514h2_…, не из чёрного списка).
  • Нажать F5 — возобновление сессии добавляет pre_shared_key, отпечаток меняется.
  • Включить флаг chrome://flags/#cryptography-compliance-cnsa (Enabled, перезапуск). По сообществу (статья eByeBots, июнь 2026) это помогает: режим CNSA меняет приоритет (порядок) шифров и групп ключевого обмена, а вблизи Chrome 146 — и post-quantum-согласование. Подробно (и важная оговорка про JA4) — в отдельной заметке про CNSA-флаг.

Про CNSA-флаг и JA4

Часто пишут, что флаг «меняет порядок шифров». Но по докам Google флаг лишь переупорядочивает предпочтение шифров и групп (не меняя их состав), а JA4 шифры сортирует перед хешированием — поэтому переупорядочивание меняет устаревший JA3, но не JA4_b. Почему при этом иногда меняется и JA4 — точно не задокументировано (вероятно, post-quantum-согласование ML-KEM-1024 ~Chrome 146 или порядок алгоритмов подписи; не исключено, что правило DPI завязано на JA3). Сам автор отмечает: «может сработать не у всех». Перед использованием проверь свой JA4 на tls.browserleaks.com/json. Разбор — в заметке про CNSA-флаг.

А для обходных средств вывод прямой и совпадает с рекомендациями схемы июня 2026:

Практика

  • Не используйте fingerprint: chrome в REALITY — именно он попадает под массовое правило. Берите менее массовый профиль: firefox, edge или random.
  • Различайте random и randomized — это не одно и то же:
    • random — xray случайно берёт один из реальных браузерных пресетов (Chrome 131, Firefox 148 и т.п.). Почерк всегда валидный — безопасный вариант.
    • randomized (HelloRandomizedALPN в uTLS) — генерирует синтетический Client Hello со случайными шифрами/расширениями (не реальный браузер), причём по-разному на каждом соединении. В Xray-core для REALITY TLS 1.3 при этом принудительно форсируется (вес TLSVersMax_Set_VersionTLS13 = 1), так что в TLS 1.2 он не падает. Но главный минус остаётся: отпечаток случаен и нестабилен, а наличие post-quantum key_share (X25519MLKEM768) от соединения к соединению непредсказуемо — синтетика может сама выглядеть для DPI аномально. По сообщениям очевидцев (МГТС МСК, с 1 апреля 2026) randomized тоже попадал под блок — это не панацея, применять с осторожностью.
  • Свежесть пресета uTLS важнее выбора бренда: пресет без post-quantum key_share (X25519MLKEM768) сам по себе аномален для «свежего» браузера — держите xray/uTLS актуальными. Это ещё одна причина предпочесть конкретный свежий пресет (firefox/edge) синтетическому randomized.
  • Полностью отключить uTLS («голый» Go-почерк через unsafe/HelloGolang) с REALITY не работает — REALITY требует валидного браузерного фингерпринта. Это обсуждалось как вариант, но для REALITY он неприменим.

📚 См. также

Вид графа

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