todo/DPI/browser-ja4-fingerprint-block.md

date	tags	aliases	link	description
2026-06-09	dpi ja4 tls fingerprint chrome utls mtproto faketls rkn	Блокировка по JA4-отпечатку браузера JA4 fingerprint block Кейс wireflow.space Почему сайт не открывается только в Chrome	https://github.com/telegramdesktop/tdesktop/issues/30733	Почему сайт не открывается только в Chrome и Edge: разбор блокировки DPI по JA4-отпечатку TLS на примере wireflow.space и FakeTLS Telegram.

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

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

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

[!warning] Статус данных В основе — наблюдения нескольких участников форумного обсуждения (захваты трафика 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 ловит конкретный устаревший отпечаток, а не содержимое трафика.

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

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

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

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

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

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

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

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

Где открывали	TLS-движок	Результат
Chrome	Chromium / BoringSSL	❌ Client Hello → ретрансмиссии → RST
Edge	Chromium / BoringSSL	❌ то же самое
Firefox	Gecko / NSS	✅ открывается
Safari	WebKit / coreTLS (BoringSSL)	✅ открывается
curl	OpenSSL	✅ открывается

В 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 FakeTLS	t13d1516h2_8daaf6152771_d8a2da3f94cd	❌ блок
Chromium после обновления страницы (F5)	t13d1517h2_8daaf6152771_b6f405a00624	✅ проходит
Свежий Chrome 148 на Windows	t13d1514h2_8daaf6152771_827b515c4f52	✅ проходит
Firefox	t13d1717h2_5b57614c22b0_3cbfd9057e0d	✅ проходит
curl (OpenSSL)	другой (начинается с t13d14…)	✅ проходит

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

[!important] Блокируется не «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, под который правило блокировки не написано, — поэтому со второго раза сайт нередко открывается.

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

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

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

[!warning] Это наблюдение, а не подтверждённый факт Связь именно с 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-стороны — в Zapret/mtproto/10-telemt-logs-dpi и Zapret/mtproto/00-overview.

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

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

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

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

[!important] Главный вывод Если сайт упорно не открывается только в 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) — в DPI/chrome-cnsa-flag-bypass.

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

А для обходных средств вывод прямой и совпадает с рекомендациями VLESS/dpi-tls-june-2026:

[!tip] Практика

• Не используйте 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 он неприменим.

📚 См. также

• 🔗 Первоисточник связи с Telegram: Issue telegramdesktop/tdesktop#30733 — «Обновить fingerprint MTPROTO FakeTLS» — откуда известно, что …d8a2da3f94cd = Chrome 134/macOS = FakeTLS Telegram, а …827b515c4f52 = Chrome 148/Windows.
• VLESS/dpi-tls-june-2026 — теория «трёх сигналов», глубокий разбор uTLS и JA3/JA4, выбор fingerprint.
• DPI/dpi-analysis-pipeline — где в общем конвейере ТСПУ стоит проверка TLS-отпечатка.
• DPI/chrome-cnsa-flag-bypass — клиентский приём сменить TLS-отпечаток без смены браузера.
• DPI/curl-impersonate — как за секунды проверить из командной строки, что блокировка идёт именно по JA3/JA4-отпечатку клиента.
• DPI/tspu-false-blocks-june-2026 — TLS-отпечаток как фактор 2 в И-триггере «Siberian», из-за которого «легли» обычные сайты на хостингах.
• DPI/ru-network-blocklists — почему блок РФ-ASN на сервере не мешает ТСПУ, но осмыслен для приватности.
• DPI/statistical-morphing-concept — куда движется идея «прятать почерк и поведение».
• Zapret/mtproto/10-telemt-logs-dpi — та же блокировка по JA4 со стороны MTProto-прокси.
• Zapret/mtproto/00-overview — обзор MTProto и FakeTLS.
• 🔗 Спецификация JA4+ (FoxIO) — как именно считается JA4.
• 🔗 uTLS (refraction-networking/utls) — библиотека подмены TLS-отпечатка.