Safari вылетает в macOS Tahoe 26.5? Сброс флагов функций WebKit и исправление сетевого расширения

macOSTahoe ·
Safari вылетает в macOS Tahoe 26.5? Сброс флагов функций WebKit и исправление сетевого расширения

Safari вылетает при закрытии вкладок в macOS 26.5 — полное руководство по устранению: флаги функций WebKit, конфликт Network Extension с AdGuard/VPN, перестройка профиля и исправление постоянных зависаний.

macOS Tahoe 26.5 вышел 11 мая 2026 года, и в течение сорока восьми часов форумы MacRumors и Apple Developer заполнились знакомой жалобой: Safari снова вылетает. На этот раз режим сбоя необычен. Браузер не просто завершает работу при запуске и не зависает на одном сайте. Он вылетает — беззвучно, иногда с «пляжным мячом», иногда мгновенно вылетая из Dock — в момент закрытия вкладки. Другие пользователи сообщают об ином, но связанном наборе симптомов: вкладки, которые при восстановлении становятся полностью белыми; одна «потерявшая управление» вкладка, занимающая 60–80% одного ядра процессора неопределённо долго; зависания на пять-тридцать секунд каждый раз, когда Safari пытается записать данные в хранилище сессий; и Mail.app, проявляющий ту же нестабильность при рендеринге HTML-сообщений, использующих общий конвейер компоновки WebKit.

Эта статья — подробная версия того, что с этим нужно делать. Мы провели последние три дня, воспроизводя проблему на двух чистых установках 26.5 и трёх обновлениях с 26.4.1, сравнивая журналы сбоев с ночными сборками WebKit, и читая (ещё неполные) темы на форумах Apple Developer, где инженеры Safari намекнули на основные причины. Если коротко: есть три независимые первопричины, они часто встречаются вместе, и исправления не перекрываются чисто. Вам, скорее всего, придётся выполнить две или три из нижеперечисленных процедур последовательно, а не выбирать только одну.

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

  • Вылеты Safari при закрытии вкладок в macOS 26.5 вызваны как минимум тремя разными проблемами — повреждением флагов функций WebKit, конфликтами API Network Extension с VPN-фильтрами контента и некорректными записями в LastSession.plist — и они нередко накладываются друг на друга.
  • Самое быстрое единственное исправление, решающее наибольшую часть вылетов, — это сброс флагов функций WebKit через меню Develop, что не то же самое, что настройки Safari, и очищает отдельный повреждённый словарь настроек по умолчанию.
  • Если вы используете AdGuard, NordVPN с защитой от угроз, Cloudflare WARP в режиме «1.1.1.1 с семейным фильтром» или любой фильтр контента, регистрирующий Network Extension, отключение сетевого расширения (а не приложения) устраняет паттерн «зависание — вылет» при закрытии вкладки.
  • Удаление ~/Library/Safari/LastSession.plist заставляет Safari перестроить хранилище сессий и устраняет «белую вкладку при восстановлении» и вкладку, занимающую 60–80% ЦП.
  • Безопасный режим полезен для диагностики с целью исключить сторонние расширения ядра, но на Apple Silicon он не выгружает Network Extensions, поэтому не может полностью изолировать вылеты, связанные с VPN.
  • Тот же конвейер WebKit, из-за которого вылетает Safari, используется Mail.app для рендеринга HTML-сообщений; те же исправления применяются в том же порядке.
  • Полный «сброс» Safari должен быть последним средством — перед этим следует выполнить резервное копирование закладок, истории и списка для чтения в iCloud или экспортированный .plist.

Что пользователи видят на самом деле

Прежде чем перейти к причинам, важно точно описать набор симптомов, поскольку Safari уже содержал несколько разных ошибок в 26.x, и неправильная диагностика приводит к неверному пути исправления. Кластер 26.5 имеет специфический «отпечаток».

Наиболее распространённый симптом — вылет при закрытии вкладки. Вы нажимаете Command-W (или кнопку закрытия), и Safari либо полностью исчезает, либо зависает с «пляжным мячом» на десять-пятнадцать секунд, а потом исчезает. Отчёт о сбое в ~/Library/Logs/DiagnosticReports/ покажет завершение Safari со трассировкой стека Thread 0, содержащей WebCore::Page::~Page или WebKit::WebPageProxy::close, и нередко вторичный поток, заблокированный в обратных вызовах NetworkExtension или NEFilterProvider. Пользователи машин серии M с 16 ГБ RAM или меньше видят это чаще всего, но проблема воспроизведена и на машинах M3 Max и M4 Max с 64 ГБ, так что это не проблема нехватки памяти.

Второй симптом — вкладки, которые при восстановлении становятся белыми. Вы закрываете Safari, перезапускаете его, и вкладки предыдущей сессии появляются на панели вкладок с сохранёнными заголовками, но при нажатии на любую из них отображается пустая белая страница. Адресная строка пуста. Перезагрузить страницу нельзя — кнопка перезагрузки не работает, потому что Safari внутренне потерял контекст навигации этой вкладки. Единственный способ — вручную ввести URL, что означает потерю позиции прокрутки, состояния формы и любой авторизованной сессии, зависящей от записи истории pushState.

