iCloud Private Relay 正在泄露你的真实 IP 地址

macOSTahoe ·
iCloud Private Relay 正在泄露你的真实 IP 地址

研究人员发现三条路径，能让网站在 iCloud Private Relay 开启的情况下看到你的真实 IP。本文讲清泄露原理、如何自测，以及现在该怎么做。

你打开 iCloud Private Relay 只有一个理由：让你访问的网站看不到你从哪里连上来。这就是它的全部卖点。Apple 把你的 Safari 流量经过两跳中转，让任何单一方——无论是你的网络运营商还是网站本身——都无法把你的身份和你的目的地对上号。但对于某一类特定的请求，这个承诺并不成立。

2026 年 8 月 4 日，安全研究员 Tommy Mysk 和 Talal Haj Bakry 公布了他们的发现：在 Private Relay 处于开启且正常工作的状态下，网站依然可以拿到你的真实 IP 地址。8 月 5 日媒体跟进报道，MacRumors、9to5Mac、TechCrunch 和 The Hacker News 等都做了转载。泄露路径一共有三条，彼此在机制上毫不相关，而其中最尖锐的一条牵涉到 passkey——正是 Apple 多年来一直在力推、宣称比密码更安全的那套登录技术。

本文会逐一讲清楚：Private Relay 到底承诺了什么、研究人员演示了什么、三条泄露路径各自怎么运作、如何在自己的 Mac 上做测试，以及有哪些事情是真正值得去做的。在展开之前先界定一下范围：这是网络身份的泄露，不是浏览内容的泄露，也不是账户的泄露。没有人在读你的加密流量，没有人能进你的 iCloud。泄露出去的是一个 IP 地址，而这件事对你重不重要，完全取决于你是谁、以及谁在盯着你。

核心要点

  • 三条独立路径，同一个结果。 Mysk 和 Haj Bakry 演示了在 Private Relay 开启的情况下，WebAuthn/passkey 流程、DNS 预解析和 WebTransport 三者都能各自把你的真实 IP 地址暴露给网站。它们是彼此独立的缺陷，只是恰好收敛到了同一种失效方式上。
  • passkey 泄露并不要求你拥有 passkey。 研究人员发现，网站只需要发起这个流程就够了——真正使用 passkey 的站点，以及只是假装使用 passkey 的站点，都能触发这个请求。你不需要点击任何东西，也不需要完成任何登录。
  • 这是 IP 泄露，不是入侵。 你浏览内容的加密部分没有被暴露，没有账户被攻陷，也没有分配任何 CVE。被暴露的是网络身份：你的真实地址，以及在 DNS 那条路径上，你的真实解析服务器。
  • Apple 正在调查，目前没有修复方案。 Apple 向 404 Media 表示正在研究这份报告。9to5Mac 报道称，Apple 给研究人员的状态回复表明公司计划处理这个问题，修复目标定在 2026 年秋季。MacRumors 则把这个问题描述为「已经长进 WebKit 的工作方式里」。
  • 关掉 Private Relay 是错误的反应。 面对网络上的被动观察者，它依然在做实事。如果你的威胁模型确实存在，合理的升级路径是用真正的 VPN，但要坦诚接受随之而来的代价：你只是把信任从 Apple 转移到了某家 VPN 厂商身上。

iCloud Private Relay 究竟是什么，Apple 承诺过它做什么

在评判这次泄露之前，先把「被泄露的那个承诺」说清楚会很有帮助——因为围绕这件事的很多困惑，都来自人们期待 Private Relay 是某种它从来没有被这样宣传过的东西。

iCloud Private Relay 是 iCloud+ 的功能，也就是说它随付费 iCloud 存储套餐提供，而不是随操作系统提供。Apple 的定位一贯而且相当克制：它的设计目标是让你的 IP 地址和浏览活动对网络服务商以及你访问的网站保持隐藏。这就是承诺的全部内容。它不是「我们会加密你 Mac 上的一切」，也不是「我们会让你彻底匿名」。

两跳架构

架构本身是最有意思的部分，而且确实经过了认真的设计。当 Private Relay 处于活动状态时，来自 Safari 的请求不会直接抵达目标服务器，而是依次经过两级代理。

第一跳是 ingress 代理，由 Apple 运营。Apple 知道你是谁——毕竟你登录着 iCloud 账户，而且你的设备是从某个特定网络连接上来的。Apple 拿不到的是目的地。你访问的站点地址被加密处理，ingress 代理读不到。

第二跳是 egress 代理，由第三方内容分发合作伙伴运营，而不是 Apple。真正跟目标网站对话的是这一级代理。它知道你要去哪里，但不知道你是谁，因为它从来没见过你原始的 IP 地址，也没见过你的 iCloud 身份——它收到的请求来自 Apple 的 ingress 代理。

结果是一次刻意的知识切分。敏感信息这一对里，没有任何一方同时握有两半。Apple 知道「谁」但不知道「哪里」。合作伙伴知道「哪里」但不知道「谁」。链条末端的网站看到的是 egress 代理的地址而不是你的地址，而 Apple 还额外提供了一个粗粒度的位置设置，让网站看到的地址仍然大致匹配你所在的区域——这对本地搜索结果和新闻很有用，同时又不会把你定位到具体位置。

这个设计比大多数人给它的评价要好，而且如果你本来就在为 iCloud 存储付费，它实际上不额外花你一分钱。如果你想更全面地了解它在整个平台防护体系中的位置，我们的 macOS Tahoe 安全与隐私完全指南 覆盖了周边的相关功能。

