Chrome и Brave не загружают сайты в бета-версии macOS 27? Как это исправить

Вы установили публичную бета-версию macOS 27 «Golden Gate», открыли Chrome, ввели адрес — и… ничего. Вкладка крутится. В статусной строке написано Connecting…, и дело с мёртвой точки не двигается. Через некоторое время появляется голая ошибка — ERR_CONNECTION_TIMED_OUT, ERR_NAME_NOT_RESOLVED или бодрое сообщение Brave This site can't be reached. Вы пробуете другой сайт. То же самое. Любой сайт. Потом, почти по привычке, открываете Safari — и он загружает страницу мгновенно, с первого раза, без задержек. Интернет явно работает. Wi-Fi в порядке. И всё же то, что Chrome не загружает сайты в бета-версии macOS 27, превращается в проблему на весь день, причём то же самое происходит в Brave, Edge, Arc и Vivaldi.

Если это про вас — выдохните: с вашим Mac всё в порядке, и с сетью тоже. Это один из наиболее часто описываемых шероховатых моментов текущей бета-версии macOS 27 — паттерн, при котором браузеры на движке Chromium не могут ничего загрузить, а Safari работает без сбоев. Об этом пишут на форумах Brave Community, в темах Apple Discussions и на форумах MacRumors, посвящённых бета-версиям, и общая нить всегда одна: браузер на WebKit работает, браузеры на Chromium — нет. Это разделение и есть главная подсказка о том, что идёт не так, и именно поэтому большинство приведённых ниже исправлений быстрые, обратимые и не требуют сносить что-либо подчистую.

Это руководство делает две вещи. Во-первых, оно честно объясняет — с той осторожностью, какой заслуживает бета-версия — почему ломаются именно не-Safari браузеры. Во-вторых, оно даёт лестницу исправлений, по которой можно подниматься по порядку: от тридцатисекундного переключателя, который решает проблему для многих пользователей, до честного запасного варианта, который никому не нравится озвучивать вслух — это бета-версия, и иногда правильный ход — временно перейти на Safari или откатиться на стабильную Tahoe, пока Apple не выпустит новую сборку. Приступим к возвращению ваших браузеров к жизни.

Ключевые выводы

• То, что Safari работает, а Chrome, Brave, Edge, Arc и Vivaldi — нет, является характерным признаком этой проблемы беты. Это указывает на то, как текущая бета-версия macOS 27 маршрутизирует сетевой трафик для приложений не на WebKit — DNS, сетевые расширения и путь трафика для конкретных приложений, — а не на проблему какого-то одного браузера.
• Об этом сообщают тестировщики беты, а не подтверждает Apple. Об этом рассказывают темы на Brave Community, Apple Discussions и MacRumors; Apple не публиковала официального признания проблемы. Поведение может меняться от одной бета-сборки к другой, поэтому проверяйте заново после каждого обновления.
• Наиболее эффективные исправления просты и обратимы: отключите Secure DNS / DNS-over-HTTPS в браузере, отключите любое системное расширение сетевого фильтра или VPN (Little Snitch, LuLu, корпоративные фильтры, некоторые антивирусы), установите для IPv6 значение «Только Link-local» и очистите кэш DNS.
• Проверьте Private Relay и VPN в первую очередь. iCloud Private Relay и наполовину подключённые VPN-туннели ведут себя в бете иначе для Safari, чем для приложений на Chromium, и часто оказываются виновниками.
• Честный запасной вариант — Safari или откат. В бете некоторые проблемы просто ждут исправления от Apple. Если рабочий браузер на Chromium для вас обязателен, взвесьте откат на стабильную Tahoe вместо борьбы со сборкой.

Сначала: вы точно на бета-версии macOS 27?

Прежде чем менять хоть одну настройку, убедитесь, что вы действительно на той бета-версии, о которой идёт речь в этой статье, — потому что описанные здесь исправления нацелены именно на поведение беты и на стабильном релизе могут оказаться пустой тратой времени (или даже немного навредить).

Проверьте точную версию

Откройте меню Apple > Об этом Mac и посмотрите строку версии. Затем нажмите Подробнее > Обновление ПО (или Системные настройки > Основные > Обновление ПО), чтобы проверить, находитесь ли вы на бета-сборке.