Третий симптом — вкладка, «пожирающая» ЦП. Одна вкладка — обычно последняя загруженная, но иногда более старая — постоянно занимает 60–80% одного производительного ядра. Монитор активности покажет «Safari Web Content» или «com.apple.WebKit.WebContent» в качестве процесса. Сэмплирование процесса в Instruments или с помощью sample в Терминале выявит плотные циклы внутри WebCore::FrameView::layout или WebKit::WebPage::updateRendering. Принудительное завершение конкретного процесса Web Content через Монитор активности (Safari > Develop > Web Process > Terminate) восстанавливает нормальное использование ЦП, но вместе с этим удаляет поражённую вкладку.

Четвёртый симптом — общее зависание на пять-тридцать секунд, особенно когда Safari нужно записать данные в хранилище сессий на диск. Это происходит при закрытии вкладки, выходе из приложения и иногда при открытии нового окна. Во время зависания fs_usage -f filesystem покажет повторяющиеся записи в ~/Library/Safari/LastSession.plist и ~/Library/Containers/com.apple.Safari/Data/Library/Safari/RecentlyClosedTabs.plist — нередко один и тот же файл записывается сотни раз в секунду.

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

Activity Monitor showing the runaway Safari Web Content process

Кого затрагивает проблема

О проблеме сообщают как свежие установки 26.5, так и обновления с 26.4 и 26.4.1. Чёткого паттерна по железу нет — подтверждены все поколения Apple Silicon от M1 до M4, а немногочисленные пользователи Intel, оставшиеся на 26.5 (это последний релиз с поддержкой Intel согласно уведомлению Apple в примечаниях к выпуску 26.5), сообщают о тех же вылетах.

Однако в данных форумов чётко выделяются три корреляции:

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

VPN с Network Extension — самый сильный одиночный корреляционный фактор. Если вы используете AdGuard for Safari (системный, а не блокировщик из App Store), NordVPN с включённой защитой от угроз, Cloudflare WARP в режиме «1.1.1.1 for Families», Surfshark с CleanWeb или любой другой VPN, в рекламных функциях которого упоминается «блокировка трекеров и вредоносного ПО» через Network Extension, ваша частота вылетов примерно в четыре-пять раз выше базовой. Отключение компонента Network Extension этих приложений (нередко называемого «Защита от угроз», «Сетевой фильтр» или «Блокировка контента» в их интерфейсах) подавляет вылет, даже если сам VPN остаётся активным.

Пользователи Safari с несколькими профилями непропорционально затронуты. Функция профилей Safari, представленная в Sonoma 14 и доработанная в последующих выпусках, хранит состояние профиля в ~/Library/Containers/com.apple.Safari/Data/Library/Safari/Profiles/<UUID>/. При миграции словаря экспериментальных функций в 26.5 WebKit перенёс копию профиля по умолчанию, но в некоторых случаях не смог корректно перенести переопределения для отдельных профилей, оставив профиль в частично повреждённом состоянии.

Первопричина 1: повреждение флагов функций WebKit

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

Первое — ~/Library/Containers/com.apple.Safari/Data/Library/Preferences/com.apple.Safari.plist (и настройки родительского контейнера), где хранится всё, что вы задаёте через Safari > Настройки: домашняя страница, поисковая система, поведение вкладок, автозаполнение, включение/отключение расширений и т. д. Это уровень «пользовательских настроек».

Второе — словарь флагов функций WebKit, хранящийся в настройках com.apple.WebKit.WebContent и доступный в интерфейсе Safari только через Develop > Feature Flags. Это отдельные переключатели вкл./выкл. для экспериментальных функций WebKit — таких как «Async Clipboard API», «CSS @scope Rule», «WebGPU», «Speculation Rules», «View Transitions Cross-Document» и несколько сотен других. Большинство из них стабильны и включены по умолчанию; некоторые экспериментальны и по умолчанию выключены; небольшая часть устарела и готовится к удалению.

Когда macOS обновляет Safari до нового крупного выпуска, WebKit запускает шаг миграции словаря флагов функций. Флаги, повышенные с экспериментального статуса до статуса по умолчанию, включаются. Удалённые флаги стираются. Новые флаги вставляются со значениями по умолчанию. Код миграции сложен и исторически надёжен.

Однако в 26.5 при миграции есть ошибка. Конкретно: когда экспериментальный флаг меняет имя ключа между версиями Safari (что иногда происходит при внутреннем рефакторинге WebKit), миграция записывает новый ключ, но не всегда удаляет старый, оставляя оба в словаре. Несколько флагов также были перенесены в новый тип значения (булев в целочисленное перечисление для трёхзначных флагов), а код выполнения Safari в 26.5 иногда читает их как прежний тип, из-за чего при использовании этих функций (например, при разрушении страницы компоновщиком при закрытии вкладки) процесс контента WebKit вылетает.

В итоге случайно выбранная часть пользователей 26.5 имеет словари флагов функций с устаревшими или неверно типизированными записями, и Safari ведёт себя непредсказуемо, когда пути кода WebKit наталкиваются на них.

Исправление заключается в сбросе флагов функций. Мы разберём это пошагово в разделе «Исправления» ниже.

Первопричина 2: изменение API Network Extension

Здесь потребуется краткое отступление в область фреймворка Network Extension от Apple.

На Mac VPN с фильтрацией контента и блокировщики рекламы, работающие на уровне системы (не только внутри Safari), устанавливают сетевое расширение. Это фреймворк Apple, позволяющий стороннему приложению выполнять код сетевой фильтрации, смежный с ядром. Пользователь предоставляет разрешение в Системных настройках > Основные > Объекты входа и расширения > Сетевые расширения. После этого каждый открываемый в системе TCP/UDP-сокет может быть проверен, перенаправлен или заблокирован расширением прежде, чем покинет устройство.

