Привет!
Меня зовут Эрик, в данный момент я инженер технической поддержки в компании Shortcut. Недавно я столкнулся с интересным тикетом: пользователи жаловались, что некоторые сайты не открываются в Google Chrome, но при этом прекрасно работают в других браузерах.
Кажется, что если сайт работает в одном браузере, он должен работать и в другом. Но это не всегда так. Иногда Chrome упорно отказывается загружать страницы, которые спокойно открываются в Firefox или Edge. Недавно я столкнулся с таким случаем в работе и хочу рассказать, как я разобрался с проблемой.
Именно так выглядел тикет!
Некоторые сайты, такие как:
…не открываются в Google Chrome. Количество таких сайтов со временем увеличивается. Проблема проявляется в связке Cеть компании + DNS SkyDNS + Google Chrome. В других браузерах, например, Firefox, сайты открываются. Просим выявить причину проблемы и устранить её, так как пользователи используют Google Chrome.
Клиент обращался в техническую поддержку SkyDNS, а также к провайдеру, но это не принесло результатов – никто не смог помочь.
Первичный анализ
Траблшутить проблему начал с банальных вещей: естественно, проверил, какой ответ отдаёт DNS-сервер, выполнил ping до полученных адресов, проверил их доступность. Понятно, что эти действия сами по себе бессмысленны, так как сайт открывается в другом браузере, но некоторые вещи делаешь на автомате.
На этом этапе проверил IP-адреса, которые отдаёт DNS сервер — они оказались принадлежащими Cloudflare. Также в DNS-ответе для каждого из сайтов были IPv6-адреса. Небольшой поиск в интернете показал, что Chrome по умолчанию отдаёт предпочтение IPv6-адресам, и это натолкнуло меня на мысль проверить, что будет, если добавить в hosts IPv4-адреса вручную. Ведь hosts — это первое место, где ПК ищет соответствие домена и IP.
И вуаля — сайт открылся в Chrome!
Казалось бы, проблема найдена: Chrome выбирает IPv6-адреса вместо IPv4, а поскольку в сети не используется IPv6, сайты не загружаются. Однако другие сайты, которые также используют IPv6, открываются в Chrome без проблем. Значит, проблема не в IPv6.
Дальше я предположил, что Chrome выполняет дополнительные действия перед установлением соединения, и эти действия, скорее всего, связаны с DNS, так как сайт открывается при наличии записи в hosts. Для того чтобы выяснить, что именно происходит, я решил снять дампы трафика и проанализировать их.
Анализ дампа трафика, в чем проблема?
Исследование трафика при запросе в Firefox
В дампе, собранном при использовании Firefox, всё достаточно обычно: происходит запрос ресурсных записей типа A и AAAA (рис.1), после чего устанавливается соединение с использованием QUIC и TLS 1.3 (рис.2).


Исследование трафика при запросе в Chrome
Анализ дампов трафика в Wireshark показал, что Chrome перед установкой соединения запрашивает не только A-запись, но и HTTPS-запись (RFC 9460). Этот тип записи содержит параметры для установки HTTPS-соединения (Рис.3), в том числе Encrypted ClientHello (ECH) — механизм, который Роскомнадзор блокирует.
Подробнее про ECH
Encrypted ClientHello (ECH) — это механизм, который скрывает имя запрашиваемого сайта (SNI) в зашифрованном виде.
Зачем это нужно?
Обычный TLS (HTTPS) передаёт имя сайта открыто в поле SNI (Server Name Indication). Это позволяет провайдерам и государственным системам слежения (например, DPI) видеть, какой сайт ты посещаешь, даже если соединение зашифровано.
Как работает ECH?
1. Браузер запрашивает специальную HTTPS-запись (SVCB) у DNS.
2. В ответе DNS содержится публичный ключ сервера для шифрования ClientHello.
3. Браузер шифрует ClientHello и отправляет его на сервер.
4. Провайдер не может увидеть, какой сайт ты открываешь, так как данные уже зашифрованы.
Роскомнадзор использует DPI (Deep Packet Inspection) для анализа трафика и блокировки запрещённых сайтов. С ECH этот анализ становится невозможным, так как DPI не видит доменное имя.

Также в дампе были замечены множественные TCP Retransmission, что может указывать на блокировку посредством DPI (Рис.4).

Подтверждение версии о блокировке посредством DPI
Чтобы подтвердить данную версию, мы создали на MikroTik правило для заворачивания трафика до конкретного сайта в VPN-туннель. И вуаля — сайт стал открываться в Chrome.
Вывод: проблема в блокировке ECH
Firefox, скорее всего, не поддерживает Encrypted ClientHello (ECH) по умолчанию, поэтому сайты открываются без проблем. В то время как Chrome запрашивает записи HTTPS , так как это часть его алгоритма оптимизации соединений и поскольку Cloudflare предоставляет поддержку ECH своим пользователям, это приводит к возникновению проблем.
Так как ECH блокируется в России, я попробовал отключить его в Chrome. В версиях Chrome с 105-121 эта опция находилась в chrome://flags/#encrypted-client-hello
. В более новых версиях (121+) её убрали из экспериментальных функций и сделали нативной, но её можно отключить через системные параметры.
Решение: отключение ECH
В Windows откройте реестр и перейдите в:
HKEY_LOCAL_MACHINESOFTWAREPoliciesGoogleChrome
Создайте параметр DWORD
с именем EncryptedClientHelloEnabled
и значением 0
. Если ключей GoogleChrome
нет — создайте их.
В macOS:
sudo defaults write /Library/Preferences/com.google.Chrome EncryptedClientHelloEnabled -bool false
В сети компании благодаря Ringo MDM коллегам удалось оперативно внести эти изменения на всех хостах, независимо от используемой операционной системы. После чего все сайты которые раньше не открывались в Chrome стали доступны.
Альтернативные способы решения
Отключение ECH — это одно из решений. Также можно попробовать:
-
Использовать VPN.
-
Переключиться на альтернативный браузер.
-
Использовать DNS резолвер без HTTPS-записей
Итог
Эта ситуация хорошо показывает, как иногда браузеры могут стать жертвами сетевых ограничений. Надеюсь, теперь у вас есть инструменты, чтобы разобраться, если столкнётесь с похожей проблемой. А вы встречались с чем-то подобным?
Буду рад услышать ваши мысли в комментариях!
Автор: erikguru