ECH включён, а SNI всё равно виден: как проверить шифрование имени сайта в 2026

ECH — шифрование имени сайта в TLS-рукопожатии — в марте 2026 получил статус стандарта (RFC 9849, Standards Track). Firefox и Chrome включают его по умолчанию, Cloudflare раздаёт ключи почти всем своим клиентам. При этом у большинства пользователей ECH молча не работает: браузер уходит на обычное рукопожатие, и провайдер по-прежнему видит, куда вы идёте.

Ниже — как за минуту проверить своими руками, шифруется ли SNI именно у вас, почему он чаще всего не шифруется, и в каких сценариях ECH бесполезен принципиально (спойлер: для антидетекта и парсинга — почти всегда).

Что именно прячет ECH — и что не прячет

В обычном TLS 1.3 всё зашифровано, кроме первого сообщения — ClientHello. В нём открытым текстом лежит поле SNI с доменом, к которому вы подключаетесь. Именно по SNI работает большинство систем фильтрации: IP один на тысячи сайтов за CDN, а домен виден.

ECH расщепляет ClientHello надвое:

• ClientHelloOuter — идёт открыто, но с подставным доменом-обёрткой. У Cloudflare это cloudflare-ech.com.
• ClientHelloInner — настоящий домен, ALPN и список шифров, зашифрованные публичным ключом сервера.

Ключ для этого шифрования браузер берёт не из соединения, а из DNS — из HTTPS-записи (тип 65), параметр ech=. Отсюда главное следствие, о котором забывают: ECH невозможен без зашифрованного DNS. Если DNS-запрос идёт открытым UDP/53, наблюдатель просто видит имя домена ещё до рукопожатия, а фильтрующий резолвер может вырезать параметр ech= из ответа — и ECH не включится.

Чего ECH не скрывает вообще:

• IP-адрес назначения — виден всегда;
• объём и тайминги трафика;
• TLS-отпечаток клиента (JA3/JA4) — набор шифров и расширений остаётся в открытой части;
• вас для самого сайта — сервер после расшифровки видит всё, что видел раньше.

Последний пункт — причина, по которой ECH не имеет отношения к обходу антибот-систем. Cloudflare, DataDome и Akamai работают на стороне сервера: им не важно, был ли SNI зашифрован по дороге. Если задача — не палиться при автоматизации, работает совсем другой слой: подмена самого TLS-отпечатка, о чём мы разбирали в материале про обход JA4-фингерпринта через curl-cffi.

Проверка №1: работает ли ECH прямо сейчас (10 секунд)

Откройте в браузере:

https://crypto.cloudflare.com/cdn-cgi/trace

Найдите строку sni=. Возможны два варианта:

• sni=encrypted — ECH работает, имя сайта по дороге скрыто;
• sni=plaintext — ECH не применился, домен ушёл открытым текстом.

Тот же адрес через curl в терминале всегда вернёт sni=plaintext — обычный curl ECH не умеет, и это удобный ориентир: так выглядит «выключено».

Проверка №2: есть ли у домена ключ ECH (dig, без браузера)

ECH включится только если у домена в DNS есть HTTPS-запись с параметром ech=. Смотрим сырую запись:

dig +short TYPE65 example.com @1.1.1.1

В ответе ищите байты FE0D — это код расширения ECH, за ним идёт ECHConfig. Практический пример: на момент подготовки материала у crypto.cloudflare.com и у нашего домена proxycove.com запись длиной 133–136 байт содержит и FE0D, и подставное имя cloudflare-ech.com в hex-виде. А вот у самого cloudflare.com запись короткая, 61 байт: только ALPN и IP-подсказки, без ECH. То есть даже внутри инфраструктуры Cloudflare ECH раздаётся не всем доменам подряд — не удивляйтесь, если у конкретного сайта его нет.

Если dig ругается ignoring invalid type HTTPS — у вас старая версия утилиты, используйте числовую форму TYPE65, как в команде выше.

Почему ECH у вас не включается: пять причин по порядку

1. Выключен зашифрованный DNS. Без DoH браузер не получит ECHConfig в доверенном виде. В Firefox: Настройки → Приватность → DNS через HTTPS в режиме «Повышенная» или «Максимальная защита». В Chrome: Настройки → Безопасность → Использовать безопасный DNS.
2. У домена просто нет HTTPS-записи с ech= — проверяется командой из блока выше. Тут от вас ничего не зависит, это решение владельца сайта и его CDN.
3. Резолвер вырезает параметр. Корпоративные и провайдерские DNS-серверы штатно умеют отдавать HTTPS-записи без ech=. Проверьте, запросив запись напрямую у публичного резолвера (@1.1.1.1) и сравнив с ответом системного.
4. Флаги браузера сброшены. В Firefox отвечают network.dns.echconfig.enabled и network.dns.http3_echconfig.enabled в about:config — оба должны быть true.
5. Посередине стоит инспектирующий шлюз. Об этом — следующий раздел.