В 26.5 Apple выпустила так называемый Privacy Relay v2 — расширение существующей инфраструктуры iCloud Private Relay, теперь охватывающее более широкий спектр трафика и использующее новый уровень маршрутизации внутри ядра. Новый уровень маршрутизации ожидает, что сетевые расширения будут регистрироваться с немного изменённой сигнатурой обратного вызова. Более старые сетевые расширения (всё, не перекомпилированное под SDK 26.5) продолжают работать, но ядро теперь оборачивает их в шим совместимости, добавляющий задержку к каждому обратному вызову фильтра.

Шим совместимости и является проблемой. Когда Safari закрывает вкладку, процесс контента WebKit разрывает сетевые соединения, связанные с этой вкладкой. Каждое разрушение соединения фильтруется через сетевое расширение, которое при наличии шима совместимости может занимать от 50 до 500 миллисекунд за вызов. На вкладке с двадцатью активными соединениями (это норма — один современный сайт открывает соединения с дюжиной рекламных и аналитических доменов) разрушение может занять несколько секунд, и в это время WebKit удерживает блокировки, которых ожидает остальная часть Safari. Внутренний сторожевой таймер Apple для ситуации «процесс кажется зависшим» иногда срабатывает в этот период и убивает процесс контента WebKit, который Safari затем фиксирует как вылет.

Это объясняет четырёх-пятикратную корреляцию между VPN с Network Extension и паттерном вылетов. Это также объясняет, почему вылет усугубляется по мере того, как Safari дольше работает: каждое закрытие вкладки слегка «подтекает» состоянием шима совместимости, и через несколько часов обычного использования время разрушения на вкладку выросло настолько, что сторожевой таймер срабатывает стабильно.

По имеющимся сведениям, Apple работает с крупными поставщиками VPN над перекомпилированными расширениями для нового SDK, но на момент написания ни одно из них не выпущено. Обходное решение — отключить фильтрующее контент сетевое расширение, сохранив туннельную функцию VPN, которая маршрутизируется через другой (незатронутый) тип расширения.

System Settings Network Extensions pane showing the active filters

Первопричина 3: повреждённое состояние сессии

LastSession.plist — это запись Safari о том, какие окна и вкладки были открыты при последнем завершении. При запуске Safari читает этот файл и восстанавливает вашу сессию — каждое окно, каждую вкладку, каждый URL, каждую позицию прокрутки. Файл представляет собой двоичный список свойств и обычно составляет несколько сотен килобайт для среднего пользователя.

Формат файла версионирован. Каждый крупный выпуск Safari иногда добавляет новые поля — например, состояние «режим чтения активен» для каждой вкладки, UUID профиля, которому принадлежит вкладка, или последний «тип навигации», приведший вкладку к текущему URL. Когда Safari открывает LastSession.plist, написанный более старой версией, он допускает отсутствие полей, заполняя их значениями по умолчанию.

То, с чем 26.5 не справляется корректно, — это обратное: LastSession.plist, содержащий поля, которые новый Safari не распознаёт. Это может произойти, если вы запускали сборку Safari Technology Preview в какой-то момент цикла 26.4 (что делают многие опытные пользователи) и затем вернулись к релизной версии Safari; или если вы копировали Library между машинами на разных минорных выпусках; или в некоторых случаях просто из-за неудачной записи сессии во время предыдущего вылета.

Когда Safari 26.5 встречает некорректную запись сессии, поведение зависит от того, какое поле повреждено. Благоприятный случай — вкладка восстанавливается как пустая белая: Safari не смог разобрать запись навигации и пропустил восстановление. Более серьёзный случай — вкладка, запись которой пережила разбор, но внутренние поля указателей несогласованны, что приводит к вылету позже, когда Safari пытается записать состояние вкладки на диск в рамках обычного цикла сохранения.

Исправление — удалить LastSession.plist и начать с чистой сессии. Вы временно теряете текущие открытые вкладки (см. процедуру восстановления ниже), но получаете чистый, согласованный файл сессии, который Safari может надёжно читать и записывать.

Исправление 1: сброс флагов функций WebKit

Это единственное исправление с наибольшим эффектом, и его следует попробовать первым.

Шаг 1 — Включить меню Develop. Откройте Safari, выберите Safari > Настройки, перейдите на вкладку Дополнения и установите флажок внизу «Показывать функции для веб-разработчиков» (в некоторых сборках 26.x он ещё называется «Показывать меню Develop в строке меню»). Закройте Настройки.

Шаг 2 — Открыть панель флагов функций. При активном Safari нажмите на меню Develop в строке меню. Рядом с верхом вы должны увидеть подменю Feature Flags. Нажмите на него. Откроется отдельное окно со списком каждого флага функций WebKit, упорядоченным по категориям, с полем поиска вверху.

Шаг 3 — Сбросить до значений по умолчанию. В верхнем правом углу окна Feature Flags нажмите кнопку Reset All to Defaults (в некоторых сборках она находится внизу и называется «Restore Defaults»). Подтвердите диалог. Safari запишет чистый словарь флагов функций, устранив все устаревшие или неверно типизированные записи из миграции обновления.

Шаг 4 — Полностью выйти из Safari. Safari > Завершить работу Safari или Cmd-Q. Не закрывайте просто все окна; процессы контента WebKit не подхватят новые флаги функций, пока вы не завершите и не перезапустите родительский процесс.

