macOS 27 测试版 Chrome、Brave 无法加载网页？修复指南

你安装了 macOS 27「Golden Gate」公开测试版，打开 Chrome，输入网址，然后……什么都没发生。标签页转个不停，状态栏显示 正在连接…… 却始终没有进展。过了一会儿，你只等来一个干巴巴的错误——ERR_CONNECTION_TIMED_OUT、ERR_NAME_NOT_RESOLVED，或者 Brave 那句略带戏谑的 无法访问此网站。于是你换一个网站试试，还是一样。每个网站都这样。然后，出于习惯，你打开了 Safari——它秒开，一次成功，毫不迟疑。网络显然没问题，Wi-Fi 也没问题。但「macOS 27 测试版下 Chrome 无法加载网站」这件事却占据了你一整个下午，而且 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 设置为「仅本地链接」，以及清空 DNS 缓存。
• 尽早检查 Private Relay 和 VPN。 在此测试版下，iCloud Private Relay 和「半连接」状态的 VPN 隧道对 Safari 和 Chromium 应用的表现并不一致，是常见的元凶之一。
• 最实际的退路是使用 Safari，或者直接回退系统。 在测试版上，有些问题只能等 Apple 解决。如果一个能正常工作的 Chromium 浏览器对你来说是刚需，不妨权衡一下回退到稳定版 Tahoe，而不是继续跟这个构建版本死磕。

首先确认：你真的在使用 macOS 27 测试版吗？

在你改动任何设置之前，先确认自己正处于本文所指的测试版系统上——因为这里的修复方法都是针对测试版行为设计的，如果在稳定版系统上使用，可能是白费功夫（甚至略微起反效果）。

检查你的确切系统版本

打开 Apple 菜单 > 关于本机，查看版本号那一行。然后点击 更多信息 > 软件更新（或 系统设置 > 通用 > 软件更新），确认自己是否处于测试版种子上。

• 如果显示的是 macOS 27.0 beta（或带有开发者/公开测试版横幅），那你就找对地方了。公开测试版于 2026 年 7 月中旬发布——Public Beta 1 于 7 月 13 日发布，Public Beta 2 于 7 月 22 日发布——截至本文撰写时，最新的开发者测试版本是 beta 4，构建版本号 26A5388g（7 月 20 日发布）。Apple 并未为公开测试版发布固定的构建版本字符串，所以不必过分纠结某个具体编号；用「macOS 27 公开测试版」这个说法来描述会更贴切、更诚实。
• 如果显示的是 macOS 26.5.2（构建版本 25F84） 或类似版本号，那你使用的是稳定版 Tahoe，而不是测试版。这种情况下，Chromium 浏览器全面无法访问不属于已知的测试版问题模式，应当把它当作普通的网络问题来处理——请先参考我们的Wi-Fi 频繁断连完整修复指南和VPN 故障排查指南，而不是下文这些针对测试版的步骤。

致 Intel Mac 用户的提示

macOS 27「Golden Gate」仅支持 Apple 芯片——M1 或更新机型。本次更新周期彻底放弃了所有 Intel Mac。如果你用的是 Intel 机型，那你根本不可能运行 macOS 27 测试版，所以浏览器出问题一定是别的原因。本文假设你使用的是运行测试版的 M 系列 Mac。

记住这里「测试版」意味着什么

以下内容全部建立在测试用户的报告基础上，来自各社区论坛和媒体报道的汇总。这些都不是 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 解析器、自己的连接池管理，以及一套自己对如何打开 socket 的看法。这种独立性通常是优势。但在 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 处理方式上做了新的改动，那么域名查询就可能永久挂起——这正是无休止的*正在连接……*的表现。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 已经花了好几个系统版本的时间，把这些功能全部从内核里搬出来，迁移到一个名为**网络扩展（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 彻底退出，而不只是关闭窗口），这样每一处改动才能真正生效。

精确定位故障发生的层级（可选，但很有用）