关键的定性：它不是 VPN

接下来这部分对理解此次泄露至关重要。Private Relay 不是 VPN，Apple 也从来没有把它描述成 VPN。

一个配置得当的 VPN 在网络层截获流量。机器上的每个应用、每种协议、每个套接字——全都会走进隧道，因为操作系统的路由表就是这么指的。这也是 VPN 为什么笨重、为什么容易搞坏东西、为什么有时候需要内核扩展或系统网络扩展才能工作的原因。

Private Relay 的作用范围要窄得多。它覆盖的是：

  • Safari 浏览流量。 这是它最主要的使用场景。
  • DNS 解析。 你的 DNS 查询本应经过中继，这样你的解析服务器就不会变成一份「你去过哪里」的日志。
  • 一部分未加密的应用流量。 应用发出的不安全 HTTP 请求会被纳入中继，作为一项加固措施。

边界就到这里。Chrome 的流量不走它。你的邮件客户端的流量不走它。第三方应用的加密流量也不走它。如果某个应用用自己的网络栈开了自己的连接，Private Relay 就不在这条路径上，而且它本来也没声称过自己在。

这个区分不是抠字眼——它是评估这次新发现的整个框架。研究人员找到的三条泄露路径里，有两条在某种程度上就是「请求跑到了 Private Relay 划定的边界之外」。问题不在于这个边界存在。问题在于，那些在用户体验上属于「Safari 浏览」的请求，最终跑到了边界之外，而且是隐形的，没有任何信号告诉用户有东西离开了隧道。

研究人员发现了什么

Tommy Mysk 和 Talal Haj Bakry 并不是初次涉足这个领域。他们长期以来一直在拆解 Apple 平台上的隐私宣称，而且经常发现营销描述和实际实现之间的落差比任何人预想的都大。他们的做法很稳定：做一个演示，公开它，让作品本身而不是新闻稿去说明问题。

他们关于 Private Relay 的发现日期是 2026 年 8 月 4 日。次日即 8 月 5 日，MacRumors、9to5Mac、TechCrunch 和 The Hacker News 等多家媒体做了报道。

用大白话说，核心结论是：即使 iCloud Private Relay 处于开启状态，网站也能拿到你的真实 IP 地址。不是通过某种需要你先被攻击才能用上的冷门侧信道，也不是靠利用你这边的配置失误。而是通过任何网站都能调用的普通 Web 平台功能。

三条路径分别是：

  1. WebAuthn / passkey。 passkey 登录发出的网络请求，是由操作系统的凭据服务发起的，而不是由 Safari 发起，所以它根本没进入被代理的路径。
  2. DNS 预解析。 这是 OS 26 一代加入的性能功能，会暴露用户真实的 DNS 解析服务器。
  3. WebTransport。 这是 26.4 一代加入的较新传输 API，它可以开启一条绕过代理的直连 HTTP/3 连接。

受影响的范围是 Safari 以及基于 WebKit 的浏览。在 iOS 上，由于大多数司法辖区仍然要求所有浏览器底层使用 WebKit，这意味着替代浏览器同样受影响——从 Safari 换成 iPhone 上的另一个浏览器，并不会换掉真正干活的引擎。在 Mac 上情况不同：受影响的主要是 Safari，以及那些为应用内浏览嵌入 WebKit 的应用，而 Chrome、Firefox 这类非 WebKit 浏览器使用自己的引擎和自己的网络栈。这对 Mac 用户来说是个实质性的差别，我们稍后会回到「这到底能给你换来什么、又换不来什么」这个话题。

Apple 的回应，据报道是这样的：公司向 404 Media 表示正在调查这份报告。9to5Mac 报道称，Apple 给研究人员的状态回复表明，公司计划处理他们上报的问题，修复目标定在 2026 年秋季。公开归属于 Apple 的表态就这么多。没有点名具体的版本，Apple 也没有在公开场合确认发布日期，三条路径中的任何一条都没有分配 CVE。

目前没有修复方案。 MacRumors 把这个问题描述为「已经长进 WebKit 的工作方式里」——对于这类缺陷来说，这个说法很中肯：它的修复不是给某个函数打补丁，而是重新思考「哪个子系统拥有一个网络请求」。

passkey 路径的完整解释

三条路径里，这一条最值得细看。它最出人意料，最难躲开，其含义也最让人不舒服。

WebAuthn 流程究竟是什么

passkey 建立在 WebAuthn 之上，这是一项用于公钥认证的 Web 标准。大多数人心里的模型大体是对的：你不再把密码发给服务器，而是设备持有私钥、服务器持有对应的公钥，登录意味着通过签署一个挑战来证明你控制着私钥。没有任何可复用的东西经过网络。对 passkey 的钓鱼攻击不像对密码那样奏效，因为签名跟来源域名是绑定的。

完成这一切的步骤序列被称为一次流程（ceremony）。站点的 JavaScript 调用浏览器，浏览器请求平台生成或验证一份凭据，你用 Touch ID 或设备密码在本地完成认证，然后一份签名断言返回。在 Apple 平台上，凭据本身存放在「密码」应用里，并通过 iCloud 钥匙串同步。如果你想了解 Apple 在这条线上的更多布局，我们在关于「密码」应用与自动改密的文章里做过讨论。

几乎没人会想到的一点是：这个流程并不是纯本地的。它有一部分涉及通过网络获取数据——依赖方的配置，以及那份把站点域名和被允许为其服务的凭据关联起来的关联数据。总得有什么东西发出一个 HTTPS 请求去拿这些数据。

