Tor Browser桌面模式为何直连请求为直连请求？

一次抓包，发现了几条不该出现的请求 事情来自开发者 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 发往公共互联网节点。 抓包统计显示： HTTP 尝试：5 次 HTTPS SNI 捕获：0 更敏感的一点在于，请求里还能看到： 设备真实 IP Referer 中包含.onion地址 User-Agent 为 Tor Browser 换句话说，访问匿名站点的上下文信息，被带着真实 IP 一起发到了普通互联网服务器。 这段证据能说明什么，不能说明什么 需要先划清边界。 这段抓包能够证明的一点是：在当时的测试环境下，Android 设备确实产生了未经过 Tor 的外部请求。 但它并不能单独证明某个明确漏洞机制，例如“Tor 网络被绕过”或“浏览器必然泄露 IP”。 因为还存在多种可能路径，例如： 浏览器在加载资源时触发额外网络请求 DNS 预解析或资源预连接 Android 网络栈或代理配置问题 Desktop Mode 触发不同的页面资源结构 也就是说，目前看到的是一个现象：访问 .onion 页面时，设备出现了直连外部服务器的流量。 真正的原因需要更系统的复现实验才能确认。 Desktop Mode 为什么可能改变网络行为 很多用户把 Desktop Mode 理解为“换一个 User‑Agent”。 实际浏览器实现通常更复杂。 当网站识别为桌面浏览器时，可能会加载完全不同的一套资源： 桌面版脚本 字体或 CDN 资源 不同的图片与样式文件 额外的资源预加载 如果这些资源指向普通互联网域名，而某个请求路径没有经过 Tor 代理，就可能产生直连流量。 抓包中的目标地址——Google 与 Akamai——正是大量网站使用的公共基础设施。 这让一个可能的场景变得合理： .onion 页面加载 → 页面资源引用外部域名 → 浏览器尝试获取资源 → 请求没有进入 Tor 代理链路。 是否真是这样，还需要进一步验证。 匿名浏览真正困难的部分：客户端网络路径 Tor 的核心设计是把流量送入多跳匿名网络。 但浏览器本身并不是单一网络模块，而是一组复杂组件： 页面资源加载 DNS 查询 预连接 更新检查 崩溃报告 只要其中任何一个模块绕开代理，就可能产生直连流量。 安全研究里经常出现类似问题： 匿名系统本身没有被攻破，但客户端实现留下了出口。 因此很多隐私浏览器在工程上会做一件事：尽量强制所有网络请求走统一代理路径。 问题往往就出在这里——不同平台、不同网络栈，行为并不完全一致。 这类问题为什么会变成产品问题 如果只是一次安全研究，它只是浏览器实现细节。 但在商业世界里，越来越多产品把“匿名访问”当作核心卖点，例如： 代理浏览器 自动化数据采集工具 AI Agent 自动浏览 账号运营基础设施 这些产品卖的并不是浏览器，而是一个承诺： 访问行为不会暴露真实来源。 一旦出现直连请求，风险就很现实： 目标网站记录真实 IP 批量账号被关联 数据采集被封锁 所以很多企业用户会追问一个更具体的问题： 你们如何证明所有流量都走代理？ 谁会为“可验证的匿名环境”付费 在实际市场里，最愿意为严格网络隔离付费的通常是三类团队： 大规模数据采集公司 Web3 或隐私产品团队 账号运营和自动化团队 他们需要的不只是代理 IP，而是一个可验证的运行环境。 典型要求包括： DNS 必须走代理 浏览器资源加载必须走代理 系统库网络请求不能直连 这也是为什么一些新产品开始提供“隔离浏览环境”或“容器化浏览器”。 它们控制的不只是 IP，而是整个网络出口。 如果你在做类似产品，工程上至少要验证三件事 这次抓包其实给工程团队留下了一份非常直接的检查清单。 第一步：从设备出口抓包，而不是只看应用日志。 第二步：确认 HTTP、HTTPS、DNS 是否全部进入代理链路。