如果你想在动手改设置之前，先确切了解到底是哪一层出了问题，五条安全的终端命令能告诉你答案。它们都不会修改任何东西——只是读取状态——所以可以放心运行，没有任何风险。这里的目的是把问题拆分成三个：网络本身是否可达？DNS 是否正常工作？即便 Chrome 打不开，系统级 HTTP 路径是否能正常工作？

1. 你能通过原始 IP 访问互联网吗？ 这会完全绕开 DNS。

ping -c 4 1.1.1.1

如果收到回复，说明你的 Mac 具备正常的网络连通性，问题出在更上层（DNS 或按应用处理层面）。如果这一步也失败了，那 Safari 应该也会失败，你面对的就是普通的连接问题，而不是这次测试版的浏览器问题模式。

2. DNS 解析是否正常工作？

ping -c 4 cloudflare.com

如果第一步成功了，但这一步提示无法解析或直接卡住，那你就确认了一个 DNS 问题——正是修复方法 1 和 4 所针对的目标。

3. 直接询问解析器。 dig 和 nslookup 都是 macOS 自带的命令，能显示系统解析器返回的结果：

dig cloudflare.com +short
nslookup cloudflare.com

如果这里能得到结果，说明系统解析器工作正常，问题出在 Chromium 自己的 DNS-over-HTTPS 上卡住了——这是一个强烈的信号，说明修复方法 1（关闭浏览器的 Secure DNS，让它转而依赖这个正常工作的系统解析器）会有帮助。

4. 即便 Chrome 打不开，系统级 HTTP 栈能加载页面吗？ 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 服务器。如果看到意料之外的地址，请回头查看修复方法 5 中关于配置描述文件和 VPN 的检查内容。

运行完这五条命令，你在动手改设置之前就能知道自己是在追查 DNS 问题、过滤器问题，还是按应用路径的问题。如果你对终端不感兴趣，完全可以跳过这一节——修复阶梯没有它也照样有效。

修复阶梯

从上到下依次尝试。每完成一步就重新测试一次，网站恢复正常后即可停止。这里的每一步都是可逆的。

修复方法 1：关闭浏览器中的 Secure DNS / DNS-over-HTTPS

这是针对本次测试版问题模式收益最高的单一修复方法，因为 Chromium 内置的加密 DNS 正是那种会与测试版系统失去同步的「自主管理」型网络行为。你要做的，就是让浏览器不再自己解析域名，转而交给系统处理。

在 Chrome、Brave、Edge 和 Vivaldi 中：

1. 打开 设置 > 隐私和安全 > 安全。
2. 滚动到 使用安全 DNS，将其完全关闭。（不要只是切换服务商——要彻底关闭，这样浏览器才会使用操作系统的解析器。）
3. 完全退出浏览器（Cmd+Q）后重新打开。

在 Arc 中： 打开 Arc > 设置，找到隐私/安全部分，用同样的方式禁用安全 DNS；Arc 把 Chromium 的这项设置放在了自己的菜单里。

如果在前面的排查检查中，原始 IP 能打开而域名打不开，那么仅这一步往往就能解决问题。

修复方法 2：禁用或移除网络过滤、VPN 及内容过滤扩展

如果你运行了 Little Snitch、LuLu、公司级内容过滤器、DNS 过滤应用，或带网页防护功能的杀毒套件，它几乎肯定已经把自己安装为系统网络扩展——而这正是本次测试版中「放行 Safari、拦截 Chromium」现象的头号嫌疑对象。

1. 进入 系统设置 > 通用 > 登录项与扩展，点击 网络扩展 旁边的 (i) 图标（旧版路径视构建版本而定，可能是 网络扩展 或 内容与隐私）。
2. 逐一将每个第三方网络过滤器 / VPN / 防火墙扩展关闭。
3. 每次切换后都要完全退出并重新打开 Chrome，再重新测试。

