如果你在iPhone上用Tor浏览器,或者花钱开了iCloud Private Relay,大概会觉得自己的真实IP已经藏好了。隐私浏览器开发商Mysk最近发现,这个假设在三种情况下会失效——WebKit里三个不起眼的功能,会绕开代理配置,直接把设备的真实IP和DNS服务器交给对方服务器。中招的不只是普通App,连苹果自己的Private Relay也在内。
这事的起点是个用户报告:Mysk自家的隐私浏览器Psylo有用户发现,访问某些网站时会DNS泄露。团队一查,发现的不止DNS泄露,还有另外两个更严重的问题,能直接暴露设备真实IP。
三条绕过路径,三个不同的年龄
WebKit里所有网络连接理应经过代理,但这三个功能各自走了后门:
- DNS预取.网页用
<link rel="dns-prefetch">标签让浏览器提前解析域名,这个解析走的是设备正常DNS通道,不经过代理。iOS 26.0才开放这个功能。 - WebAuthn Related Origin Requests:passkey跨域验证时,系统的凭证服务会直接从设备发起请求去抓校验文件,完全绕开App配置的代理。这个功能iOS 18.0就有了。
- WebTransport.基于HTTP/3的低延迟通信,WebKit建立连接时压根没把代理参数塞进去。iOS 26.4才上线。
三个功能出现的时间跨度接近两年,却在同一份代理绕过清单里会师,说明WebKit团队在做新特性时,大概没有把“是否经过应用层代理”当成一条必须过审的红线。
VPN为什么没事
同样标着“隐私工具”,VPN偏偏躲过了这一劫。区别在于代理生效的层级。
Psylo、iOS版Tor浏览器依赖的是WKWebsiteDataStore.proxyConfigurations,这是苹果在iOS 17、macOS 14才给出的应用层代理接口,由App自己去接管网页发出的每一条连接。而VPN在系统网络层做全流量隧道,不管WebKit内部哪个模块想抄近道,流量出设备前都已经被打包走了。
但这不代表VPN能直接顶替Tor。VPN厂商本身能看到你是谁、连了哪些站点,信任模型是“相信这一家”。Tor想避开的恰恰是这种单点全知,iCloud Private Relay的设计目标也是让苹果自己都拼不出“谁访问了什么”。三者根本不是同一道安全等级的替代品,谁也补不了谁的洞。
真正的病根不在某个具体功能,而在苹果的App Store政策:所有iOS浏览器必须用WebKit引擎,不允许自带网络栈。桌面和Android版的Tor Browser能自己控制底层网络实现,绕过风险小得多;iOS上无论是Onion Browser还是Psylo,命脉全捆在WebKit这一套引擎里。
一个引擎级的边界疏漏,因此不再是某个App的bug,而是变成了整条iOS隐私浏览器生态的共同风险敞口——苹果自家的Private Relay同样跳不出这个坑,说明问题出在WebKit的页面加载流程之外那些“系统组件代劳”的场景,不是某家开发商没做好适配。
一个引擎的漏洞,足以打穿一整条产品线的隐私承诺。
Mysk已经把三个漏洞报告给了Tor Project和Onion Browser的开发者,自家Psylo在1.3.1版本里做了修复:拦截DNS预取标签,默认关闭WebTransport和WebAuthn,需要的网站可以按站点单独打开。这套“默认关、按需开”的思路算是把风险交还给用户自己判断,值得认可。
- 提醒.苹果是否已在WebKit层修复这三个问题、是否分配CVE编号、Tor Project和Onion Browser何时给出正式响应,目前都还看不到公开答案。对高风险人群来说,这段空窗期里,iOS上的隐私浏览器和Private Relay都不该被当成绝对安全的匿名工具。
如果你正在用iOS版Tor浏览器或者依赖Private Relay处理敏感事务,眼下更现实的做法是叠加一层系统级VPN或Tor隧道做纵深防御,同时留意开发者是否推送了新版本——这比等一个不知道什么时候会来的官方补丁靠得住。