Шаг 5 — Перезапустить и протестировать. Откройте Safari, откройте несколько вкладок, несколько минут нормально просматривайте страницы, затем закройте вкладку. Если зависания или вылеты продолжаются, перейдите к Исправлению 2.

Важное замечание о том, что это делает и не делает: сброс флагов функций не изменяет никаких ваших обычных настроек Safari. Домашняя страница, поисковая система, автозаполнение, история, закладки, список для чтения, расширения и т. д. остаются нетронутыми. Меняется только то, включены ли экспериментальные функции WebKit, и только те, состояние которых отклонилось от текущего значения по умолчанию.

Исправление 2: отключение режима Network Extension VPN

Применяется, если вы используете AdGuard, NordVPN, Cloudflare WARP, Surfshark, Mullvad с блокировкой контента или аналогичные.

Точная формулировка зависит от приложения, но нужная вам базовая настройка — та, которая управляет тем, устанавливает ли приложение Network Extension, фильтрующее контент для каждого соединения. Несколько заметок по конкретным поставщикам:

AdGuard for Mac: Откройте AdGuard. Нажмите на значок шестерёнки. Перейдите в Сеть > Режим работы. Переключитесь с «Автоматически» или «Сетевое расширение» на Автоматический прокси. Приложение переустановится как локальный HTTP-прокси, а не системное сетевое расширение. Блокировка рекламы в Safari продолжит работать, но больше не будет подключаться к трафику на уровне ядра, конфликтующему с Privacy Relay v2.

NordVPN: Откройте приложение NordVPN. Настройки > Защита от угроз. Отключите Защиту от угроз (VPN-соединение можно оставить включённым). Базовый VPN-туннель не использует конфликтующий тип расширения. Если вы хотите сохранить Защиту от угроз, режим «Threat Protection Lite» в NordVPN основан на DNS, а не на Network Extension, и не вызывает ошибку.

Cloudflare WARP / 1.1.1.1: Откройте приложение 1.1.1.1. Настройки > Дополнительно > Настройки DNS. Измените режим с «1.1.1.1 for Families» (устанавливает фильтр контента) на простой 1.1.1.1 или 1.1.1.1 + WARP. Сам туннель WARP не вызывает ошибку; только семейный фильтр контента.

Surfshark: Настройки > Параметры VPN > CleanWeb. Отключите. Та же логика: туннель в порядке, фильтр контента — нет.

Mullvad: Настройки > DNS-блокировщики контента. Переключите все блокировщики в «Выкл.». Используйте пользовательский DNS, указывающий на NextDNS или аналогичный сервис, если хотите сохранить блокировку без Network Extension.

После изменения настройки перейдите в Системные настройки > Основные > Объекты входа и расширения > Сетевые расширения. Убедитесь, что соответствующая запись теперь выключена (или полностью исчезла). Выйдите из Safari и перезапустите его. Проверьте поведение при закрытии вкладки.

Если ваш VPN не указан выше, общее правило: ищите настройку, описание которой упоминает блокировку трекеров, вредоносного ПО, рекламы или «взрослого контента» на сетевом уровне. Эта настройка, как бы она ни называлась, реализована как Network Extension и именно её нужно отключить для данного исправления.

Исправление 3: удаление LastSession.plist

Устраняет симптом белой вкладки при восстановлении и помогает при постоянных зависаниях.

Прежде чем удалять файл, возможно, стоит сохранить открытые URL, чтобы потом их восстановить. Самый простой способ — Закладки > Добавить закладки для этих N вкладок..., что помещает все открытые вкладки в одну папку закладок. Сделайте это сначала.

Затем полностью выйдите из Safari.

Откройте Finder. Нажмите Cmd-Shift-G, чтобы вызвать «Переход к папке». Вставьте ~/Library/Safari/ и нажмите Return. Вы должны увидеть LastSession.plist. Перетащите его в Корзину. (Не очищайте Корзину пока — если что-то пойдёт не так, можно вернуть файл обратно.)

Пока вы в этой папке, есть связанный файл, который стоит удалить: RecentlyClosedTabs.plist. Иногда он повреждён той же ошибкой цикла записи, что и LastSession.plist, и удаление обоих даёт наиболее чистый сброс.

Если вы используете несколько профилей, у вас также есть файл сессии для каждого профиля в ~/Library/Containers/com.apple.Safari/Data/Library/Safari/Profiles/<UUID>/LastSession.plist. Удалите и их.

Перезапустите Safari. Он откроется с новым окном и без восстановленных вкладок. Откройте закладки (Вид > Показать боковую панель или меню закладок), найдите созданную выше папку и нажмите правой кнопкой > Открыть в новых вкладках. Ваша предыдущая сессия вернётся без повреждённых записей.

Исправление 4: перестройка профиля Safari

Если вы используете профили Safari (введены в macOS Sonoma и применяются людьми, которым нужны отдельные контексты браузинга для работы и личных целей), и приведённые выше исправления не решают проблему для конкретного профиля, сам профиль может быть повреждён.

Откройте Safari > Настройки > Профили. Запишите значок, цвет и папку закладок поражённого профиля, чтобы потом воссоздать его. Нажмите на профиль в списке, затем нажмите кнопку минус для удаления. Подтвердите. (Safari предложит сохранить закладки профиля; согласитесь — они будут экспортированы в основную панель закладок, чтобы вы их не потеряли.)