如果禁用某一个扩展后 Chrome 恢复正常，你就找到了元凶。接下来你可以选择先关闭它，等 Apple 发布修复版本；或者把该工具更新到最新版本（厂商针对测试版通常会很快出补丁）；也可以查看厂商发布的测试版兼容性说明。如果你用的是受管理的公司 Mac，可能没有权限自行禁用公司级过滤器——这种情况应该联系你的 IT 团队，这也是暂缓安装测试版的合理理由。我们的网络扩展内容过滤器修复文章对这类扩展在系统底层发生变化时会如何表现，做了更深入的分析。

修复方法 3：将当前活动网络服务的 IPv6 设置为「仅本地链接」

多名测试用户反映，在这个测试版中，当 IPv6 出现异常时，Chromium 的双栈（IPv4 + IPv6）连接竞速机制会卡死，而 Safari 却能容忍这种情况。强制让网络服务关闭完整的 IPv6，能把流量推回到正常工作的 IPv4 路径上。

通过系统设置操作（推荐，较为温和）：

1. 打开 系统设置 > 网络，选择你当前使用的服务（Wi-Fi 或 以太网），点击 详细信息……。
2. 切换到 TCP/IP 标签页。
3. 将 配置 IPv6 设置为 仅本地链接。
4. 点击 好，然后完全退出并重新打开 Chrome。

通过终端操作（效果相同，如果你更喜欢命令行）： 先列出你的网络服务名称，然后为你正在使用的那个服务关闭 IPv6。注意，-setv6off 比图形界面里的「仅本地链接」更彻底地禁用了 IPv6，但对于排查这个问题来说，两种方式都可以。

# 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 命令，作用是清空缓存并重启多播 DNS 响应器：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

系统会要求你输入管理员密码。执行成功后不会有任何可见输出——这是正常现象。之后退出并重新打开 Chrome，再尝试访问某个网站。为了获得最佳效果，建议把这一步和修复方法 1（关闭安全 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 上，可以参考我们的macOS VPN 故障排查指南——大多数 VPN 客户端都需要一次针对测试版的更新。
• 配置描述文件： 在系统设置 > 通用 > 设备管理（或隐私与安全性 > 描述文件）中，移除任何你不认识或不再需要的旧 DNS 或代理配置描述文件。遗留的配置描述文件可能会把不正确的 DNS 服务器固定下来。

修复方法 6：部分测试用户力荐的 FaceTime／「允许在其他设备上接听电话」开关

这个方法有点奇怪，也未经证实，但值得花三十秒尝试，因为一批论坛发帖用户反映，切换这个开关让他们的 Chromium 浏览器起死回生。理论上认为，切换这个「接续互通（Continuity）」功能，会促使网络栈重新初始化那些被测试版留在异常状态下的按应用网络路径。

1. 打开 FaceTime > 设置（菜单栏：FaceTime > 设置）。
2. 找到 来自 iPhone 的通话 / 允许在其他设备上接听电话，先关闭再重新打开。
3. 或者也可以在 iPhone 上操作：设置 > 电话 > 在其他设备上接听，把你的 Mac 关闭再打开。
4. 重新测试 Chrome。

把这个方法当作「碰巧对某些人有效的民间偏方」看待，而不是有保证的修复方案。它不花任何成本，也能立刻撤销，所以值得占据阶梯上的一级。

修复方法 7：重置浏览器网络设置或新建一个配置文件

如果系统级修复方法没能解决问题，就要排查一下是否是你特定的浏览器配置文件里保留着损坏的网络状态。

• Chrome/Brave/Edge： 打开 设置 > 重置设置 > 将设置恢复为原始默认值。这会清除自定义的 DNS、代理和启动项调整，但不会影响你的书签或密码。
• 全新配置文件测试： 新建一个配置文件（配置文件图标 > 添加）或打开一个访客窗口，尝试访问某个网站。如果新配置文件正常，说明问题出在原配置文件本地——你可以重置旧的，或迁移到新的配置文件。
• 清空 socket / 主机缓存： 在 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. 把它从应用程序文件夹拖到废纸篓。
3. 直接从厂商官网下载最新版本——测试版兼容性修复经常随浏览器更新一起发布，所以当前版本可能已经能更好地应对这个测试版。
4. 重新安装并测试。登录账号后，你的同步数据（书签、密码）会自动恢复。