Как ECH ломают: две разные схемы

Корпоративный файрвол: тихое понижение

Вендоры сетевого оборудования выпустили готовые рецепты против ECH — терять видимость трафика они не готовы. Cisco, например, ещё с базы приложений VDB 416 (октябрь 2025) определяет «ECH Servers» как отдельное приложение и предлагает два подхода: перехватывать соединение с пересозданием сертификата и вырезать расширение encrypted_client_hello из ClientHello, либо действовать проще — на уровне DNS: блокировать HTTPS-записи для ECH-доменов, резать DoH/DoT/DoQ, блокировать канареечный домен use-application-dns.net и разрешать DNS только на корпоративные серверы.

Коварство первой схемы в том, что она не выглядит как блокировка. Сервер, не увидев ECH-расширения, отвечает как обычно, клиент считает ECH «безопасно отключённым» и переподключается уже с открытым SNI. Сайт открылся, ошибок нет — а имя домена ушло в лог шлюза.

Страновой уровень: соединение просто умирает

Российский пример показателен своей точностью. С 5 ноября 2024 года фильтрация срабатывает только при совпадении двух признаков одновременно: SNI со значением cloudflare-ech.com плюс наличие ECH-расширения. По отдельности ни то, ни другое блокировку не вызывает — ECH к другим доменам-обёрткам (например, тестовым defo.ie или tls-ech.dev) проходит. Реализовано это не сбросом соединения, а тихим отбрасыванием пакетов: страница висит и отваливается по таймауту. Затронуты и TCP-based HTTP/2, и QUIC/HTTP-3. Роскомнадзор тогда прямо заявил, что использование TLS ECH нарушает российское законодательство, и рекомендовал владельцам сайтов уйти с CDN Cloudflare — под фильтр разом попали тысячи вполне легальных ресурсов, включённых в общую обёртку.

Firefox в такой ситуации примерно через минуту повторяет попытку уже без ECH — то есть в итоге отдаёт открытый SNI, чего спецификация делать не рекомендует именно из соображений безопасности. Если вы наблюдаете «сайт грузится ровно минуту, потом открывается» — это почти наверняка оно.

Когда ECH недостаточно и что ставить вместо него

Разложим по задачам честно.

• Приватность от провайдера на домашнем интернете. ECH + DoH — хорошее и бесплатное улучшение. Работает там, где его не режут.
• Обход фильтрации. ECH для этого не проектировался, и практика это подтвердила: как только он начал мешать фильтрам, его научились определять и глушить целиком. Полагаться на него как на инструмент доступа нельзя.
• Парсинг, мультиаккаунтинг, автоматизация. ECH не даёт ничего: целевой сайт видит ваш IP, ваш JA4 и вашу историю запросов. Значение имеют только источник IP и качество отпечатка.

Во всех случаях, где ECH не справляется, работает более грубый, но надёжный слой: вынести TLS-рукопожатие за пределы наблюдаемой сети. Когда трафик идёт через прокси, наблюдатель на вашем канале видит только соединение с прокси-узлом — никакого SNI целевого сайта в нём нет вообще, независимо от того, поддерживает домен ECH или нет. Для повседневного доступа и работы с сервисами, чувствительными к репутации IP, подойдут резидентные прокси; для мобильных приложений и площадок, которые особенно придирчивы к типу подключения, — мобильные.

И не забывайте про DNS: прокси в браузере не гарантирует, что имена резолвятся через него же. Утечка DNS выдаёт ровно то, что вы пытались скрыть, — как это проверить, разбирали в отдельной инструкции про проверку прокси на утечку DNS. Если же вопрос именно в глубоком анализе трафика на канале, смотреть надо не на ECH, а на сам транспорт.

Короткий чек-лист

1. Открыть crypto.cloudflare.com/cdn-cgi/trace и посмотреть строку sni=.
2. Если plaintext — включить DoH в браузере и проверить снова.
3. Не помогло — проверить наличие ключа у домена: dig +short TYPE65 домен @1.1.1.1, искать FE0D.
4. Ключ есть, а ECH не применяется — сравнить ответ публичного и системного резолверов: скорее всего, параметр вырезают по дороге.
5. Соединение зависает на минуту и открывается — ECH глушат на уровне сети; ECH тут не поможет, нужен другой транспорт.

Вывод

ECH — это аккуратно закрытая последняя дыра в приватности TLS, а не средство доступа и тем более не инструмент для автоматизации. Он зависит от зашифрованного DNS, отключается посередине без единой ошибки на экране и глушится целиком там, где начинает мешать. Проверять его стоит — две команды выше занимают минуту. Но строить на нём обход блокировок или защиту от антибот-систем бессмысленно: эти задачи решаются на уровне того, чей IP и чей TLS-отпечаток видит сервер на другом конце.