• Если написано macOS 27.0 beta (или отображается баннер бета-версии для разработчиков/публичной беты), вы там, где нужно. Публичная бета появилась в середине июля 2026 года — Public Beta 1 вышла 13 июля, Public Beta 2 — 22 июля, — а самая свежая сборка для разработчиков на момент написания статьи — beta 4, сборка 26A5388g (20 июля). Apple не публиковала фиксированные номера сборок для публичных бета-версий, так что не стоит слишком зацикливаться на конкретном числе; честнее всего называть это «публичной бета-версией macOS 27».
• Если написано macOS 26.5.2 (сборка 25F84) или похоже, вы находитесь на стабильной Tahoe, а не на бете. В этом случае полное отключение Chromium — это не известный паттерн беты, и стоит рассматривать проблему как обычную сетевую неполадку. Начните с нашего полного руководства по устранению проблем с обрывом Wi-Fi и руководства по устранению проблем с VPN вместо описанных ниже шагов для беты.

Заметка для владельцев Mac на Intel

macOS 27 «Golden Gate» работает только на Apple Silicon — M1 и новее. В этом цикле поддержка всех Mac на Intel была прекращена. Если у вас Mac на Intel, вы физически не можете запускать бета-версию macOS 27, так что проблема с браузером у вас — это что-то совершенно другое. Это руководство предполагает Mac на чипе серии M, работающий на бете.

Помните, что здесь означает «бета»

Всё изложенное ниже основано на том, о чём сообщают тестировщики беты, собранном из форумов сообщества и публикаций в прессе. Ничто из этого не является дефектом, официально признанным Apple, с официальным исправлением. Это важно по двум причинам: поведение может меняться от сборки к сборке (исправление, нужное в Public Beta 2, может оказаться лишним после следующей сборки), а для некоторых тестировщиков единственным лекарством оказалось просто дождаться Apple. Настройте свои ожидания в соответствии с тем, что это предрелизная ОС.

Почему в бете macOS 27 ломаются только не-Safari браузеры

Самый полезный диагностический факт, который у вас есть, — это разделение между Safari и Chromium. Понимание того, почему они ведут себя по-разному, сразу указывает на нужные исправления, так что давайте разберём механизм — с оговоркой, что это обоснованный вывод из сообщений сообщества, а не доказанный путём реверс-инжиниринга факт.

Safari и Chromium используют разные сетевые пути

Safari построен на WebKit и тесно вплетён в macOS. Он опирается на нативный сетевой стек системы (NSURLSession, системный резолвер, системное хранилище доверенных сертификатов) так, как это ожидают собственные фреймворки Apple, и получает системные удобства — iCloud Private Relay, политику сети для конкретных приложений, DNS-резолвер ОС — как полноправный участник системы.

Браузеры на Chromium (Chrome, Brave, Edge, Arc, Vivaldi — все используют движок Chromium) делают значительную часть этой работы сами. Chromium поставляется с собственным сетевым сервисом, часто с собственным резолвером DNS-over-HTTPS, собственным пулом соединений и собственными представлениями о том, как открывать сокеты. Обычно эта независимость — сила. Но в бете, где Apple, возможно, меняет поведение сети для отдельных приложений, DNS или фильтрации через сетевые расширения, она становится уязвимостью: предположения Chromium и новое поведение беты могут разойтись так, как Safari никогда не столкнётся, — потому что Safari по умолчанию делает всё так, как задумано Apple.

Версия с сетевыми расширениями и DNS (с оговорками)

Современная macOS маршрутизирует трафик приложений через фреймворк сетевых расширений (network extension). Фильтры контента, VPN-клиенты, DNS-прокси и файрволы регистрируются как системные сетевые расширения и могут проверять, перенаправлять или блокировать трафик для конкретных приложений. Когда тестировщики беты сообщают, что Safari работает, а все браузеры на Chromium зависают, обе ведущие теории сообщества лежат именно в этой области:

1. Разрешение DNS не работает именно для приложений на Chromium. Если Chrome и Brave используют собственный Secure DNS (DNS-over-HTTPS), а бета что-то по-новому делает с обработкой DNS, поиск имён может зависать навсегда — именно так и выглядит бесконечный Connecting…. Safari, использующий системный резолвер, эту проблему обходит. Ошибки вроде ERR_NAME_NOT_RESOLVED прекрасно вписываются в эту теорию.
2. Фильтр на базе сетевого расширения молча отбрасывает трафик не-Safari браузеров. Инструменты, устанавливающиеся как сетевые расширения — Little Snitch, LuLu, корпоративные фильтры контента и некоторые антивирусные пакеты, — арбитрируют подключение для каждого приложения. Если бета изменила то, как расширения оцениваются или одобряются, фильтр может пропускать Safari, но отправлять трафик приложений на Chromium в никуда. Это та же разновидность трений беты, которую мы уже описывали применительно к фильтрам контента на базе сетевых расширений в материале об исправлении отключения из-за сетевого расширения в macOS Tahoe 26.5.1 — симптом другой, но напряжение испытывает та же подсистема.