修复方法 9（测试版现实的退路）：使用 Safari，或回退到 Tahoe

这里是最坦诚的部分。这是一个测试版，浏览器无法访问这个问题是测试用户报告的，并非 Apple 官方承认的，而且有些测试用户发现，在 Apple 发布新构建版本之前，上述阶梯中的任何方法都无法真正彻底解决问题。如果你已经把整个阶梯都试了一遍，Chromium 依然打不开，那么你还有两个理性的选择：

• 暂时依靠 Safari。 它能用、速度快，还能导入你的书签。在测试版逐渐成熟的这几周里，把日常浏览都放在 Safari 上，是一个完全合理的临时方案，你也可以在每个新测试版种子发布后继续重新测试 Chrome（不同构建版本之间的表现确实会发生变化）。
• 回退到稳定版 Tahoe。 如果一个能正常工作的 Chromium 浏览器对你来说是硬性刚需——出于工作需要、扩展程序需要，或是无法迁移的工作流程——最干净利落的解决办法就是离开测试版。请参照我们的将 macOS 27 测试版无损降级回 Tahoe 的分步指南。如果你只是正在考虑要不要安装测试版，那么这整个问题都是一个有力的理由，让你下次考虑在独立分区上安全安装测试版，这样你日常工作的系统就永远不会成为出问题的那个。

以上任何一种选择都没什么可羞愧的。测试版是你自愿参与试用的预览版本，不是让你必须忍受一个坏掉的浏览器的承诺。

常见问题排查

问题：测试版下 Chrome 能打开部分网站，但在其他网站上卡住

解决方法： 部分能加载几乎总是意味着 DNS 问题，而不是完全被拦截。有些域名能从缓存中解析出来，而新的查询却卡住了。同时执行修复方法 1（关闭安全 DNS）和修复方法 4（清空 DNS 缓存），然后完全退出 Chrome 再重试。如果问题依旧，把系统 DNS 设置成一个普通解析器——系统设置 > 网络 > 详细信息 > DNS，添加 1.1.1.1 和 8.8.8.8——这样操作系统就不再依赖那个被测试版处理不当的解析器了。

问题：本来一切正常，测试版更新后又坏了

解决方法： 这种情况在预料之中。每个新的测试版种子都可能重置网络扩展的批准状态和相关行为。任何一次 macOS 27 测试版更新之后，都请在系统设置 > 通用 > 登录项与扩展 > 网络扩展中重新批准你的网络扩展，然后重新执行修复方法 1 和修复方法 4。由于这是未经官方确认的测试版行为，请把每个构建版本都当作全新的诊断对象，而不是假设你之前的修复方法依然有效。

问题：工作或学校配发的 Mac 无法进行我需要的修复操作

解决方法： 受管理的 Mac 会强制启用公司级内容过滤器和配置描述文件，而你自己无法禁用它们，这类过滤器正是「Safari 正常、Chromium 失效」这种分裂现象的头号嫌疑对象。不要试图跟 MDM（移动设备管理）对着干。联系你的 IT 团队，告诉他们浏览器只在 macOS 27 测试版上对 Chromium 应用出问题，并询问他们的过滤器厂商是否有兼容测试版的构建版本。如果没有，这就是一个明确的信号：生产用途／受管理的 Mac 目前还不应该安装这个测试版。

问题：禁用网络扩展修复了 Chrome，但我需要那个工具持续运行

解决方法： 你已经确认了元凶——现在要用正确的方式恢复防护。把该工具（Little Snitch、LuLu，或你的杀毒软件）更新到最新版本，因为厂商通常会很快发布测试版兼容性补丁。查看厂商的发布说明或论坛，看看是否有针对 macOS 27 的说明。如果目前还没有兼容的版本，那你就是在这个测试版上要在「该工具」和「Chromium」之间二选一——这也是权衡回退到 Tahoe、等厂商跟上进度的一个正当理由。