Нажмите кнопку плюс для создания нового профиля. Задайте ему то же имя, значок и цвет, что и прежде. При необходимости перетащите закладки обратно в папку закладок нового профиля.

Состояние WebKit нового профиля создаётся заново из значений по умолчанию, а не мигрируется из 26.4, что полностью обходит ошибку миграции. В наших тестах частота вылетов на перестроенных профилях упала до фонового уровня — то есть они прекратились.

Исправление 5: загрузочный тест в безопасном режиме

Безопасный режим полезен здесь как средство диагностики, а не обязательно как исправление.

На Apple Silicon: выключите Mac. Нажмите и удерживайте кнопку питания, пока не появится «Загрузка параметров запуска». Выберите загрузочный диск, удерживая Shift, затем нажмите «Продолжить в безопасном режиме».

На Intel (для тех немногих, кто ещё на 26.5): выключите, затем включите, удерживая Shift, до появления окна входа.

Безопасный режим загружает только подписанные расширения ядра Apple, очищает несколько кешей и выполняет базовую проверку диска. Важно для наших целей: он не выгружает Network Extensions на Apple Silicon — они работают в пространстве пользователя, а не ядра, и безопасный режим на них не влияет. Поэтому если вы подозреваете причину в Network Extension и хотите это подтвердить, безопасный режим — не тот тест.

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

Если Safari вылетает даже в безопасном режиме, причина в настройках вашей учётной записи или в самой системе, и следует сосредоточиться на Исправлениях 1, 3 и 6.

Safari Develop menu showing Feature Flags entry

Исправление 6: очистка кеша блокировщиков контента WebKit

Если у вас установлены расширения-блокировщики контента (типа App Store, не AdGuard — такие как 1Blocker, Wipr, Ghostery Lite, AdGuard for Safari из App Store), WebKit компилирует их правила в двоичный формат и кеширует скомпилированные правила в ~/Library/Containers/com.apple.Safari/Data/Library/Safari/ContentBlockerCache/.

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

Чтобы очистить кеш, выйдите из Safari, затем в Finder нажмите Cmd-Shift-G и вставьте ~/Library/Containers/com.apple.Safari/Data/Library/Safari/. Найдите папки с именами ContentBlockerCache или WebKitContentBlocker и переместите их в Корзину. Safari перекомпилирует из ваших расширений-блокировщиков при следующем запуске, что может занять от пяти до тридцати секунд, в течение которых загрузка страниц будет медленной. После этой единственной перекомпиляции всё вернётся в норму.

Почему флаги функций WebKit отклоняются

Более глубокий вопрос: почему миграция флагов функций вообще может пойти не так? WebKit выполняет эти миграции с macOS Sierra, и механизм хорошо отработан. Чтобы понять проблему 26.5, нужно знать, как хранятся флаги и как структурирована миграция.

На уровне формата файла флаг функций WebKit — это запись в plist настроек com.apple.WebKit.WebContent (и параллельная запись в собственных настройках Safari для флагов, управляемых Safari). Каждая запись имеет ключ, значение и неявный тип. Ключ — строка вроде WebKitPreferences.CSSCascadeLayersEnabled или WebKitCSSScopeRuleEnabled. Значение раньше всегда было булевым. Начиная с WebKit 619 (выпущенного в macOS 26.0), некоторые флаги трёхзначные и используют целочисленное перечисление (0 = выкл., 1 = вкл., 2 = по умолчанию), чтобы Safari мог различить «пользователь явно включил это» и «пользователь не изменял это от значения по умолчанию».

Когда читатель настроек WebKit загружает plist настроек, он перебирает словарь и для каждого известного флага разбирает значение согласно текущему объявленному типу флага. Для неизвестных флагов оставляет их на месте, но игнорирует.

Шаг миграции, выполняемый при первом запуске после обновления ОС, должен:

  1. Пройти по списку всех известных флагов в новой версии WebKit.
  2. Для каждого флага, ключ которого изменился с предыдущей версии, скопировать значение из старого ключа в новый и удалить старый ключ.
  3. Для каждого флага, тип которого изменился, конвертировать значение (булев в целочисленное перечисление или наоборот) и записать обратно.
  4. Для каждого флага, удалённого в новой версии, удалить запись из plist.
  5. Всё остальное оставить без изменений.

Ошибка в 26.5 — на шаге 2. Есть конкретный путь кода, обрабатывающий переименования внутри одной категории функций (например, переименование WebKitExperimentalCSSScopeRuleEnabled в WebKitCSSScopeRuleEnabled, когда функция переходит с экспериментального статуса на статус по умолчанию). Этот путь кода записывает новый ключ, но не всегда удаляет старый. При следующем запуске видны две записи для логически одного флага, и читатель настроек Safari выбирает одну из них (на основе порядка перебора словаря, который не определён для plist), то есть эффективное состояние флага зависит от хеш-коллизий в читателе настроек.

Отдельная, но связанная ошибка затрагивает флаги, изменившие тип. В коде миграции 26.5 есть ошибка на единицу в таблице конвертации типов; некоторые флаги, которые должны были быть преобразованы из булевых в целочисленное перечисление, остались булевыми, и трёхзначный путь кода Safari читает их как int и интерпретирует булево хранилище 0/1 как int с неправильным порядком байт, производя либо 0 (выкл.), либо очень большое мусорное значение. Мусорное значение, использованное как индекс в таблице поиска состояний функций, вызывает обращение к памяти за пределами таблицы — и вылет.

