todo/DPI/chrome-cnsa-flag-bypass.md

---
date: 2026-06-09
tags:
  - dpi
  - ja4
  - ja3
  - tls
  - chrome
  - cnsa
  - rkn
aliases:
  - CNSA-флаг Chrome против блокировок
  - cryptography-compliance-cnsa
  - chrome_fix
  - Обход блокировки сайтов флагом Chrome
link: https://habr.com/ru/articles/1045438/
description: "Сайт не открывается только в Chrome? Флаг cryptography-compliance-cnsa меняет TLS-отпечаток JA3/JA4 и может снять блокировку: как включить и когда работает."
---

> [!mirror] Резервное зеркало
> Актуальная версия этой страницы — на основной вики: [wiki.zapret.moe/DPI/chrome-cnsa-flag-bypass](https://wiki.zapret.moe/DPI/chrome-cnsa-flag-bypass)

# 🧪 Обход блокировки сайтов флагом Chrome `cryptography-compliance-cnsa`

> [!info] О чём заметка
> Клиентский способ вернуть доступ к сайтам, которые **не открываются только в Chromium-браузерах** из-за блокировки по **TLS-отпечатку** (JA4/JA3): включить экспериментальный флаг `chrome://flags/#cryptography-compliance-cnsa`. Это меняет TLS-«почерк» Chrome, и соединение перестаёт совпадать с заблокированной сигнатурой. Сам механизм блокировки и почему он бьёт по обычным браузерам — в [[DPI/browser-ja4-fingerprint-block|разборе блокировки по JA4-отпечатку]].

> [!quote] Первоисточник
> Приём описан в статье **eByeBots** на Хабре (июнь 2026): 👉 [habr.com/ru/articles/1045438](https://habr.com/ru/articles/1045438/). Там же — ссылка на репозиторий [`ebyebots/chrome_fix`](https://github.com/ebyebots/chrome_fix) с `.bat`-файлом для применения «в один клик».

> [!warning] Статус
> Это **народный приём**, не официальная рекомендация. Автор прямо предупреждает: **«может сработать не у всех»**. Объяснение «меняет порядок шифров» — авторская формулировка, и она **технически неполна** (см. раздел «Почему это работает»): против JA4 один лишь порядок шифров не помогает. Перед применением и после — проверьте свой отпечаток на [tls.browserleaks.com/json](https://tls.browserleaks.com/json).

## TL;DR

- Сайт открывается в Firefox/Safari, но **не в Chrome/Edge** → вероятно, блок по TLS-отпечатку (JA4/JA3).
- Лечится включением флага: `chrome://flags/#cryptography-compliance-cnsa` → **Enabled** → перезапуск.
- Флаг включает режим **CNSA** (американский стандарт криптографии), меняя **приоритет (порядок)** шифров и групп ключевого обмена в `Client Hello` (а вблизи Chrome 146 — и post-quantum-согласование) → TLS-почерк меняется → под правило блокировки может перестать попадать.
- Работает в **Chromium-браузерах** (Chrome, Brave, Opera, Яндекс.Браузер). Для Windows есть `.bat`, ставящий флаг через реестр.
- Это **не панацея** и не замена нормальному обходу: меняется лишь TLS-почерк, помогает только против блокировок, завязанных на него.

## На пальцах

> [!example] Аналогия
> Охранник на входе не проверяет содержимое сумки (оно зашифровано), а сверяет ваш «фасон одежды» с ориентировкой: «не пускать в куртке такого-то покроя». Все Chromium-браузеры одеты в один и тот же фасон (одинаковый TLS-`Client Hello`), и он попал в ориентировку. Флаг CNSA — это команда «оденься по другому дресс-коду»: Chrome пересобирает рукопожатие под стандарт CNSA, фасон меняется, и ориентировка на него больше не срабатывает.

## Что наблюдается

Из-за блокировки по TLS-отпечатку «через раз» перестают открываться вполне легальные ресурсы — **только в Chrome/Edge**, тогда как в Firefox/Safari они работают. В самой статье как пострадавший назван **Beget** (хостинг, у автора блокировался CDN); README репозитория `chrome_fix` приводит в примерах **beget.com, GitHub и Discord**. Это побочный ущерб от правил, нацеленных на обходные средства с хромовским отпечатком.

> [!warning] Обновление конца августа 2026: флаг может и мешать
> В конце августа 2026 у части пользователей включённый флаг дал обратный эффект: YouTube переставал открываться и показывал экран «Connect to the internet», а выключение флага возвращало доступ. Правила ТСПУ меняются, и приём, помогавший весной, к концу лета местами превратился в помеху — при диагностике проверяйте оба состояния флага. В те же дни шла отдельная волна с [[DPI/tspu-dns-nsdi-dnat-august-2026|подменой DNS-ответов на ТСПУ]], которая даёт похожий симптом «сайт не открывается» совсем по другой причине.

## Как включить

- [ ] Открой `chrome://flags/` (в Chrome) или `edge://flags/`, `brave://flags/` и т.п. — в адресной строке.
- [ ] Найди **Cryptography Compliance (CNSA)** — ID флага `#cryptography-compliance-cnsa`.
- [ ] Переключи в **Enabled**.
- [ ] Перезапусти браузер (кнопка *Relaunch*).
- [ ] Проверь проблемный сайт. Для контроля отпечатка — открой [tls.browserleaks.com/json](https://tls.browserleaks.com/json) до и после: если приём сработал, значение `ja4` изменится. Не изменилось — значит на твоей сборке флаг на отпечаток не повлиял.

Для Windows автор предлагает `.bat` из [`ebyebots/chrome_fix`](https://github.com/ebyebots/chrome_fix), который ставит флаг **через реестр** без ручных шагов (требует прав администратора и перезапуска браузера).

> [!danger] Перед запуском чужого .bat
> `.bat` правит реестр и требует админ-прав. Запускать сторонние скрипты вслепую не стоит — открой и прочитай содержимое, убедись, что он трогает только ключи реестра Chrome и ничего лишнего, либо сделай то же руками через `chrome://flags`. Содержимое чужого скрипта может меняться между версиями — не полагайся на чужие описания. Процедуру отката репозиторий не описывает — ручной способ отключается обратно тем же флагом (Disabled).

## Почему это работает (и важная оговорка про JA4)

Флаг включает режим соответствия **CNSA (Commercial National Security Algorithm Suite)** — набор криптоалгоритмов правительства США. По описанию Google, флаг заставляет Chrome **упорядочивать cipher suites по предпочтению CNSA**; вблизи Chrome 146 при этом флаге TLS-серверы Google начинают согласовывать post-quantum **ML-KEM-1024**. Сама политика помечена как «не требуется для безопасности».

> [!warning] Тонкость: «порядок шифров» — неполное объяснение
> Автор статьи пишет, что флаг «меняет **порядок** шифров». По документации Google флаг и правда лишь **переупорядочивает** предпочтение шифров и групп ключевого обмена под CNSA (`PreferSlowCiphers` + `PreferSlowKEXAlgorithms`) — он **не добавляет и не убирает** шифры из `Client Hello`.
>
> Но современный отпечаток **JA4 шифры сортирует** перед хешированием (вторая часть JA4 — хеш *отсортированного* списка cipher suites). Значит, одно лишь переупорядочивание шифров JA4 **не меняет** — оно меняет устаревший **JA3** (тот к порядку чувствителен).
>
> Почему же при этом иногда меняется и JA4, и блок спадает — **точно не задокументировано**. Вероятные причины: вблизи Chrome 146 флаг включает post-quantum-согласование **ML-KEM-1024** (меняется `key_share`/`supported_groups`), либо сдвигается порядок алгоритмов подписи (их JA4, в отличие от шифров, **не сортирует**). Не исключено и то, что конкретное правило DPI завязано на **JA3**, а не JA4 — тогда переупорядочивания шифров уже достаточно. Этим же объясняется авторское «**может не у всех**»: эффект зависит и от сборки браузера, и от того, на что именно настроено правило.

## Чем это НЕ является

> [!important] Область применимости (из закреплённого комментария к статье)
> Приём помогает только при **«сибирской» блокировке в варианте с учётом фингерпринта браузера** — то есть когда правило DPI завязано именно на TLS-отпечаток (JA3/JA4). Против **других** механизмов блокировки (а их довольно много) флаг **не поможет**. Это и есть прямой ответ на авторское «может не у всех». Что за «сибирская» схема и какие у неё ещё сигналы (подсеть, частота соединений) — см. [[VLESS/dpi-tls-june-2026|разбор схемы ограничений июня 2026]].

> [!note] Границы приёма
> - Это **не VPN и не обход цензуры в целом** — помогает только против блокировок, завязанных на **TLS-отпечаток клиента**.
> - Не поможет против блокировок по **IP/подсети, SNI или поведению** (частота соединений).
> - **Canvas Defender и подобные расширения тут бесполезны** — они работают только в JS (Canvas/WebGL) и не касаются TLS-рукопожатия. Полноценные **антидетект-браузеры** (Multilogin, GoLogin и т.п.) на модифицированном Chromium TLS-отпечаток менять как раз умеют — это их фича, — но это тяжёлый платный инструмент для других задач (мультиаккаунтинг); ради возврата доступа к сайту флаг CNSA куда проще.
> - Альтернатива со стороны **владельца сайта**, упомянутая в статье, — отключить TLS 1.3 (тогда отпечаток клиента иной); но это решение для админа ресурса, а не для пользователя. Автор добавляет, что у многих TLS 1.3 «отключён ещё со времён Cloudflare» (утверждение размытое, без подтверждения) и обещает отдельный материал для владельцев сайтов.

## Совместимость

| Браузер | Флаг доступен |
|---|---|
| Chrome | ✅ `chrome://flags/#cryptography-compliance-cnsa` |
| Brave / Opera / Яндекс.Браузер | ✅ (Chromium) |
| Edge | ⚠️ спорно: автор статьи пишет, что флага **нет**; README `chrome_fix` указывает `edge://flags` — проверь на своей сборке |
| Firefox / Safari | ❌ не нужно — у них и так другой JA4 |

## 📚 См. также

- [[DPI/browser-ja4-fingerprint-block|Блокировка сайта по JA4-отпечатку браузера]] — что это за блок, почему страдает Chrome и какие ещё есть способы сменить отпечаток (Firefox, обновление Chrome, F5).
- [[VLESS/dpi-tls-june-2026|Как DPI «замораживает» VLESS+REALITY: схема июня 2026]] — теория JA3/JA4 и uTLS, чем JA4 отличается от JA3.
- [[DPI/dpi-analysis-pipeline|Как DPI анализирует соединение: воронка проверок]] — где стоит проверка TLS-отпечатка.
- [[DPI/tspu-dns-nsdi-dnat-august-2026|Перехват DNS на ТСПУ (август 2026)]] — как отличить проблему с TLS-отпечатком от подменённого DNS-ответа: в первом случае адрес сайта получен, во втором резолвинг проваливается ещё до соединения.
- [[DPI/tspu-false-blocks-june-2026|Как ТСПУ ломает легитимные сайты: сопутствующий ущерб (июнь 2026)]] — общая картина июньских сбоев сайтов, где JA4-блок — лишь один из механизмов.
- 🔗 [Спецификация JA4+ (FoxIO)](https://github.com/FoxIO-LLC/ja4) — почему JA4 сортирует шифры, а JA3 нет.
- 🔗 [tls.browserleaks.com/json](https://tls.browserleaks.com/json) — посмотреть свой JA4 до/после.