是谁发出了这个请求

问题就出在这里。引用媒体对研究人员解释的转述：

WebKit 把 WebAuthn 流程交给操作系统的凭据服务处理，由后者自己直接从设备发出 HTTPS 请求，而它并不知道宿主应用配置了任何代理。

请仔细读这句话，因为每一个分句都在承担信息。WebKit 自己并不执行这个流程；它把任务委派给了一个掌管凭据的系统服务。这个服务随后发出属于它自己的出站 HTTPS 请求。而最关键的是，它并不知道宿主应用配置了任何代理——凭据服务并不知道也不关心 Safari 已经被设置成把流量走 Private Relay 的两跳路径。它是另一个进程，有另一套网络配置，只是在做它被设计去做的事情。

后果，同样是据报道：

由于这次获取是由操作系统的凭据服务而不是 Safari 发出的，它从来没有进入 Private Relay 的代理路径。

于是请求从你的设备直接发出，带着你的真实 IP 地址，抵达一台由该网站控制的服务器。网站看到了这个连接，记录下了这个地址。Private Relay 从头到尾都在运行，只是不在这条路径上。

从架构角度看，你能理解这件事是怎么在没人失职的情况下发生的。凭据处理本来就应该和浏览器隔离开——这种分离是一项安全属性，不是失误。把密钥材料挡在那个运行着来自任意网站的不可信 JavaScript 的进程之外，完全正确。问题在于，这条隔离线是为安全画的，而没有人把隐私边界重新画一遍去对齐它。凭据服务继承了进程隔离，却没有继承代理配置。

最尖锐的一点：你不需要拥有 passkey

下面这个细节，把一则有趣的架构笔记变成了一个真实的隐私问题。

研究人员指出，这条路径在使用 passkey 的站点、以及仅仅假装使用 passkey 的站点上都会触发。网站可以在你没完成任何登录的情况下发起这个流程。你不需要为该站点拥有 passkey。你甚至不需要有账户。你不需要点登录按钮、不需要通过 Touch ID 提示、不需要跟任何东西交互。

页面只要调用这个 API，网络请求就发生了。这个流程最终成功、失败还是被放弃，跟泄露毫无关系，因为泄露发生在获取动作那一刻，早于任何认证逻辑起作用之前。

这把这项功能的意义整个倒转了过来。WebAuthn 存在的意义是让认证更安全。而在这种配置下，仅仅是调用认证机制这一动作，就变成了一个任何页面都能在加载时静默拉动的去匿名化开关。追踪方不需要攻陷任何东西，只需要嵌入一小段代码，发起一个永远不会有人完成的流程，就能收集每一个加载该页面的 Private Relay 用户的真实 IP。

发生这一切时，没有任何用户可见的信号。没有提示、没有权限弹窗、工具栏上也没有指示。设计上的假设是：发起一次凭据流程是无害的行为——在正常情况下确实如此。

passkey 认证流程示意图

DNS 预解析路径

第二条泄露路径影响较小，但很有教育意义，因为它在一个完全不同的子系统里展现了同样的底层模式。

预解析是干什么的

加载一个网页是一串相互依赖的查找。浏览器拿到 HTML，发现它引用了一个域名上的样式表、第二个域名上的字体、第三个域名上的分析脚本、第四个域名上的图片。这些域名里的每一个，在连接能开始之前都需要先做一次 DNS 解析，而 DNS 解析是要花时间的——顺利时几十毫秒，在糟糕的移动网络上会差得多。

DNS 预解析就是针对这一点的直白优化。浏览器还在解析页面的时候，就提前扫一眼被引用的链接和资源，把这些主机名提前解析掉。等解析器真的走到需要建立连接的位置时，地址已经在缓存里了，连接可以立刻开始。这类改动会在页面加载指标上体现为实打实的提升，这也正是浏览器工程师不断添加此类功能的原因。

这个具体实现是在 OS 26 一代——也就是 Tahoe 时期跨 Apple 各平台的那批发布——中登场的。

它暴露了什么

研究人员发现，这些预解析查询会暴露用户真实的 DNS 解析服务器。

在 Private Relay 正常工作的情况下，DNS 本应属于中继覆盖的范围。这一点是刻意为之而且很重要：如果你的查询以明文发给了 ISP 的解析服务器，你的 ISP 就会拿到一份带时间戳的清单，记录你查过的每一个域名，而无论实际流量加密得多好，这份清单几乎就是一份完整的浏览历史。Private Relay 存在的很大一部分意义，正是切断这条关联。

当预解析查询逃出这条路径，它们就会发给你设备实际配置使用的那台解析服务器——通常是你当前网络通过 DHCP 派发给你的那台，这一般意味着你的 ISP、你的雇主，或者你正连着的那个 Wi-Fi 的运营者。

这里泄露的东西比裸露的 IP 地址窄一些。观察者能得知你使用哪台解析服务器，这是一个关于「你在哪个网络上」以及「通常由哪家服务商为你服务」的强信号。跟其他信号组合起来，它会成为指纹的一部分。它同时也意味着，解析服务器的运营者看到了本应对其屏蔽的查询记录。

这个问题比 passkey 路径要小，产出的信号也更粗。但它不是零。如果你曾经在 macOS 上一边跑隧道一边跟 DNS 行为搏斗过，这些内容会让你觉得眼熟——系统解析器和被代理流量之间的相互作用，一直是困惑的长期来源，我们的 macOS VPN 故障排查完全指南 讲了这类问题的一般形态。