常见问题解答

为什么在 macOS 27 测试版中 Safari 能用，但 Chrome 和 Brave 不能用？

Safari 使用 macOS 原生的网络和 DNS 处理机制，所以测试版对系统底层的任何改动，它都会一并继承。Chromium 系浏览器则自己管理 DNS、socket 和连接逻辑，这可能与测试版新的按应用网络处理方式失去同步。同一台机器、同一个 Wi-Fi，走的却是不同的网络路径——这就是为什么一个能用，另一些却卡住的原因。

这是 Apple 官方确认、即将修复的漏洞吗？

官方并未如此确认。这个问题是由测试用户在 Brave Community、Apple Discussions 和 MacRumors 上报告的，并被媒体汇总报道，但 Apple 尚未发布正式确认。因为它存在于预发布构建版本中，表现可能随每个新种子而变化，所以每次 macOS 27 测试版更新后都应重新测试。

关闭安全 DNS 会降低我浏览网页的隐私性吗？

会略微降低，但只是暂时的。禁用浏览器的 DNS-over-HTTPS 意味着域名查询会使用你的系统解析器，而不是加密解析器。作为测试版下的一个临时变通方案，这个代价是可以接受的，等 Apple 发布一个能与 Chromium 良好配合的构建版本后，你可以再重新启用安全 DNS。无论如何，你的 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 里将就几周，那么留在测试版上、并在每个新种子发布后重新测试，会是省事得多的路径。

结语

当「macOS 27 测试版下 Chrome 无法加载网站」而 Safari 却运行完美时，你面对的不是一台坏掉的 Mac，也不是一个坏掉的浏览器——你面对的是一个预发布系统，它对待 Chromium 独立网络路径的方式，与对待 WebKit 的方式不一样。正是这一个洞察，解释了为什么大多数修复方法都只是简单的开关切换：关闭浏览器的安全 DNS、禁用某个网络过滤扩展、把 IPv6 设为「仅本地链接」、清空 DNS 缓存，以及检查 Private Relay 和 VPN。对大多数测试用户来说，这些阶梯中总有一级能解决问题，而且每一级都能在几秒钟内撤销。

但请把这个坦诚的判断始终放在心里：这是测试用户报告的行为，而非 Apple 确认的漏洞，而在测试版上，最终的解决办法有时候就是耐心等待。表现会随构建版本变化而改变，所以每个新种子发布后都要重新测试——如果一个能正常工作的 Chromium 浏览器是你无法缺少的东西，那么依靠 Safari，或者回退到稳定版 Tahoe，直到 Apple 把问题解决，都没什么可羞愧的。你是自愿参与试用预览版本的；把一个坏掉的浏览器当作「等下一个构建版本」的情况来处理，正是正确的直觉。

最后一个实用习惯：留意测试版的发布节奏。Apple 大约每一到两周就会发布一个新种子——Public Beta 1 于 7 月 13 日发布，Public Beta 2 于 7 月 22 日发布，开发者测试版 beta 4（构建版本 26A5388g）于 7 月 20 日发布——而网络相关的表现在各个种子之间确实发生了变化。所以更聪明的做法是：先保持你有效的修复设置不变，记下是哪一级解决了问题，然后每次新构建版本发布后，短暂关闭该变通方案并重新测试 Chrome。如果某个种子悄悄修复了底层问题，你就应该把安全 DNS 和 IPv6 都调回正常设置，而不是让这些改动永久保留下去。测试版在不断变化；你的变通方案也不该是永久性的。

从阶梯顶端开始逐级尝试，在第一个让你的网站恢复正常的那一级停下来；如果你正在权衡到底要不要继续留在 Golden Gate 测试版上，已知问题指南和安全安装演练会帮助你看清情况，做出决定。