iCloud 私密转送也可能泄露 IP：WebKit 有三条流量绕过代理

安全研究者 Mysk 与隐私浏览器 Psylo 团队披露，WebKit 的 DNS 预取、WebAuthn 关联源请求和 WebTransport 可能绕过应用为网页配置的代理，直接从设备网络发出请求。研究者称，这些路径也可能让使用 iCloud 私密转送的用户暴露真实 IP 地址。

一句话结论：浏览器页面“走代理”不等于页面触发的所有系统组件都走同一条代理；当网络请求被交给 DNS 服务、凭据服务或 QUIC 传输栈时，应用级代理边界会出现缺口。

第一条路径是 DNS 预取。网页可以提示浏览器提前解析将要访问的域名，以缩短后续连接时间。研究者发现，自 iOS 26.0 起，这些查询可能使用设备的常规 DNS 路径，而不是 WebKit 数据存储配置的代理。攻击者只需控制一个查询域名，就能在权威 DNS 日志中看到请求来源。

第二条路径来自 WebAuthn 的 Related Origin Requests。为判断多个相关域名能否共享凭据，操作系统凭据服务会获取站点的 .well-known/webauthn 文件。Mysk 称这项自 iOS 18.0 出现的请求由系统服务直接发出，因此不受浏览器应用代理约束。

第三条是 Safari 26.4 加入的 WebTransport。它通常通过 HTTP/3 和 QUIC 建立低延迟双向连接，但研究者观察到这条连接会直接使用真实网络接口。与前两种只需要一次轻量请求不同，WebTransport 还可以持续传输数据，使泄露更容易被远端确认。

影响集中在应用级代理。iOS 上第三方浏览器同样受 WebKit 约束，使用 WKWebsiteDataStore.proxyConfigurations 的 Tor 浏览器或隔离浏览器因此可能受影响。系统级 VPN 会在更低层接管设备流量，研究者表示不受这三条绕过路径影响。

Psylo 1.3.1 已阻止 DNS 预取，并默认关闭 WebTransport 与 WebAuthn，允许用户按隔离空间重新启用。Onion Browser 的 Silver Lockdown 则关闭 WebTransport。苹果尚未公开确认研究者的全部结论或给出统一修复时间，因此用户不应把临时应用缓解等同于系统问题已经解决。

关键事实

• 被披露的三条路径是 DNS 预取、WebAuthn 关联源请求和 WebTransport
• 问题影响应用级 WebKit 代理；系统级 VPN 位于更低网络层，研究者称不受影响
• iOS 要求所有浏览器使用 WebKit，因此影响不局限于 Safari 的界面
• iCloud 私密转送的影响目前来自研究者测试，苹果尚未发布完整技术回应

OC 判断

这是一个边界定义问题，不只是三个独立漏洞。只要浏览器功能可以把请求委托给代理配置之外的系统服务，未来新增协议还可能重复出现同类泄露。WebKit 需要提供可继承的网络隔离语义，而不是让每个隐私浏览器逐项禁用现代 Web 功能。

为什么重要

• 对开发者：使用 WebKit 应用代理时，必须单独测试 DNS、凭据和新传输协议。
• 对企业：有强制出口审计需求的设备应使用系统级隧道，不能只依赖浏览器代理。
• 对用户：私密转送能减少常规网页追踪，但不应被理解为覆盖设备所有网络请求的 VPN。

参考来源

• Mysk：WebKit Proxy and iCloud Private Relay IP Leak
• Apple：About iCloud Private Relay
• Apple Platform Security：iCloud Private Relay
• WebKit：Safari 26.4 的 WebTransport