WebTransport 路径

第三条泄露路径牵涉到三者中最新的技术，而且它是对这个结构性问题最干净的一次示范。

WebTransport 是干什么的

WebTransport 是一套现代 Web API，用于浏览器和服务器之间低延迟的双向通信。可以把它看作 WebSockets 的继任者，建立在 HTTP/3 和 QUIC 之上而不是 TCP 之上。

它之所以存在，是因为有相当一类 Web 应用需要比请求/响应更好的东西。多人游戏需要不断推送状态，而且它们对偶尔丢一次更新的容忍度远高于对延迟的容忍度。直播视频和音频应用也一样。协作编辑器、远程桌面工具、实时遥测仪表盘——它们全都想要一条低开销的持久通道，并且在可靠性不值那点延迟代价时能够发送不可靠数据报。

WebTransport 通过跑在 QUIC 上实现了这些，QUIC 是一种基于 UDP 的传输协议，内置加密，且跨流不存在队头阻塞。就它要解决的问题而言，这是相当漂亮的工程。

Apple 的实现是在 26.4 一代中登场的。

为什么直连 HTTP/3 能击穿代理

Private Relay 的代理机制是围绕常规 Web 流量构建的——也就是 Safari 正常网络路径所产生的那些请求模式。这些请求会走 ingress/egress 两跳链条。

研究人员发现，WebTransport 可以开启一条直连的 HTTP/3 连接，绕过代理。一旦这条连接从设备直接连到目标服务器建立起来，服务器看到的就是设备的真实地址，跟任何未经代理的连接没有区别。

这里的模式和 passkey 那一条完全一致，尽管涉及的代码毫无关联。平台上增加了一项新能力。这项能力会开启网络连接。而代理层构建时对「网络连接」是什么的模型，早于这项新能力。二者之间没有任何连接，于是新能力悄无声息地运行在边界之外。

这就是为什么 MacRumors 的那句定性——问题已经长进 WebKit 的工作方式里——不只是修辞。引擎的演进会不断添加能够访问网络的子系统。除非代理边界被强制在一个所有子系统都必须经过的层次上，否则每一个新子系统都是同一个缺陷的候选者。修好三个具体的泄露，本身并不能防住第四个。

如何测试你自己的 Mac

研究人员做了一个公开的测试工具，从读者的角度看，这是这次披露中最有用的东西。你不需要听信任何人的说法。

工具地址是 https://leaks.psylo.app/。

执行测试

  1. 先确认 Private Relay 是开着的。 如果中继根本没在跑，测泄露就没有意义。打开「系统设置」，点击侧边栏顶部的 Apple 账户，选择 iCloud，然后选 Private Relay，确认它已启用。如果你不确定，可以先跳到后面关于检查 Private Relay 状态的那一节——它自己关掉的频率比大多数人以为的要高。
  2. 记下你的中继 IP 应该长什么样。 在开启中继的 Safari 里打开任意一个「我的 IP 是多少」的服务，它显示的地址会属于 Apple 的 egress 合作伙伴，而不是你自己的。这就是你的基线：网站本应看到的那个地址。
  3. 在 Safari 里访问测试页面。 一定要用 Safari，因为在 macOS 上这些路径是 WebKit 特有的。工具会跑它的检查，并报告它能观察到的关于你连接的信息。
  4. 对比结果。 干净的结果意味着工具通过每条被测路径观察到的地址都跟你的中继地址一致——代理守住了。泄露的结果意味着至少有一条路径浮出了一个不属于中继的地址，而那个地址就是你的。
  5. 在你在意的每个网络上都测一遍。 家里的网络、公司的网络和公共 Wi-Fi 上，结果可能不同，部分原因是 Private Relay 自身的可用性在这些网络之间就有差别。

一个诚实的提醒

测试工具只能告诉你它所实现的那些路径的情况，它无法告诉你所有可能存在的路径的情况。

这一点比通常的免责声明更重要，原因就在上面那个结构性判断。如果底层问题是「新的 WebKit 子系统可以在代理边界之外开启网络连接」，那么路径的集合就不是固定的——它只是「到目前为止被发现的那些」。一个检查三项内容的工具给出干净结果，只意味着这三项在那次测试中、在那个网络上、在那个时刻没有泄露。这明显好过什么都不知道，但它不是一张匿名性证书。

对待这个测试，应该像对待任何一个阴性的安全结果一样：它是针对一组特定问题缺乏证据，而不是「普遍不存在问题」的证据。

现在你实际能做的事

没有补丁可装。下面的内容大致按照「实际帮助有多大」排序，并且每一条都说明了它要你付出什么代价，因为一条不说明代价的缓解措施，是推销而不是建议。

1. 如果你的威胁模型确实需要，就用真正的 VPN

这是报道中提到的缓解措施，也是这份清单上唯一一个在正确的层次上解决问题的选项。配置得当的 VPN 在网络层截获流量，而这一层位于这三条路径运作位置的下方。凭据服务的 HTTPS 请求、预解析的 DNS 查询、WebTransport 的 QUIC 连接，全都要经过操作系统的网络栈，而系统级 VPN 就坐在这一切的底下。