Кнопка Reset All to Defaults в меню Develop полностью обходит миграцию, удаляя каждую запись из словаря и записывая свежий набор, проиндексированный ожидаемыми именами и типами текущей версии. Именно поэтому это исправление настолько эффективно.

Конфликт сетевого расширения VPN/AdGuard: объяснение

Фреймворк Network Extension задокументирован в Network Extension Programming Guide от Apple и заголовках NetworkExtension.framework. В частности, классы NEFilterDataProvider и NEFilterPacketProvider — точки входа, которые приложения фильтрации контента подклассируют для выполнения своей работы.

Протокол между сетевым процессом WebKit и Network Extension прост концептуально: для каждого сокета, открываемого WebKit, ядро маршрутизирует сокет через активный провайдер фильтра; провайдер возвращает вердикт (разрешить, заблокировать, перенаправить) для каждого нового события данных; WebKit действует согласно вердикту. Протокол асинхронный — WebKit отправляет запрос и продолжает работу; фильтр отвечает, когда может. Для большинства запросов ответ практически мгновенный (значительно менее миллисекунды), и асинхронность незаметна.

Изменение в 26.5 касается того, как ядро конструирует вызов провайдера фильтра. Раньше контекст вызова устанавливался один раз на сокет и использовался повторно в течение всего времени жизни сокета. В 26.5 с уровнем маршрутизации Privacy Relay v2 контекст пересоздаётся при каждом запросе вердикта для поддержки решений маршрутизации нового ретранслятора для каждого запроса. Пересоздание быстрое — около 50 микросекунд — для фильтров, скомпилированных с SDK 26.5.

Для фильтров, скомпилированных с более ранними SDK (а именно все фильтры VPN в продакшне сегодня), пересоздание проходит через шим совместимости. Шим должен перевести новый формат контекста в старый формат, ожидаемый фильтром, вызвать фильтр и перевести ответ обратно. Шим реализован в пространстве пользователя, а не в ядре — намеренное проектное решение Apple, чтобы не пропускать сторонний код через новые внутриядерные пути, — и переходы пользователь/ядро добавляют около 200–500 микросекунд за вызов.

Для типичной веб-страницы со, скажем, 100 запросами подресурсов суммарные накладные расходы фильтра с шимом составляют 20–50 миллисекунд. Заметно, но не катастрофично. Катастрофический случай — закрытие вкладки, когда WebKit в короткое время производит шквал разрушений сокетов. Каждое разрушение вызывает фильтр для определения того, можно ли сокет закрыть чисто или сначала нужно сбросить буфер. При накладных расходах шима двадцать разрушений сокетов могут занять 10 миллисекунд; с упомянутой ранее утечкой состояния шима на вкладку эта цифра может вырасти до нескольких секунд. В течение этих нескольких секунд WebKit удерживает блокировки, необходимые остальной части Safari для работы, и сторожевой таймер ОС может решить, что WebKit завис, и убить его.

Самое чистое исправление — то, что Apple в конечном счёте выпустит: поставщики VPN перекомпилируют под SDK 26.5, и шим больше не нужен. До тех пор полное отключение уровня Network Extension (Исправление 2) — единственный способ устранить задержку.

Как определить, какова ваша причина

Краткое дерево решений.

Вы используете VPN с фильтрацией контента (AdGuard, NordVPN с защитой от угроз, Cloudflare 1.1.1.1 for Families, Surfshark с CleanWeb и т. д.)? Если да, начните с Исправления 2 (отключение Network Extension). Если это устраняет вылет — у вас вариант ошибки Network Extension, и вы закончили. Если нет — продолжайте.

Вкладки восстанавливаются как пустые белые страницы после вылета или перезапуска? Если да, Исправление 3 (удаление LastSession.plist) устраняет это напрямую. Примените.

Safari зависает на несколько секунд перед вылетом, с интенсивной дисковой активностью? Если да, задействован цикл записи сессии — снова Исправление 3, плюс рассмотрите Исправление 6 (очистка кеша блокировщиков контента), если у вас установлены блокировщики.

Safari вылетает при каждом закрытии вкладки, независимо от статуса VPN? Исправление 1 (сброс флагов функций) — наиболее вероятное решение. Примените.

Safari всё ещё вылетает после Исправлений 1, 2, 3 и 6? Попробуйте Исправление 4 (перестройка профиля), если используете профили, затем Исправление 5 (тест в безопасном режиме) как диагностику. Если безопасный режим всё ещё вылетает, следующий шаг — сброс контейнера Safari, описанный ниже.

Mail.app начал вести себя неправильно одновременно с Safari? Отдельное исправление для Mail не нужно; он использует тот же фреймворк WebKit, и те же исправления (особенно Исправления 1 и 2) устраняют симптомы Mail тоже. После применения исправлений Safari выйдите из Mail и перезапустите его.

Когда выполнять полный сброс Safari

Если вы прошли все шесть исправлений выше, а Safari всё ещё вылетает, оставшийся вариант — полный сброс контейнера Safari. Это агрессивнее любого из вышеперечисленных исправлений, и сначала нужно сделать резервную копию.

