--- date: 2026-06-09 tags: - dpi - ja4 - tls - fingerprint - chrome - utls - mtproto - faketls - rkn aliases: - Блокировка по JA4-отпечатку браузера - JA4 fingerprint block - Кейс wireflow.space - Почему сайт не открывается только в Chrome link: https://github.com/telegramdesktop/tdesktop/issues/30733 --- # 🕵️ Когда DPI блокирует сайт по JA4-отпечатку браузера: разбор кейса wireflow.space > [!info] О чём заметка > Документированный полевой случай: сайт открывается в Firefox, Safari и `curl`, но **не открывается ни в одном Chromium-браузере** (Chrome, Edge) — и причина не в самом сайте, а в **TLS-отпечатке браузера**, по которому его опознаёт DPI. Это конкретная иллюстрация «Сигнала 2» (фингерпринт клиента) из теоретического разбора [[VLESS/dpi-tls-june-2026|схемы ограничений июня 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|воронка анализа DPI]] и в разделе про uTLS в [[VLESS/dpi-tls-june-2026|разборе схемы июня 2026]]. Для понимания кейса достаточно прочитать **первый блок** хеша: ```text 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](https://github.com/telegramdesktop/tdesktop/issues/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|логах DPI по telemt]] и [[Zapret/mtproto/00-overview|обзоре MTProto]]. ## Как это связано с блокировкой VLESS и обычного веба Этот кейс — наглядная демонстрация того, о чём говорит [[VLESS/dpi-tls-june-2026|разбор схемы июня 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|отдельной заметке про CNSA-флаг]]. > [!warning] Про CNSA-флаг и JA4 > Часто пишут, что флаг «меняет **порядок** шифров». Но по докам Google флаг лишь **переупорядочивает** предпочтение шифров и групп (не меняя их состав), а JA4 шифры **сортирует** перед хешированием — поэтому переупорядочивание меняет устаревший **JA3**, но не JA4_b. Почему при этом иногда меняется и JA4 — точно не задокументировано (вероятно, post-quantum-согласование ML-KEM-1024 ~Chrome 146 или порядок алгоритмов подписи; не исключено, что правило DPI завязано на JA3). Сам автор отмечает: **«может сработать не у всех»**. Перед использованием проверь свой JA4 на [tls.browserleaks.com/json](https://tls.browserleaks.com/json). Разбор — в [[DPI/chrome-cnsa-flag-bypass|заметке про CNSA-флаг]]. А для **обходных средств** вывод прямой и совпадает с рекомендациями [[VLESS/dpi-tls-june-2026|схемы июня 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»](https://github.com/telegramdesktop/tdesktop/issues/30733) — откуда известно, что `…d8a2da3f94cd` = Chrome 134/macOS = FakeTLS Telegram, а `…827b515c4f52` = Chrome 148/Windows. - [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — теория «трёх сигналов», глубокий разбор uTLS и JA3/JA4, выбор `fingerprint`. - [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где в общем конвейере ТСПУ стоит проверка TLS-отпечатка. - [[DPI/chrome-cnsa-flag-bypass|Обход блокировки флагом Chrome cryptography-compliance-cnsa]] — клиентский приём сменить TLS-отпечаток без смены браузера. - [[DPI/curl-impersonate|curl-impersonate — curl, притворяющийся браузером]] — как за секунды проверить из командной строки, что блокировка идёт именно по JA3/JA4-отпечатку клиента. - [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: сопутствующий ущерб (июнь 2026)]] — TLS-отпечаток как фактор 2 в И-триггере «Siberian», из-за которого «легли» обычные сайты на хостингах. - [[DPI/ru-network-blocklists|Блокировка российских сетей (ASN/CIDR): приватность vs «чтобы не блокировали VPN»]] — почему блок РФ-ASN на сервере не мешает ТСПУ, но осмыслен для приватности. - [[DPI/statistical-morphing-concept|Адаптивная мимикрия трафика (концепт)]] — куда движется идея «прятать почерк и поведение». - [[Zapret/mtproto/10-telemt-logs-dpi|telemt: чтение логов и TLS-фингерпринты]] — та же блокировка по JA4 со стороны MTProto-прокси. - [[Zapret/mtproto/00-overview|MTProto Proxy — полный гайд]] — обзор MTProto и FakeTLS. - 🔗 [Спецификация JA4+ (FoxIO)](https://github.com/FoxIO-LLC/ja4) — как именно считается JA4. - 🔗 [uTLS (refraction-networking/utls)](https://github.com/refraction-networking/utls) — библиотека подмены TLS-отпечатка.