Обе версии согласуются с отчётами, и, честно говоря, вероятно, единой универсальной причины тут нет — у разных тестировщиков, скорее всего, разные триггеры, наложенные на общий фундамент «Chromium идёт своим сетевым путём». Это хорошая новость с точки зрения починки: вам не нужно знать, какая причина именно у вас. Достаточно просто пройти по лестнице сверху вниз — обычно срабатывает одна из ступеней.

Расшифровка точного текста ошибки

Ошибка, которую показывает Chrome, значительно сужает круг причин, так что прочитайте её прежде чем начинать что-то кликать. Вот несколько распространённых сообщений и то, что они обычно означают в этой бете:

• ERR_NAME_NOT_RESOLVED — чистый сбой DNS. Браузеру вообще не удалось преобразовать домен в IP-адрес. Это явно указывает на исправление 1 (отключение secure DNS) и исправление 4 (очистка кэша). Это самый распространённый признак паттерна беты.
• ERR_CONNECTION_TIMED_OUT — имя разрешилось, но само соединение так и не установилось. Это скорее указывает на фильтр на базе сетевого расширения (исправление 2), гонку IPv6 (исправление 3) или наполовину живой VPN (исправление 5), молча поглощающий трафик.
• ERR_CONNECTION_REFUSED / ERR_CONNECTION_RESET — что-то активно закрыло соединение. На Mac с фильтром контента или расширением-файрволом это ваш фильтр, застрявший в процессе вынесения вердикта, — сразу переходите к исправлению 2.
• ERR_PROXY_CONNECTION_FAILED — настроен прокси (часто из-за оставшегося конфигурационного профиля или VPN-приложения), и он не работает. См. проверку профилей в исправлении 5.
• Вкладка, которая крутится бесконечно без ошибки — обычно это зависший, а не откровенно проваленный поиск DNS, что снова указывает на исправления 1 и 4.

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

Что такое «сетевое расширение» на самом деле, простыми словами

Если фраза сетевое расширение вам ни о чём не говорит, вот короткая версия — это важно, потому что половина исправлений ниже вращается именно вокруг этого. Много лет назад приложения, которым нужно было проверять или фильтровать ваш трафик (VPN, файрволы, родительский контроль, веб-щиты антивирусов), делали это с помощью расширений ядра, работавших с глубокими системными привилегиями. Apple уже несколько релизов подряд выносит всё это из ядра в изолированный (sandboxed) фреймворк пользовательского пространства под названием Network Extensions. Когда вы сегодня устанавливаете Little Snitch, корпоративный фильтр или VPN, он регистрируется как системное сетевое расширение, через которое macOS маршрутизирует ваш трафик, чтобы инструмент мог разрешать, блокировать или перенаправлять соединения — часто для каждого приложения отдельно.

Именно эта возможность работать с каждым приложением по отдельности и есть суть проблемы. Сетевое расширение в принципе может обращаться с Safari и Chrome по-разному, и оно зависит от ОС, которая сообщает ему, как устроены соединения. Когда бета меняет внутреннюю «сантехнику» — то, как одобряются расширения, как помечается трафик отдельных приложений, как расширению передаётся каждое соединение, — расширение, которое прекрасно ведёт себя для Safari, может в итоге отбрасывать или подвешивать трафик Chromium, причём никто этого не планировал. Именно поэтому шаг «отключите сетевое расширение и проверьте заново» здесь настолько важен, и именно поэтому так важно заново одобрять расширения после каждого обновления беты.

Почему это явно «бета», а не «ваш браузер сломан»

Если бы был сломан сам Chrome, переустановка помогла бы, а Brave, Edge, Arc и Vivaldi не отказывали бы все синхронно. Если бы была сломана ваша сеть, отказывал бы и Safari. Единственное, что чисто объясняет картину «все браузеры на Chromium мертвы, WebKit работает, тот же компьютер, тот же Wi-Fi», — это что-то на уровне ОС и сети, что по-разному обращается с этими двумя классами приложений, а именно такие вещи предрелизная ОС и делает неправильно. Стоит прочитать обзор известных проблем беты Golden Gate, чтобы понять контекст того, сколько шероховатостей есть в этой сборке.