代价是真实的，而且在行动之前你应该把它说出来：你只是把信任从 Apple 转移到了某家 VPN 厂商身上。 Private Relay 的两跳设计是专门构造成「没有任何单一方同时看到你的身份和你的目的地」的。传统的单跳 VPN 不具备这个性质。你的 VPN 服务商两边都看得到。你押的是他们的日志政策、他们所处的司法辖区、他们的运营安全和他们的诚信，而且和 Apple 的架构不同，这个赌注不是由设计强制保证的——它是由隐私政策里的一句承诺来保证的。

这不构成反对 VPN 的理由，而是构成「要慎重挑一个」的理由：经过独立审计、司法辖区透明、商业模式不依赖你的数据。如果你走这条路，做好花些时间处理配置怪癖的准备；我们的 macOS VPN 故障排查完全指南 讲了 macOS 上特别容易把人绊倒的那些失效模式。

2. 不要关掉 Private Relay

这是最常见的直觉反应，而且它是反的。

Private Relay 面对被动观察者依然在做实事。对于那些确实走了中继的流量，你的 ISP 仍然无法从你的 DNS 查询里拼出一份浏览日志。咖啡馆 Wi-Fi 的运营者仍然看不到你访问了哪些站点。你绝大部分的 Safari 流量仍然被代理，仍然对你访问的网站隐藏着你的地址。这些泄露只是逃逸出去的特定路径，而且它们需要网站主动去尝试——页面必须去调用一次 passkey 流程、或者使用 WebTransport、或者触发预解析行为。

关掉中继一条泄露也堵不上，只会把中继本来成功挡住的所有暴露重新放回来。你最终得到的隐私严格少于原来，换来的却是零。

3. 对你允许哪些站点发起流程保持自觉

这条建议比它听起来要弱，而且值得诚实说明原因。

passkey 路径无需交互就会触发。你无法拒绝一个从没询问过你的流程。所以既没有开关可切，也没有提示可拒。

你保留的是对究竟加载哪些页面的控制权。如果你正在做的事情里 IP 暴露确实重要，那就要意识到：你打开的任何页面——包括你从某个链接落地过去的页面，包括嵌入式的应用内浏览视图——都是一个可以调用这条路径的页面。这支持的是分区隔离的做法：在一个刻意选定的环境里做敏感浏览，而不是和其他一切混在同一个会话里。它不支持「列一份要避开的网站清单」，因为真正会利用这一点的站点，不会主动亮明身份。

4. 搞清楚锁定模式在这件事上能做什么、不能做什么

锁定模式是 Apple 为面临定向攻击风险的用户提供的极端保护设置。它会禁用一长串 Web 技术，包括即时编译的 JavaScript 和各种复杂功能，其逻辑是：你没有的攻击面无法被利用。

如果你属于锁定模式所针对的那部分人群，它值得考虑，因为它的整套思路就是移除功能而不是给具体缺陷打补丁，而被移除的功能没法泄露。但要小心这个推理：锁定模式是一种加固姿态，不是针对这三条路径的定点修复，而且所有报道都没有把它描述成本次问题的解药。如果你本来就是它的候选用户，就把它当作一个值得评估的合理选项；但不要把它当作这个具体问题的答案。它同时也会破坏大量普通网页浏览，这是刻意的设计，也正是 Apple 不建议一般用户开启它的原因。

5. 知道换浏览器能做什么——以及在哪里它什么也做不了

这里平台很关键。

在 iOS 上，换浏览器没有帮助。大多数司法辖区仍然要求所有浏览器使用 WebKit 作为引擎，所以你装的替代浏览器，只是同一个引擎之上的另一套界面，路径完全相同。iPhone 上的 Chrome 用的不是 Chrome 的引擎。

在 Mac 上，情况确实不同。非 WebKit 浏览器使用自己的引擎和自己的网络栈，因此在这些源自 WebKit 的具体路径上表现不同。但要仔细看清这换来了什么、又换不来什么：Private Relay 本来就不代理非 Safari 浏览器的流量。在 macOS 上换到 Chrome 或 Firefox，并不能把你放到中继后面——而是把你完全带到了中继之外。你没有修好泄露，你只是退出了这项保护。只有当你同时搭配一个覆盖全部流量的 VPN 时，这才算是改善。如果你大部分时间都在用 Safari 并想把它用得更透，我们的 Safari 高手指南 比一次出于错误理由的浏览器迁移更值得你的注意力。

不要对这些措施给自己开空头支票。第 2 到第 5 项能减少暴露，或者至少避免把事情弄得更糟。只有第 1 项是在这些路径实际运作的层次上解决问题，而它的做法是用一种信任关系替换另一种。

网络隐私分层示意图

谁才真的需要在意

隐私类新闻奖励歇斯底里、惩罚分寸感，所以我们来精确说清楚这件事影响谁、影响多深。

对大多数人来说，这是侵蚀，不是紧急事件

如果你是威胁模型普通的普通用户，诚实的判断是：一项你付费购买的功能在特定情况下做得没有宣传的那么多，这很讨厌，也值得 Apple 修好，但对你的实际后果接近于零。

想想真正泄露出去的是什么。你的 IP 地址，泄露给一个刻意去找它的网站。大多数网站早就掌握着关于你的、好得多的标识符——你已登录、你有 cookie、你有一份比「随你在网络之间移动而变化的 IP 地址」区分度高得多的浏览器指纹。对广告生态来说，IP 地址是一个补充信号，不是皇冠上的明珠。真正在利用这一点的公司——如果有的话——本来就在通过 Private Relay 从来挡不住的手段全面追踪你。

你失去的是一层你有理由相信它存在的纵深防御。这是一个正当的抱怨，但它不构成改变你生活方式的理由。

