Tor 是否走了 VPN？分割隧道改变了什么

有一个值得检验的信念：连接图标亮着，就意味着 Tor 的流量先经过了 VPN。这个推断比它应有的频率更常失败，而且是悄无声息地失败。分割隧道的匹配器可以让 Tor 进程留在隧道之外，同时设备保持连接，两个观察结果同时为真。图标报告的只是一个接口；数据包实际走过的路径是另一个问题。要回答这个问题，应看路由和匹配器，而不是看图标。

连接图标能证明什么，不能证明什么

VPN 已连接意味着有一个接口处于启用状态，并且到对端存在隧道。Tor 的入口连接是另一条由另一个进程创建的流；它是否进入那条隧道，取决于施加在它上面的匹配器和路由表。把进程排除在外，VPN 仍然连接，Tor 仍然建立电路，而你设想的顺序并没有发生。这两个观察回答的是不同问题，所以任何一个单独都不能决定顺序。

这个缺口不是任何一个工具的缺陷。排除规则正是为此而存在，而这条规则多半是有人还记得的原因写下的。

客户端对连接应用哪种匹配器

决定路径的是客户端对每条连接应用的匹配器：进程名、目标前缀或路由条目，视客户端而定。桌面快捷方式不与其中任何一种匹配，因为它是启动器，不是策略单元。先读客户端的规则集，说出它真正检验的单元，再讨论 Tor。如果客户端按目标匹配，问题就变成哪些前缀位于隧道之内，而不是哪个程序在运行。

只包含内部办公前缀的目标规则是一种常见形态，它按设计让普通的 Tor 入口连接保持直连。这是按配置工作的策略，无论图标看起来多健康，都不是 VPN 先于 Tor 的顺序。把匹配器和被排除的前缀写进笔记的同一行，因为这一对才是规则。

隧道断开时 Tor 会怎样

现在拿走隧道，看看 Tor 会做什么，因为只在网络健康时才成立的策略并不是你描述的策略。客户端可能在隧道断开期间拒绝直连流量，也可能悄悄放行，或者稍后重新连接并再次应用规则。手动断开和崩溃是不同的两件事，而崩溃是没有人演练过的那一种。用无害流量测试，并记录你实际观察到的是三种结果中的哪一种。

也要读客户端文档化的行为，但在你的测试与之一致之前，把文档当作假设。厂商描述的是默认值；例外由你的配置决定。

为什么出口地址回答不了入口问题

通过 Tor 访问的网站报告的是出口中继的地址，这只说明电路从哪里出去，完全不能说明第一跳是如何离开你的设备的。人们引用这个地址作为 VPN 优先的证据，但它承受不了这个分量。入口问题是本地的：哪个接口承载了到第一台中继的连接，VPN 对端会看到哪个源地址。要用设备上的路由查询或抓包来回答，而不是用网站。

两条不同的路径可以产生同一个出口国家，所以一致的结果证明的比看起来还要少。比较接口，而不是地理。

从未继承浏览器设置的应用程序

文档查看器、同步客户端和包管理器各自建立自己的连接，它们都不继承浏览器的代理设置。每个都遵循客户端的匹配器、自己的配置或系统代理，而这个组合很少被写下来。例外清单就是这样增长的：一次一个应用，每次添加都合理，直到没有人能说清清单覆盖了什么。不如为每个应用保留一张简图，写明匹配器、路径和失败时的行为。

如果额外的 VPN 层没有你能说出的任何用途，去掉这一层比维护一长串例外更容易验证。同时，Tor 项目关于 VPN 的说明 从另一侧探讨同一个顺序问题。活动部件越少，下次客户端更新后需要重新验证的假设也越少。