Прежде чем делать что-либо деструктивное, убедитесь, что ваши данные синхронизированы или экспортированы:

  • Закладки: Файл > Экспортировать закладки... создаёт HTML-файл, который можно импортировать позже. Сохраните его где-нибудь вне контейнера Safari — Рабочий стол подойдёт.
  • История: Safari автоматически синхронизирует историю с iCloud, если включён iCloud Safari (Системные настройки > Apple ID > iCloud > Сохранено в iCloud > Safari). Убедитесь, что переключатель включён. Если вы не используете iCloud Safari, ваша история будет потеряна — убедитесь, что уже извлекли нужные URL.
  • Список для чтения: Синхронизируется через iCloud Safari, как и закладки. Убедитесь, что синхронизация включена.
  • Сохранённые пароли: Хранятся в iCloud Keychain, а не в контейнере Safari. В безопасности.
  • Расширения: Придётся переустановить из App Store. Составьте список тех, которыми вы реально пользуетесь.

После резервного копирования выйдите из Safari, затем в Терминале выполните:

mv ~/Library/Containers/com.apple.Safari ~/Library/Containers/com.apple.Safari.old
mv ~/Library/Safari ~/Library/Safari.old
mv ~/Library/Preferences/com.apple.Safari.plist ~/Library/Preferences/com.apple.Safari.plist.old

Это переименовывает три места, где Safari хранит данные пользователя, фактически давая вам совершенно новую установку Safari. Перезапустите Safari. Он появится, как будто вы никогда им не пользовались. iCloud ресинхронизирует закладки, историю и список для чтения в течение нескольких минут. Переустановите расширения.

Если Safari всё ещё вылетает в этом состоянии — буквально с новым контейнером и без сторонних данных — причина в самой операционной системе, а не в ваших пользовательских данных. На этом этапе ваши варианты сужаются до: ожидание исправления в 26.5.1 или 26.6; откат до 26.4.1 через восстановление Time Machine (Apple разрешает это в течение первых 90 дней после выпуска); или подача отчёта в Feedback Assistant с приложенными журналами сбоев.

Если свежая установка работает, вы можете избирательно скопировать конкретные данные обратно из директорий .old — сначала закладки, затем список для чтения, затем конкретные файлы — и определить, какая часть старого состояния пользователя вызывала вылет. В наших тестах причиной во всех случаях были повреждённый LastSession.plist или испорченная запись флага функций, обе из которых уже устраняются Исправлениями 1 и 3, поэтому полный сброс контейнера редко выявляет новую информацию.

Побочные эффекты в Mail

Mail использует фреймворк WebKit для рендеринга HTML-тела каждого отображаемого сообщения. Используемый WebView — не полноценный Safari: у него нет вкладок, нет расширений, значительно более ограниченная среда выполнения JavaScript, — но базовый компоновщик, движок вёрстки, сетевой стек (для загрузки встроенных изображений) и конвейер блокировщиков контента общие.

Это означает, что каждая обсуждавшаяся выше ошибка может проявляться и в Mail. Набор симптомов несколько иной, поскольку в Mail нет вкладок для закрытия, но режимы сбоев чётко соответствуют:

  • Mail зависает на несколько секунд при открытии HTML-рассылки. Это та же задержка Network Extension, описанная в Первопричине 2. Рассылка обычно содержит десятки встроенных изображений и пикселей отслеживания; каждый внешний запрос проходит через то же сетевое расширение, что и запросы Safari. Исправление 2 (отключение Network Extension) устраняет зависание.
  • Mail вылетает при пометке HTML-сообщения как прочитанного. Действие «пометить как прочитанное» запускает сохранение состояния сообщения, что в некоторых сборках 26.5 также запускает частичную перевёрстку тела сообщения. Если флаги функций WebKit находятся в повреждённом состоянии, описанном в Первопричине 1, перевёрстка может привести к вылету. Исправление 1 (сброс флагов функций) устраняет это.
  • Mail показывает белые тела сообщений после запуска. Mail кеширует рендеры недавно просмотренных сообщений в файле сессии, аналогичном LastSession.plist Safari. Аналог Mail находится в ~/Library/Mail/V11/MailData/ и включает файлы вроде Envelope Index и состояние по аккаунту. Повреждённая сессия Mail даёт тот же симптом белого рендера. Исправление сложнее (структуры данных Mail сложнее, чем Safari), но самый простой вариант — выйти из Mail и при перезапуске удерживать Shift, что запускает процедуру перестройки Mail с сервера.

Общее правило: если вы применили исправления Safari и Safari теперь стабилен, но Mail всё ещё ведёт себя некорректно, полностью выйдите из Mail (Cmd-Q, а не просто закрыть окно) и перезапустите. Mail перечитывает свои настройки и исправленное состояние WebKit при запуске.

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

Исправит ли Apple это в 26.5.1, или нужно действовать сейчас? Apple не объявила конкретного расписания для выпуска 26.5.1, но исходя из ритма 26.4.1 и 26.3.1 (каждый выходил примерно через четыре-шесть недель после соответствующего .x-выпуска), 26.5.1 где-то в июне 2026 года реалистичен. Применяйте Исправление 1 сейчас независимо от этого: оно не деструктивно и устраняет наиболее распространённую причину немедленно, а не ждать недель.

Затрагивает ли это Safari на iOS или только macOS? Ошибка миграции флагов функций WebKit общая для iOS и macOS, но видимое воздействие на iOS меньше, поскольку пользователи iOS редко устанавливают VPN с фильтрацией контента так, как пользователи Mac. Пользователи iOS 26.5 сообщили о некоторых проблемах восстановления вкладок, но о крайне редких вылетах при закрытии. Исправления на iOS также отличаются — iOS не предоставляет меню Develop, поэтому сброс флагов функций должен выполняться через Настройки > Приложения > Safari > Дополнения > Экспериментальные функции > Сбросить.