Чек-лист быстрой диагностики за 60 секунд

Прежде чем переходить к полной лестнице исправлений, выполните эти пять быстрых проверок. Они почти ничего не стоят и часто сразу указывают на нужное исправление.

1. Загружает ли Safari сайт? Если да — подтверждено: это специфический для Chromium паттерн, и лестница ниже применима. Если Safari тоже не работает, это не ошибка браузера в бете — это общая проблема с подключением; перейдите к руководству по обрыву Wi-Fi.
2. Работает ли VPN или фильтр контента? Посмотрите в строке меню и в разделе Системные настройки > Основные > Элементы входа и расширения > Сетевые расширения. Если там что-то есть — это подозреваемый номер один.
3. Включён ли iCloud Private Relay? Системные настройки > [ваше имя] > iCloud > Private Relay. Отметьте, включён ли он.
4. Работают ли IP-адреса, когда доменные имена не работают? В Chrome попробуйте загрузить http://1.1.1.1. Если прямой IP-адрес загружается, а cloudflare.com — нет, проблема в DNS, и вам нужны исправления 1 и 4.
5. Ведёт ли себя так же совершенно новый профиль браузера? В Chrome откройте новое гостевое окно. Если оно тоже не работает, причина в системе, а не в вашем профиле, — переходите сразу к сетевым исправлениям.

Что бы ни показали эти пять проверок, вы всё равно можете просто начать с исправления 1 и идти по порядку. Полностью перезапускайте Chrome между исправлениями (Cmd+Q, а не просто закрытие окна), чтобы каждое изменение действительно вступало в силу.

Точно определите, где происходит сбой (необязательно, но эффективно)

Если вы хотите точно знать, на каком уровне происходит сбой, прежде чем менять настройки, пять безопасных команд Terminal вам это покажут. Ни одна из них ничего не изменяет — они только считывают состояние, — так что вы можете выполнить их все без риска. Смысл в том, чтобы разделить три вопроса: Достижима ли сеть вообще? Работает ли DNS? Работает ли системный HTTP-путь, даже если у Chrome не работает?

1. Можете ли вы достучаться до интернета по прямому IP-адресу? Это полностью обходит DNS.

ping -c 4 1.1.1.1

Если вы получаете ответы, у вашего Mac есть рабочее подключение, а проблема находится выше (DNS или на уровне отдельных приложений). Если и это не работает, у вас отказал бы и Safari, и вы имеете дело с общей проблемой подключения, а не с паттерном беты.

2. Работает ли разрешение DNS?

ping -c 4 cloudflare.com

Если шаг 1 сработал, а этот сообщает cannot resolve или зависает, вы подтвердили проблему с DNS — именно то, на что нацелены исправления 1 и 4.

3. Спросите напрямую у резолвера. dig и nslookup идут в комплекте с macOS и показывают, что возвращает системный резолвер:

dig cloudflare.com +short
nslookup cloudflare.com

Если здесь есть ответ, значит, системный резолвер работает нормально, а застряло собственное DNS-over-HTTPS браузера на Chromium — это веский сигнал, что поможет исправление 1 (отключение secure DNS в браузере, чтобы он полагался на этот работающий системный резолвер).

4. Загружает ли системный HTTP-стек страницу, даже если Chrome не может? curl использует собственную сеть macOS — тот же класс пути, что использует Safari:

curl -I https://www.cloudflare.com

Если curl возвращает заголовки (HTTP/2 200 и подобные), а Chrome зависает, вся диагностика умещается в одну строку: путь ОС работает, путь Chromium — нет. Это подтверждённый паттерн беты, и он означает, что описанные ниже системные исправления — ваш лучший вариант.

5. Какой DNS система использует на самом деле?

scutil --dns | grep nameserver
networksetup -getdnsservers "Wi-Fi"

Это покажет, не направил ли вас незаметно VPN, профиль или фильтр на DNS-серверы, которые вы не выбирали. Если вы видите неожиданные адреса, вернитесь к проверкам профилей и VPN из исправления 5.

Выполните эти пять команд, и вы будете знать ещё до того, как коснётесь настроек, гоняетесь ли вы за DNS, фильтром или проблемой пути отдельного приложения. Если Terminal — не ваше, полностью пропустите этот раздел: лестница исправлений прекрасно работает и без него.

