事情来自开发者 shchess 的一次简单测试。
他在 Android 手机上使用 Tor Browser 访问一个 .onion 网站，并把浏览器切换到 Desktop Mode（桌面模式）。随后对设备出口流量做了抓包。
抓包里出现了三条异常记录：
[18:12:10] 10.188.1.98 -> 192.178.183.95 (Akamai) [18:12:14] 10.188.1.98 -> 142.251.14.95 (Google) [18:12:22] 10.188.1.98 -> 142.251.20.95 (Google)
这些请求并没有走 Tor 网络，而是直接从设备 IP 发往公共互联网节点。
抓包统计显示：
更敏感的一点在于，请求里还能看到：
.onion 地址换句话说，访问匿名站点的上下文信息，被带着真实 IP 一起发到了普通互联网服务器。
需要先划清边界。
这段抓包能够证明的一点是：在当时的测试环境下，Android 设备确实产生了未经过 Tor 的外部请求。
但它并不能单独证明某个明确漏洞机制，例如“Tor 网络被绕过”或“浏览器必然泄露 IP”。
因为还存在多种可能路径，例如：
也就是说，目前看到的是一个现象：访问 .onion 页面时，设备出现了直连外部服务器的流量。
真正的原因需要更系统的复现实验才能确认。
很多用户把 Desktop Mode 理解为“换一个 User‑Agent”。
实际浏览器实现通常更复杂。
当网站识别为桌面浏览器时，可能会加载完全不同的一套资源：
如果这些资源指向普通互联网域名，而某个请求路径没有经过 Tor 代理，就可能产生直连流量。
抓包中的目标地址——Google 与 Akamai——正是大量网站使用的公共基础设施。
这让一个可能的场景变得合理：
.onion 页面加载 → 页面资源引用外部域名 → 浏览器尝试获取资源 → 请求没有进入 Tor 代理链路。
是否真是这样，还需要进一步验证。
Tor 的核心设计是把流量送入多跳匿名网络。
但浏览器本身并不是单一网络模块，而是一组复杂组件：
只要其中任何一个模块绕开代理，就可能产生直连流量。
安全研究里经常出现类似问题：
匿名系统本身没有被攻破，但客户端实现留下了出口。
因此很多隐私浏览器在工程上会做一件事：尽量强制所有网络请求走统一代理路径。
问题往往就出在这里——不同平台、不同网络栈，行为并不完全一致。
如果只是一次安全研究，它只是浏览器实现细节。
但在商业世界里，越来越多产品把“匿名访问”当作核心卖点，例如：
这些产品卖的并不是浏览器，而是一个承诺：
访问行为不会暴露真实来源。
一旦出现直连请求，风险就很现实：
所以很多企业用户会追问一个更具体的问题：
你们如何证明所有流量都走代理？
在实际市场里，最愿意为严格网络隔离付费的通常是三类团队：
他们需要的不只是代理 IP，而是一个可验证的运行环境。
典型要求包括：
这也是为什么一些新产品开始提供“隔离浏览环境”或“容器化浏览器”。
它们控制的不只是 IP，而是整个网络出口。
这次抓包其实给工程团队留下了一份非常直接的检查清单。
第一步：从设备出口抓包，而不是只看应用日志。
第二步：确认 HTTP、HTTPS、DNS 是否全部进入代理链路。
第三步：测试不同浏览模式，例如：
很多直连问题只有在真实抓包时才会出现。
在匿名网络产品里，真正决定可靠性的往往不是加密算法，而是一个更基础的问题：有没有任何请求绕开你设计的那条路。
其它
关注微信公众号解锁更多技术资讯，感谢您的支持！
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。