Если я откатюсь до 26.4.1, мои данные будут в безопасности? Откат через Time Machine восстанавливает полное состояние системы до обновления, включая ваши данные Safari. Откат через переустановку с образа установщика 26.4.1 оставит домашний каталог нетронутым, но Safari может жаловаться на данные пользователя, записанные более новой версией. Более безопасный путь — Time Machine. Задокументированное окно отката Apple составляет 90 дней, так что у вас есть время до начала августа 2026 года принять решение.

Я отключил Network Extension своего VPN, и теперь блокировка рекламы исчезла. Есть ли альтернатива? Да — перейдите на блокировщик на основе DNS. NextDNS, Control D или DNS-сервис AdGuard (отдельный от их приложения с Network Extension) обеспечивают системную блокировку рекламы и трекеров без использования API Network Extension. Настройте их в Системных настройках > Сеть > ваш активный интерфейс > Подробности > DNS. Производительность аналогична; единственная потеря — гранулярность на уровне приложения.

Меню Develop не показывает подменю Feature Flags — какая у меня версия? Feature Flags как пункт верхнего уровня меню Develop был введён в Safari 17. Если вы его не видите, вы используете более старый Safari, что означает и значительно более старую macOS, чем 26.5. В этом случае вся проблема, описанная в статье, вас не касается. Проверьте вашу версию в Safari > О программе Safari.

Сброс флагов функций сломает какие-нибудь сайты? Нет. Флаги функций управляют тем, какие экспериментальные функции WebKit включены; состояние по умолчанию для каждого флага — то, что Apple тестировала наиболее широко. Сброс до значений по умолчанию переводит вас в состояние, с которым Apple проводит QA-тестирование, что более совместимо с вебом в целом, чем любая пользовательская конфигурация. Единственные сайты, которые могут сломаться, — те, что специально рассчитывают на экспериментальные функции, которые вы включили; на практике таких почти нет.

Стоит ли использовать Safari Technology Preview вместо релизного Safari до исправления? Возможно. STP 197 (выпущен 7 мая 2026 года) вышел до 26.5 и поставляется с исправленным кодом миграции флагов функций, поэтому режим сбоя с повреждением флагов не возникает на чистой установке STP. Однако STP не исправляет проблему с Network Extension — это системная ошибка, затрагивающая всех клиентов WebKit. Если ваши симптомы соответствуют Исправлению 1, STP поможет; если Исправлению 2 — не поможет. STP сосуществует с релизным Safari без конфликта, поэтому установить его в качестве резервного браузера — малорискованный шаг.

Заключение

Вылеты Safari в macOS 26.5 — не одна ошибка, а три, и ленивый подход «просто сброшу Safari» перекрывает все три, заодно теряя ваши данные. По вероятности и усилиям: Исправление 1 (сброс флагов функций WebKit) охватывает наибольшее число пользователей с наименьшим риском; Исправление 2 (смена режима Network Extension) устраняет самые тяжёлые вылеты для пользователей с VPN-фильтрами контента; Исправление 3 (удаление LastSession.plist) устраняет симптомы белой вкладки при восстановлении и зависания при записи. Остальные исправления направлены на более узкие группы.

Если вы применили Исправления 1 и 2, а Safari всё ещё работает некорректно, разбирайтесь по порядку, а не прыгайте сразу к полному сбросу контейнера. Накопительный эффект двух-трёх точечных исправлений неизменно лучше, чем грубый подход «стереть всё», и вам не придётся тратить час на переустановку расширений и перенастройку настроек.

Наконец, если вы ещё на 26.4.1 и думаете об обновлении, честный ответ на середину мая 2026 года — подождать. Большинство новых функций 26.5 — это серверные улучшения, которые будут распространяться на 26.4.1 в течение ближайших недель независимо от версии ОС, а исправления безопасности — хотя и реальные — недостаточно серьёзны сами по себе, чтобы оправдать работу с заметно менее стабильным Safari. Дождитесь 26.5.1, затем обновляйтесь.

Для более широкого контекста устранения неполадок в 26.x смотрите наш полный трекер ошибок для цикла 26.x и наш смежный руководство по стабильности Safari и системы для 26.2. Если Mail тоже ведёт себя нехорошо — а обычно так и бывает, когда проблемы с Safari — смотрите наше руководство по исправлениям, специфичным для Mail. Пользователям, обновляющимся с предыдущей базы, стоит прочесть руководство по обновлению 26.4 / 26.4.1 для контекста о том, что изменилось между выпусками. А если помимо исправлений Safari вам нужно постоянное защитное ПО, наше руководство по антивирусам и безопасности 2026 года рассказывает, какие инструменты используют Network Extensions, а какие — альтернативные архитектуры.

Источники, использованные при написании этой статьи: тема форума MacRumors 2481881 (исправления ошибок в RC 26.5 и обсуждение после выпуска), несколько тем на форумах Apple Developer о миграции флагов функций WebKit 26.5, официальная документация поддержки Apple о включении меню Develop в Safari и подробный анализ Говарда Оукли в Eclectic Light «What has changed in macOS Tahoe 26.5». Когда сообщения форумов расходились, мы воспроизводили поведение локально на нескольких машинах, прежде чем включать его сюда.