2026年8月4日，Mysk的研究人员发布了对WebKit中三种机制的分析，这些机制使流量绕过设置的代理，直接从设备发送。所有使用代理模式的iOS浏览器，包括Tor浏览器，以及苹果自家的服务——iCloud Private Relay，都受到了影响。代理已开启，界面显示的是其他国家，而网站却能看到您的真实IP和家庭DNS解析器。
这并不是一种针对偏执者的奇异漏洞。这是一个清晰的架构规则的示范，所有通过代理工作的人都应该掌握：应用层的代理仅保护通过该应用的网络栈传输的流量。操作系统或单独系统服务产生的所有内容都将被绕过。
究竟是什么在泄漏
研究始于一个日常场景：使用代理浏览器Psylo的用户向开发者投诉DNS泄漏。对投诉的分析揭示了三条独立的泄漏渠道——它们都存在于WebKit本身，而不是特定的应用程序中。
1. DNS预取——最简单也是最麻烦的
机制：<link rel="dns-prefetch">标签请求浏览器提前解析主机名，以加快未来的加载速度。问题在于，iOS上的WebKit通过设备的常规DNS路径解析这些名称，而不是通过代理。
桌面版Safari自Safari 5以来就支持dns-prefetch，但iOS对此标签一直无视——直到iOS 26.0（2025年9月）。当时，WebKit在同一更改中启用了它，同时移除了旧的隐式推测DNS预取（错误285744）。
如何被利用：页面在这些标签中嵌入每个访客独特的主机名，然后简单地观察请求如何到达其自己的权威DNS服务器——来自访客真实网络地址的请求。没有JavaScript，没有用户交互。只需打开页面即可。
2. WebAuthn相关的来源请求——通过passkey的泄漏
这个渠道在iOS 18.0中出现。当网站请求WebAuthn凭据（即passkey）时，系统会检查https://<rpId>/.well-known/webauthn文件——以确保域名确实与指定的依赖方相关联。
关键细节：这个验证请求并不是从浏览器的网络栈发出的。它由操作系统的凭据服务执行，该服务直接从设备发送HTTPS请求。浏览器内部设置的代理对此毫不知情（错误268426）。
也就是说，只要页面发起passkey请求，攻击者的服务器就能获得与您真实IP的连接。
3. WebTransport——直接从设备的QUIC
最新的渠道。调用new WebTransport(url)直接从设备打开QUIC连接，绕过代理配置。WebTransport在WebKit中长期处于关闭状态，并于2026年3月在iOS 26.4中公开发布（错误260810和303453）。
这对谁有影响
苹果要求所有iPhone上的浏览器使用WebKit。因此，每个依赖WebKit代理API的iOS浏览器都受到影响——包括所有iOS版本的Tor浏览器和引发调查的Psylo。此外，还有Safari和iCloud Private Relay。
未受影响的是——VPN应用程序。它们在系统级别工作，完全封装设备的所有流量，包括系统服务产生的流量。这就是区别的本质：系统隧道没有“旁路”。一个例外是安全级别为银的Onion Browser，在启用锁定模式时：它对WebTransport的泄漏不敏感。
开发者方面已经有反应。在Psylo 1.3.1中，所有三条渠道都被封堵：应用程序阻止dns-prefetch提示（页面不再能迫使设备解析攻击者控制的名称），而WebTransport和WebAuthn默认关闭——可以通过单独的开关逐个启用。根据发布时的数据，苹果预计将在未来的更新中解决这些问题；公司没有给出具体的时间表。
为什么现在才被发现
这里的时间线很有代表性，值得单独分析——它解释了为什么之前没有人注意到这个问题。
- 2024年9月，iOS 18.0——WebAuthn相关的来源请求机制出现。泄漏渠道存在近两年，这段时间没有人讨论：对passkey的域名检查看起来像是安全元素，而不是泄露地址的方式。
- 2025年9月，iOS 26.0——WebKit在移动设备上启用dns-prefetch支持。形式上这是加载速度的优化；实际上，页面获得了让设备请求任意DNS名称的能力，绕过代理。
- 2026年3月，iOS 26.4——WebTransport公开启用。第三个渠道。
- 2026年8月——一名用户对DNS泄漏的投诉引发了分析，揭示了所有三条渠道。
共同点：这些功能都不是作为去匿名化的渠道设计的。所有三者都是平台的常规功能：加速解析、检查passkey、现代传输。只有在与应用层代理模式结合时，它们才成为泄漏，因此多年没有人以这种身份进行检查。
实践中的结论简单而令人不快：没有关于泄漏的新闻并不意味着它们不存在。必须定期自行检查，而不是等待别人发布分析。
如何检查自己
研究人员发布了一个公共测试平台——leaks.psylo.app。它检查三件事：普通HTTPS流量（服务器看到的IP和DNS解析器），WebTransport以及WebAuthn + dns-prefetch的组合。打开时启用代理，并将结果与您期望看到的地址进行比较。
还应单独检查基本的卫生——您的工作组合中的IP、DNS和WebRTC地址是否一致。如果您之前没有系统性地进行此操作，请从我们的分析开始：如何检查代理的DNS泄漏。
实践结论：层次很重要
WebKit的故事是一个普遍规则的特例，这个规则在通过代理工作时在任何平台上都应牢记。
- 浏览器中的代理 ≠ 设备上的代理。应用程序内部的设置仅覆盖应用程序自己发送的流量。系统服务、后台进程、更新、推送连接，以及显然的内置passkey服务——所有这些都走自己的路。
- 泄漏不仅发生在“已知”的地方。WebRTC早已引起关注，人们已经学会了堵住它。而DNS预取和WebAuthn检查是性能和安全功能，没人将其视为去匿名化的渠道。浏览器的新功能定期创造新的旁路。
- 平台更新可能会默默破坏您的保护。这里的情况在日期上非常明显：DNS预取在iOS 26.0中“启用”，WebTransport在iOS 26.4中启用。用户没有做任何更改，而泄漏的表面却自行扩大。
这对多账户和自动化意味着什么
对于那些管理多个账户或收集数据的人来说，这里的风险并不是抽象的隐私问题，而是相当实际的财务问题。平台的反欺诈系统会比较信号：如果会话声明一个IP，而相关请求来自另一个地址和家庭解析器，这就是将账户关联起来或将会话标记为可疑的充分理由。
实际后果：
- 不要在移动浏览器中使用代理模式进行工作多账户会话。在平台未修复漏洞之前，iOS上的应用层是不可靠的。
- 系统性地封装流量。如果任务是移动环境，最好在设备级别上设置代理或通过单独的网关进行路由，而不是依赖浏览器内部的设置。
- 在每次重大操作系统和浏览器更新后检查组合。每季度至少一次。将其纳入检查清单，而不是“当某些事情出错时”。
- 关闭不使用的功能。在解析或SMM的工作配置中，WebTransport和WebAuthn几乎肯定不需要——关闭它们可以消除三条泄漏渠道中的两条。
IP的质量仍然是一个单独的变量：即使在密封的配置中，数据中心地址也会通过ASN暴露自己。在需要看起来像普通用户的场景中，使用住宅代理，而对于移动应用和具有最严格反欺诈措施的平台，使用移动代理，这些代理的IP来自真实的移动运营商。但如果部分流量物理上绕过代理，任何代理类别都无法提供保护——首先要确保密封性，然后是地址质量。
总结
WebKit的三个漏洞——DNS预取、WebAuthn相关的来源请求和WebTransport——表明“代理已启用”和“所有流量都通过代理”是两个不同的声明。在iOS上，它们之间的差距足够大，以至于普通网页在没有任何JavaScript代码的情况下就能识别Tor浏览器访客的真实地址。
在苹果准备修复之前，唯一有效的策略是检查，而不是假设。打开测试平台，比较地址，关闭多余的API。并将每次重大操作系统更新视为事件，之后需要重新检查配置。隐私与其幻觉之间的差异往往只在于一个未及时提出的问题：“所有流量都是真的吗？”同时，了解除了地址之外，哪些信号也在暴露您——我们在关于防止浏览器指纹识别的文章中讨论过这一点。