谁应该采取行动

应该认真对待这件事的，是那些威胁模型里确实包含「基于 IP 去匿名化」的人。具体来说：

  • 记者，尤其是与消息源合作时，记者与某个地点或某个网络之间的关联本身就是敏感信息。
  • 活动人士与组织者，在网络地址会映射到一个带有风险的真实身份的环境中。
  • 正在躲避某个特定个人的人——跟踪骚扰者、有暴力行为的前伴侣，或者任何既有技术手段又有动机去运营一个站点或一条链接、并读取谁连了上来的人。这是 IP 地址真正危险的场景，因为它能近似出一个位置，并且能确认某个特定的人访问了某条特定链接。
  • 不希望雇主或所在机构知道自己在查什么的人，尤其是在该机构控制的网络上。

如果你属于以上任何一类，正确的姿态从来就不是只靠 Private Relay。而是一个精心挑选的 VPN 或 Tor、恰当的分区隔离，以及「任何便利性功能都可能失效」这个默认假设。这次披露是对这条原则的提醒，而不是对它的修改。我们的 Mac 安全与隐私指南 2026 更深入地讲了如何搭建分层配置；如果你在考虑更广泛地降低自己的暴露面，在本地而不是云端运行 AI 工具 是同一套推理应用在技术栈另一个部分上的结果。

中间地带

在「跟你无关」和「你的人身安全取决于它」之间，是其余所有人，而那里合理的姿态是校准认知而不是采取行动。要明白 Private Relay 的覆盖范围比大多数人心里的模型更窄。别再把它当 VPN，因为它不是，而现在你手上有了一次关于这个差别的具体演示。继续开着它，因为面对它当初设计要防的那些观察者，它仍然有效。而如果你发现自己在做一件「被认出来会真的有影响」的事，那就去拿一件为这项工作打造的工具，而不是依赖那个恰好已经开着的功能。

如何确认 Private Relay 到底有没有开

有很大概率，此刻在你使用的至少一个网络上 Private Relay 是关着的，而你毫不知情。它会在好几种情况下悄悄自我禁用，所以在担心泄露之前，先确认中继确实在运行是值得的。

主设置

在 Mac 上：

  1. 打开系统设置。
  2. 点击侧边栏顶部的你的 Apple 账户。
  3. 选择 iCloud。
  4. 在列表中找到 Private Relay 并打开它。
  5. 确认开关是打开的。顺便检查一下 IP 地址位置 设置——「保持通用位置」能让区域相关内容正常工作，而「使用国家或地区和时区」则会把你的表观位置放得更宽。

如果你根本看不到 Private Relay，通常的解释是你没有订阅付费的 iCloud+ 套餐。它是 iCloud+ 功能，在免费存储层级上不会出现。

几乎没人知道的「按网络」开关

这一条经常把人坑到。Private Relay 对每一个 Wi-Fi 网络都有独立的开关状态，与全局设置无关。

检查方法：打开系统设置，进入 Wi-Fi，点击当前所连网络旁边的详细信息，在那里找 Private Relay 选项。它可能对那个特定网络是关闭的，而全局设置是开着的。

这个行为其实很有用——你可以用它保持中继总体开启，同时对那个不关就会出问题的公司网络单独关掉——但这也意味着「我打开了 Private Relay」和「Private Relay 此刻正在运行」是两个不同的陈述。任何测试结果出乎意料的网络，都要去检查一下按网络的设置。

它悄悄自我关闭的几种方式

除了这两个开关之外，还有几种情况会在没有醒目警告的情况下禁用中继：

  • 不受支持的网络。 有些网络会屏蔽 Private Relay 依赖的协议或端点。发生这种情况时，macOS 通常会让你在「不使用中继连接这个网络」和「不连接」之间做选择，而你当时选的那一项会被保留下来。
  • 企业和受管网络。 企业经常刻意禁用 Private Relay，因为一个隐藏目的地地址的代理，与网络层的内容过滤和监控从根本上不兼容。受管设备可能通过配置描述文件被禁用，且完全没有面向用户的开关。
  • 国家和地区限制。 Private Relay 并非在所有地方都可用。Apple 已确认它在若干司法辖区不可用，而在那些地区，无论你怎么设置，这项功能都不会运行。
  • 移动运营商的配置。 有些运营商下发过在其网络上禁用它的配置。
  • 冲突的 VPN 或 DNS 配置。 运行系统 VPN 通常意味着 Private Relay 主动让位，因为 VPN 会先接管流量。自定义 DNS 设置和某些 DNS 过滤描述文件同样可能禁用它。

共同的线索是：Private Relay 采取的是「失效即放行」而不是「失效即报警」。它停止工作，而你继续浏览。对一项便利性功能来说，这是一个站得住脚的设计选择——另一种做法是把人家的网断掉——但这也意味着定期验证是了解自己实际状态的唯一途径。

一个真正的修复应该长什么样

值得想一想 Apple 究竟得造点什么，因为这能解释为什么报道中的时间线是以月而不是以一个小版本更新来计算的。

浅层的修复是逐条路径打补丁。让凭据服务感知宿主应用的代理配置，并据此路由它的流程请求。把预解析的 DNS 查询拉回中继的 DNS 路径里。让 WebTransport 的 QUIC 连接走代理链，或者在中继激活时拒绝直接建立连接。三处定点改动，堵上三个洞。