Лестница исправлений

Двигайтесь сверху вниз. Проверяйте после каждого шага; остановитесь, когда сайты снова заработают. Каждый шаг здесь обратим.

Исправление 1: отключите Secure DNS / DNS-over-HTTPS в браузере

Это самое результативное исправление для этого паттерна беты, потому что встроенный зашифрованный DNS Chromium — это ровно тот тип самоуправляемой сети, который может рассинхронизироваться с бета-версией ОС. Вы указываете браузеру перестать самостоятельно разрешать имена и полагаться на систему.

В Chrome, Brave, Edge и Vivaldi:

1. Откройте Настройки > Конфиденциальность и безопасность > Безопасность.
2. Прокрутите до пункта Использовать безопасный DNS и полностью отключите его. (Не просто смените провайдера — именно отключите, чтобы браузер использовал резолвер ОС.)
3. Полностью закройте браузер (Cmd+Q) и откройте его заново.

В Arc: откройте Arc > Settings, найдите раздел конфиденциальности/безопасности и отключите secure DNS таким же образом; Arc отображает эту настройку Chromium в собственных меню.

Если в вашей диагностической проверке прямой IP-адрес загружался, а домены — нет, зачастую одного этого шага достаточно, чтобы всё исправить.

Исправление 2: отключите или удалите расширения сетевых фильтров, VPN и фильтров контента

Если вы используете Little Snitch, LuLu, корпоративный фильтр контента, приложение для DNS-фильтрации или антивирусный пакет с веб-защитой, оно почти наверняка установило себя как системное сетевое расширение — и это главный подозреваемый в том, что пропускает Safari, но блокирует Chromium в этой бете.

1. Перейдите в Системные настройки > Основные > Элементы входа и расширения, затем нажмите значок (i) рядом с Сетевые расширения (в более старых сборках путь может называться Network Extensions или Контент и конфиденциальность, в зависимости от сборки).
2. По очереди отключайте каждое стороннее расширение сетевого фильтра / VPN / файрвола.
3. После каждого переключения полностью закрывайте и заново открывайте Chrome, затем проверяйте.

Если отключение одного из них возвращает Chrome к жизни, вы нашли виновника. Дальше можно оставить его отключённым, пока Apple не выпустит исправленную сборку, обновить инструмент до последней версии (разработчики быстро выпускают патчи для бет) или проверить примечания вендора о совместимости с бетой. Если у вас управляемый/рабочий Mac, вы, возможно, не сможете отключить корпоративный фильтр самостоятельно — это случай для вашего ИТ-отдела, и это законный повод повременить с бетой. Наш материал о фильтрах контента на базе сетевых расширений подробнее разбирает, как эти расширения ведут себя, когда ОС меняется у них под ногами.

Исправление 3: установите для IPv6 значение «Только Link-local» для активной сетевой службы

Несколько тестировщиков сообщают, что гонка двухстекового (IPv4 + IPv6) соединения в Chromium зависает в бете, когда IPv6 ведёт себя неправильно, тогда как Safari это переносит. Принудительное отключение полного IPv6 для сетевой службы направляет трафик по рабочему пути IPv4.

Через Системные настройки (рекомендуется, щадящий способ):

1. Системные настройки > Сеть, выберите активную службу (Wi-Fi или Ethernet), нажмите Подробнее….
2. Перейдите на вкладку TCP/IP.
3. Установите для параметра Настроить IPv6 значение Только Link-local.
4. Нажмите OK, затем полностью закройте и заново откройте Chrome.

Через Terminal (эквивалентный способ, если вы предпочитаете командную строку): сначала выведите список имён ваших сетевых служб, затем отключите IPv6 для той, которую используете. Учтите, что -setv6off отключает IPv6 более полно, чем «Только Link-local» в графическом интерфейсе, но для локализации этой проблемы подходит любой вариант.

# See the exact network service names
networksetup -listallnetworkservices

# Turn IPv6 off for Wi-Fi (use your exact service name)
sudo networksetup -setv6off "Wi-Fi"

Чтобы позже восстановить обычный IPv6:

sudo networksetup -setv6automatic "Wi-Fi"

Исправление 4: очистите кэш DNS

Если проблема в DNS (а в этой бете часто именно так), устаревший или повреждённый кэш резолвера может продолжать удерживать неудачные запросы даже после того, как вы изменили настройку. Очистите его. Это стандартная безопасная пара команд macOS — она очищает кэш и перезапускает службу multicast DNS responder:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

