loop-uh
0ad0bcc8dd
Some checks failed
Published content check / validate (push) Failing after 5s
Каждая публикуемая заметка получила callout-шапку со ссылкой на свою страницу wiki.zapret.moe (на самой вики она вырезается транформером RemoveMirrorCallout, видна только на зеркале Obsidian Publish и в Forgejo) и SEO-поле description — 1–2 предложения для meta description обоих сайтов. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
171 lines
26 KiB
Markdown
171 lines
26 KiB
Markdown
---
|
||
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
|
||
description: "Почему сайт не открывается только в Chrome и Edge: разбор блокировки DPI по JA4-отпечатку TLS на примере wireflow.space и FakeTLS Telegram."
|
||
---
|
||
|
||
> [!mirror] Резервное зеркало
|
||
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/DPI/browser-ja4-fingerprint-block](https://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|схемы ограничений июня 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-отпечатка.
|