这能修好已上报的问题，但修不好底层的状况。三条路径的共同模式是一样的：一个能够访问网络的子系统在构建时没有继承代理边界。只要这个边界是每个子系统需要主动选择加入的东西，而不是强制在它们之下的东西，这件事就会不断重演。

更深层的修复是架构性的——把中继强制在一个所有与 WebKit 相邻的网络路径都必须穿过的层次上，让新能力无法因为「不知道有这回事」而绕过它。这是一次大改动，有实实在在的破坏风险，属于会落在大版本发布而不是安全更新里的那类工作。它还需要为「确实无法走中继的请求」定一条明确的策略：是失效即阻断从而弄坏功能，还是失效即放行从而泄露。两个答案都不舒服，而选哪一个既是工程决策，也是产品决策。

第三个组成部分，而且可以说是最有价值的一个，是用户可见层面的：当一个请求逃出中继时，给出某种信号。目前这项功能对自己的覆盖范围完全沉默。你无法判断你正在看的这个页面是被完整代理了、部分代理了，还是完全没有。正是这种不透明，把三个实现层面的缺口变成了一个关于「承诺被打破」的故事，因为用户根本没有办法观察到「在工作」和「没在工作」之间的差别。

2026 年秋季版本里值得关注什么

根据 9to5Mac 对 Apple 给研究人员的状态回复的报道，修复目标定在 2026 年秋季。这就是被报道出来的全部内容——Apple 并未在公开场合承诺具体的版本或日期，你不应该把它当作保证。

如果真的有东西发布了，值得检查的是：

  • 三条路径是全部处理了，还是只处理了 passkey 那条。 passkey 路径拿到了头条，另外两条更安静，很有可能被推迟。
  • 修复是定点的还是结构性的。 发行说明很少直说这一点，但研究人员大概率会重测并公布结果，而他们的测试工具也给了其他所有人独立验证的途径。
  • 有没有出现用户可见的东西。 任何按页面粒度指示中继覆盖情况的功能，相比目前的沉默都会是有意义的改进。
  • Private Relay 的适用范围有没有被重新表述。 如果 Apple 收紧了对这项功能覆盖范围的措辞，那也是有信息量的——这会暗示解决方案在一定程度上关乎预期管理，而不完全关乎代码。

在那之前，情况没有变化：泄露是真的，中继面对被动观察者仍然在做有用的事，而这两者之间的落差，就是你需要自己做判断的地方。

常见问题排查

Private Relay 变灰或者根本找不到

问题： 你打开系统设置、Apple 账户、iCloud，结果要么列表里没有 Private Relay，要么开关点了没反应。

解决方案： 按顺序排查这些原因。第一，确认你订阅的是付费 iCloud+ 套餐——Private Relay 在免费层级上根本不存在，这是它缺席最常见的解释。第二，检查你所在的地区：这项功能在若干国家和地区不可用，在没有提供的地方就不会出现。第三，如果这台 Mac 由雇主或学校管理，去系统设置的「通用」下找「设备管理」，看有没有配置描述文件——机构经常禁用 Private Relay，因为它会让网络过滤失效，而描述文件层面的限制在本地无法覆盖。第四，确认你登录 iCloud 用的是持有 iCloud+ 订阅的那个账户，而不是某个次要账户。如果这四点都没问题而开关仍然无响应，退出 iCloud 再重新登录，然后重启。

Private Relay 在某个特定网络上老是自己关掉

问题： 中继在家里好用，但在办公室、某家咖啡馆或某个酒店 Wi-Fi 上始终是关的。

解决方案： 先检查按网络的开关，因为这几乎总是原因所在。打开系统设置，进入 Wi-Fi，点击那个网络旁边的「详细信息」，在那里找 Private Relay 设置。它独立于全局开关，而且如果你曾经在「此网络屏蔽 Private Relay」的提示里选择了「不使用它继续」，这个选择会被为该网络记住。把它重新打开，看看连接是否仍然正常。如果这个网络确实屏蔽了中继，你会再次收到提示，而到那一步你就知道屏蔽发生在上游，而不是一个过期的设置。企业网络尤其倾向于在防火墙上刻意屏蔽它，而且客户端没有绕过办法——如果你在这类网络上需要地址隐私，VPN 是唯一的路径，前提是该网络允许 VPN。

测试工具显示存在泄露，你想知道接下来做什么

问题： 你访问了研究人员的工具，它报告你的真实地址通过一条或多条路径可见，而你想知道下一步。

解决方案： 第一，不要把这理解成一次入侵。泄露结果意味着某个站点可以获知你的 IP 地址；它不意味着任何东西被窃取、被访问或被攻陷，没有账户需要加固，也没有密码需要更改。第二，确认这个结果说的是这些路径，而不是中继压根没开——去检查全局和按网络的 Private Relay 设置，然后重测，因为一个被禁用的中继会通过每条路径都显示你的真实地址，那是一个完全不同的、而且很容易解决的问题。第三，如果确认中继开着而泄露依然存在，那你就复现了已上报的行为，而目前没有用户侧的修复可用。根据你的威胁模型做决定：对大多数人来说，正确的反应是记下这件事然后继续；对那些确实需要地址隐私的人来说，VPN 是可用的缓解措施，代价就是前面讲过的信任转移。在 2026 年秋季的任何更新之后，都要重测一次。

因为使用 Private Relay 而被网站拦截或页面异常

问题： 某个银行网站拒绝加载、某个流媒体服务说你在错误的国家或地区、某个商店的结账流程失败，或者某个站点反复用验证码拦你。