У вас запросят пароль администратора. При успехе видимого вывода не будет — это нормально. После этого закройте и заново откройте Chrome и попробуйте открыть сайт. Для лучших шансов сочетайте это с исправлением 1 (отключение secure DNS); вместе они устраняют самый распространённый режим сбоя DNS, о котором сообщают для этой беты.

Исправление 5: проверьте Private Relay, VPN и конфигурационные профили

iCloud Private Relay и VPN оба меняют то, как трафик покидает ваш Mac, и оба обрабатываются по-разному для Safari и для приложений на Chromium, — что делает их классическими подозреваемыми в асимметричном сбое.

• iCloud Private Relay: Системные настройки > [ваше имя] > iCloud > Private Relay. Временно отключите его и проверьте Chrome заново. Private Relay маршрутизирует трафик только Safari и часть системного трафика, но его переключение может сбросить состояние сети, в котором застревал Chromium.
• VPN: если VPN подключён, полностью отключите его (а не просто сверните приложение) и проверьте заново. Наполовину подключённые или несовместимые с бетой туннели — очень частая причина того, что «браузер зависает навсегда». Если проблема окажется в VPN, пройдитесь по нашему руководству по устранению проблем с VPN в macOS — большинству VPN-клиентов нужно обновление с учётом беты.
• Конфигурационные профили: в разделе Системные настройки > Основные > Управление устройством (или Конфиденциальность и безопасность > Профили) удалите любой старый профиль DNS или прокси, который вы не узнаёте или который вам не нужен. Оставшиеся профили могут закреплять неработающие DNS-серверы.

Исправление 6: переключатель FaceTime / «Разрешить звонки на других устройствах», в который клянутся некоторые тестировщики

Это исправление странное, неподтверждённое, но стоит потраченных тридцати секунд, потому что группа пользователей форумов сообщает, что оно вернуло их браузеры на Chromium к жизни. Теория состоит в том, что переключение этой функции Continuity подталкивает сетевой стек к повторной инициализации путей для отдельных приложений, которые бета оставила в плохом состоянии.

1. Откройте FaceTime > Настройки (строка меню: FaceTime > Настройки).
2. Найдите пункт Звонки с iPhone / Разрешить звонки на других устройствах и отключите его, затем включите снова.
3. Либо на iPhone: Настройки > Телефон > Звонки на других устройствах, отключите и снова включите ваш Mac.
4. Проверьте Chrome заново.

Относитесь к этому как к народному средству, которое у некоторых срабатывает, а не как к гарантированному исправлению. Оно ничего не стоит и мгновенно отменяется, так что заслуживает свою ступень в лестнице.

Исправление 7: сбросьте сетевые настройки браузера или начните с нового профиля

Если системные исправления не помогли, выясните, не удерживает ли именно ваш профиль браузера повреждённое состояние сети.

• Chrome/Brave/Edge: откройте Настройки > Сброс настроек > Восстановить настройки по умолчанию. Это очищает пользовательские настройки DNS, прокси и запуска, не затрагивая ваши закладки и пароли.
• Проверка с новым профилем: создайте новый профиль (значок профиля > Добавить) или откройте гостевое окно и попробуйте открыть сайт. Если новый профиль работает, проблема была локальной для профиля — сбросьте старый или перейдите на новый.
• Очистите кэш сокетов/хостов: в Chrome перейдите на chrome://net-internals/#sockets и нажмите Flush socket pools, затем на chrome://net-internals/#dns и нажмите Clear host cache. (Brave и Edge открывают те же страницы под собственной схемой, например brave://net-internals.)

Исправление 8: переустановите браузер с чистого листа

Если после сетевых исправлений не работает только один конкретный браузер, переустановите его заново. Поскольку Chrome, Brave, Edge, Arc и Vivaldi используют один и тот же движок, делайте это, только если отстаёт один-единственный браузер, — системную причину переустановкой не вылечить.

1. Закройте браузер (Cmd+Q).
2. Перетащите его из папки Applications в Корзину.
3. Скачайте самую новую сборку прямо с сайта разработчика — исправления совместимости с бетой постоянно попадают в обновления браузера, так что актуальная сборка может уже лучше справляться с бетой.
4. Переустановите и проверьте заново. Синхронизированные данные (закладки, пароли) вернутся, когда вы снова войдёте в аккаунт.

