Загадочные проблемы браузинга: почему некоторые сайты не грузятся в Chrome?

Привет!

Меня зовут Эрик, в данный момент я инженер технической поддержки в компании Shortcut. Недавно я столкнулся с интересным тикетом: пользователи жаловались, что некоторые сайты не открываются в Google Chrome, но при этом прекрасно работают в других браузерах.

Кажется, что если сайт работает в одном браузере, он должен работать и в другом. Но это не всегда так. Иногда Chrome упорно отказывается загружать страницы, которые спокойно открываются в Firefox или Edge. Недавно я столкнулся с таким случаем в работе и хочу рассказать, как я разобрался с проблемой.

Именно так выглядел тикет!

Некоторые сайты, такие как:

• https://onlinedoctranslator.com/

• https://sciencesauceonline.com/

• https://childdevelop.info/

• https://wordleunlimited.org/

…не открываются в 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) — механизм, который Роскомнадзор блокирует.

Также в дампе были замечены множественные 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-записей

Итог

Эта ситуация хорошо показывает, как иногда браузеры могут стать жертвами сетевых ограничений. Надеюсь, теперь у вас есть инструменты, чтобы разобраться, если столкнётесь с похожей проблемой. А вы встречались с чем-то подобным?

Буду рад услышать ваши мысли в комментариях!