解决方案： 这是因为网站看到的是 egress 代理的地址而不是你的地址，而它要么不把这个地址识别为住宅地址，要么这个地址的地理定位落在了意料之外的地方，要么它属于某个已被标记的共享地址段。先从位置设置入手：在 Private Relay 面板里，如果 IP 地址位置被设成了更宽的国家或地区级选项，把它切换为「保持通用位置」，这能解决大部分地理错配。如果还不够，用按网络的开关只在那个网络上禁用中继，而不是全局禁用；或者对那个特定站点换用另一个浏览器——但要记得，macOS 上非 Safari 的浏览器本来就在中继之外。为了修好一个顽固的站点而全局关掉中继，是一种你事后一定会忘记撤销的矫枉过正。

VPN 与 Private Relay 相互冲突

问题： 你连上 VPN，Private Relay 就报告自己处于非活动状态；或者两者同时开启导致 DNS 出错、连接失败或者浏览慢到不可用。

解决方案： 首先要明白这在很大程度上是预期行为。系统 VPN 在网络层截获流量，位置在 Private Relay 能看到它之前，所以 VPN 激活时 macOS 通常会让中继退居其后——这不是缺陷，也不会让你失去保护，因为 VPN 现在覆盖的流量严格多于中继原来覆盖的。实际的建议是：挑一个，让它独占这条路径。如果你是出于本文讨论的原因在跑 VPN，那么中继退让就是正确的结果。如果你看到的是真实的功能损坏而不只是中继报告非活动，那么常见的元凶是冲突的 DNS 配置、只部分截获流量的 VPN 客户端，或者之前安装的 VPN 残留的网络扩展。在进一步排查之前，先到系统设置里移除旧的 VPN 配置描述文件，因为陈旧的描述文件在这类问题中占了不成比例的份额。

常见问题

这是否意味着我的浏览历史被暴露了？

不是。泄露的是你的 IP 地址——网络身份，而不是内容。你浏览内容的加密部分依然加密，除了「你连接到了一个本来就在试图识别你的站点」这一事实之外，这些路径不会暴露你读了哪些页面。不涉及任何账户凭据，也没有任何账户被攻陷。

我应该因此停止使用 passkey 吗？

不应该。passkey 依然明显比密码更安全——它们抗钓鱼，而且没有任何可复用的东西经过网络。这次泄露不是 passkey 认证本身的弱点，而是支撑该流程的那个网络请求绕过了 Private Relay。放弃 passkey 等于用一份实实在在的安全收益，去换一点边际上的隐私收益。

这件事分配 CVE 了吗？

三条路径中没有任何一条被报告分配了 CVE。这些发现由 Mysk 和 Haj Bakry 于 2026 年 8 月 4 日公布，媒体在次日跟进报道。Apple 向 404 Media 表示正在调查。对任何为此问题引用具体 CVE 编号的信息源都要保持警惕，因为并不存在已公布的编号。

在 Mac 上用 Chrome 或 Firefox 能解决吗？

不是人们以为的那种解决。那些浏览器使用自己的引擎，不受这些 WebKit 特有路径的影响，但 Private Relay 本来就从不代理它们的流量。切换过去并不能把你放到中继后面——而是把你完全移出中继。只有当你同时搭配一个覆盖全部流量的 VPN 时，这才有帮助。

这件事在我的 iPhone 上和在 Mac 上有区别吗？

有。在 iOS 上，大多数司法辖区要求所有浏览器使用 WebKit，所以设备上的每个浏览器都共享同样的暴露面，换应用什么也改变不了。在 Mac 上，只有 Safari 以及嵌入 WebKit 的应用受影响，因为其他浏览器自带引擎。而这些路径本身在两个平台上的行为是一样的。

Apple 什么时候会修好？

9to5Mac 报道称，Apple 给研究人员的状态回复表明公司计划处理这个问题，修复目标定在 2026 年秋季。除了向 404 Media 确认正在调查之外，Apple 并未在公开场合承诺具体的版本或日期。目前没有可用的修复，而 MacRumors 把这个问题描述为已经长进 WebKit 的工作方式里。

结语

Mysk 和 Haj Bakry 的发现是真实的、有充分文档支持的，而且值得 Apple 妥善修复而不是狭隘地打个补丁。三个彼此独立的 WebKit 子系统——处理 passkey 流程的凭据服务、DNS 预解析和 WebTransport——都能各自把你的真实 IP 地址摆到一个刻意去找它的网站面前，而 Private Relay 就在那里报告着自己已启用。三者中 passkey 路径最尖锐，因为站点只需要发起流程而不需要完成它，并且完全不需要你做任何事。

它不是什么：不是入侵、不是账户失陷，也不是恐慌的理由。Private Relay 从来不是 VPN，也从没声称过是，而且面对它当初设计要拦住的那些观察者——你的 ISP、你正连着的网络、那些能看到流量但无法让站点主动探测你的被动观察者——它依然在做它被造出来要做的事。这层保护是完好的，关掉这项功能只会白白交出它，什么也换不回来。

它是什么：一次清晰的演示，说明这项功能的覆盖范围比大多数人心里的模型更窄，也说明这个边界并没有被强制在任何「新平台能力必须遵守」的地方。如果你的威胁模型里确实包含「有人得知你的 IP 地址」，答案从来都是一件为这项工作打造的工具，并且理解和接受它带来的信任转移。如果不包含，那就记下这件事，保持中继开启，好奇的话跑一下测试，然后看看秋天会发布什么。

延伸阅读：Mac 安全与隐私指南 2026