Исправление 9 (запасной вариант с учётом реальности беты): используйте Safari или откатитесь на Tahoe

Вот честная часть. Это бета-версия, отключение браузеров сообщается тестировщиками, но не признано Apple, и некоторые тестировщики обнаружили, что ничто из лестницы выше не срабатывает окончательно, пока Apple не выпустит новую сборку. Если вы прошли всю лестницу до конца, а Chromium всё ещё мёртв, у вас есть два разумных варианта:

• Пока полагайтесь на Safari. Он работает, быстрый и импортирует ваши закладки. Использовать Safari для повседневного сёрфинга в течение нескольких недель, пока бета дозревает, — вполне разумное временное решение, и вы можете продолжать проверять Chrome после каждой новой сборки (поведение действительно меняется от сборки к сборке).
• Откатитесь на стабильную Tahoe. Если работающий браузер на Chromium для вас обязателен — для работы, для расширений, для рабочего процесса, который нельзя перенести, — самое чистое решение — покинуть бету. Следуйте нашему пошаговому руководству по откату с бета-версии macOS 27 на Tahoe без потери данных. А если вы только раздумываете насчёт беты, вся эта проблема — веский аргумент в пользу того, чтобы в следующий раз установить её безопасно на отдельный том, чтобы ваша рабочая система никогда не оказалась той, что ломается.

Ни в одном из этих вариантов нет ничего постыдного. Бета — это превью, которое вы добровольно согласились тестировать, а не обязательство мучиться со сломанным браузером.

Устранение распространённых проблем

Проблема: Chrome загружает одни сайты, но зависает на других в бете

Решение: частичная загрузка почти всегда означает проблему с DNS, а не полную блокировку. Некоторые имена разрешаются из кэша, тогда как новые запросы зависают. Выполните вместе исправление 1 (отключение secure DNS) и исправление 4 (очистка кэша DNS), затем полностью закройте Chrome и попробуйте снова. Если проблема сохраняется, установите системный DNS на обычный резолвер — Системные настройки > Сеть > Подробнее > DNS — и добавьте 1.1.1.1 и 8.8.8.8, чтобы ОС не полагалась на резолвер, с которым бета обращается неправильно.

Проблема: всё работало, а после обновления беты снова сломалось

Решение: ожидайте этого. Каждая новая сборка может сбрасывать одобрения сетевых расширений и переключать поведение. После любого обновления беты macOS 27 заново одобрите свои сетевые расширения в Системные настройки > Основные > Элементы входа и расширения > Сетевые расширения, затем заново выполните исправление 1 и исправление 4. Поскольку это непризнанное поведение беты, относитесь к каждой сборке как к новой диагностике, а не считайте, что предыдущее исправление всё ещё действует.

Проблема: рабочий или учебный Mac блокирует нужные мне исправления

Решение: управляемые Mac применяют корпоративные фильтры контента и конфигурационные профили, которые вы не можете отключить самостоятельно, и эти фильтры — главный подозреваемый в разделении «Safari работает / Chromium не работает». Не боритесь с MDM. Обратитесь в свой ИТ-отдел, сообщите, что браузер отказывает только для приложений на Chromium в бете macOS 27, и спросите, есть ли у поставщика их фильтра сборка, совместимая с бетой. Если нет, это явный сигнал, что рабочий/управляемый Mac пока не должен находиться на бете.

Проблема: отключение моего сетевого расширения починило Chrome, но мне нужен работающий инструмент

Решение: вы подтвердили виновника — теперь восстановите защиту правильным способом. Обновите инструмент (Little Snitch, LuLu, ваш антивирус) до последней версии, поскольку разработчики быстро выпускают патчи совместимости с бетой. Проверьте примечания к выпуску или форум разработчика на предмет упоминания macOS 27. Если совместимой сборки пока нет, вам приходится выбирать между инструментом и Chromium в этой бете — это законная причина взвесить откат на Tahoe, пока разработчик не наверстает.

Часто задаваемые вопросы

Почему Safari работает, а Chrome и Brave — нет в бете macOS 27?

Safari использует нативную сеть и DNS macOS, поэтому наследует всё, что изменила бета. Браузеры на Chromium управляют собственным DNS, сокетами и логикой соединений, что может рассинхронизироваться с новой обработкой сети для отдельных приложений в бете. Тот же компьютер, тот же Wi-Fi, разный сетевой путь — вот почему один работает, а остальные зависают.

Это официальный баг Apple, для которого готовится исправление?

Официально — нет. О проблеме сообщают тестировщики беты на Brave Community, Apple Discussions и MacRumors, её агрегирует пресса, но Apple не публиковала официального признания. Поскольку она живёт в предрелизной сборке, поведение может меняться с каждой новой сборкой, так что проверяйте заново после каждого обновления беты macOS 27.

Сделает ли отключение secure DNS мой браузинг менее приватным?

Немного, и только временно. Отключение DNS-over-HTTPS в браузере означает, что поиск имён использует ваш системный резолвер вместо зашифрованного. Для обходного решения на бете это вполне приемлемый компромисс, и вы сможете снова включить secure DNS, как только Apple выпустит сборку, которая нормально работает с Chromium. Ваш HTTPS-трафик страниц в любом случае остаётся зашифрованным.

У меня macOS 26.5.2, а не бета. Применимы ли эти исправления?

Скорее всего, нет. Полное отключение Chromium — это паттерн именно беты. На стабильной Tahoe 26.5.2 (сборка 25F84) неспособность браузера загружать сайты, скорее всего, вызвана обычной проблемой подключения, VPN или фильтром. Начните с руководств по Wi-Fi и VPN, указанных выше, а не с описанных здесь шагов для беты.

Может ли переустановка Chrome исправить проблему сама по себе?

Для этой проблемы — редко. Если Brave, Edge, Arc и Vivaldi отказывают вместе с Chrome, причина системная, и переустановка одного браузера не поможет. Переустанавливайте только тогда, когда отстаёт один-единственный браузер на Chromium, — и всегда берите самую новую сборку, поскольку обновления браузеров часто добавляют совместимость с бетой.

Стоит ли мне просто откатиться на Tahoe из-за этого?

Если рабочий браузер на Chromium важен для вашей повседневной работы, а лестница исправлений не помогла закрепить результат — да, это разумное решение. Следуйте руководству по откату, указанному выше, чтобы вернуться назад без потери данных. Если вы можете прожить на Safari несколько недель, оставаться на бете и проверять каждую новую сборку — путь с меньшими усилиями.

Заключение

Когда Chrome не загружает сайты в бете macOS 27, а Safari работает прекрасно, вы имеете дело не со сломанным Mac и не со сломанным браузером — вы видите, как предрелизная ОС по-разному обращается с независимым сетевым путём Chromium и с WebKit. Именно это понимание объясняет, почему исправления в основном сводятся к быстрым переключателям: отключите secure DNS в браузере, отключите расширение сетевого фильтра, установите для IPv6 значение «Только Link-local», очистите кэш DNS и проверьте Private Relay и VPN. Одна из этих ступеней срабатывает для большинства тестировщиков, и каждая из них отменяется за секунды.

Но держите в голове честную рамку: это поведение, о котором сообщают тестировщики беты, а не подтверждённый Apple баг, и в бете конечное решение иногда — просто терпение. Поведение меняется от сборки к сборке, поэтому проверяйте заново после каждой новой сборки — и если рабочий браузер на Chromium для вас незаменим, нет ничего постыдного в том, чтобы временно полагаться на Safari или откатиться на стабильную Tahoe, пока Apple не разберётся с проблемой. Вы добровольно согласились тестировать превью; относиться к сломанному браузеру как к ситуации «жду следующую сборку» — это как раз правильный инстинкт.

Ещё одна практическая привычка: следите за темпом выхода бет. Apple выпускает новые сборки примерно раз в одну-две недели — Public Beta 1 вышла 13 июля, Public Beta 2 — 22 июля, а бета для разработчиков 4 (сборка 26A5388g) — 20 июля, — и поведение сети действительно менялось от сборки к сборке. Поэтому разумная привычка — держать рабочее исправление на месте, отмечать, какая ступень сработала, а после каждой новой сборки ненадолго отключать этот обходной путь и проверять Chrome заново. Если новая сборка незаметно устранит основную проблему, вы захотите вернуть secure DNS и IPv6 к обычным настройкам, а не оставлять их изменёнными навсегда. Беты меняются; ваши обходные решения не должны быть постоянными.

Пройдите лестницу сверху вниз, остановитесь на первой ступени, которая вернёт ваши сайты к жизни, а если вы раздумываете, стоит ли вообще оставаться на Golden Gate, руководство по известным проблемам и обзор безопасной установки помогут вам принять решение с ясной головой.