在 Tor 前面加一层 VPN 就更容易躲避监视吗？

在一条路径上再加一段加密，并不会让观察者消失；他们只是换了位置，有时还会多出一个。真正有用的练习是把路线画出来，标出每一步里谁看得到什么，因为 Tor 前面的 VPN 和经由 Tor 抵达的 VPN，对几乎每个值得问的问题都给出相反的答案。两种布置都无法击败已被攻破的端点，也都修不好一个直接写着用户名字的账号。按顺序走完这条路，再问一句某层消失时会在哪里断掉，口号就变成了决定。

沿路径走一遍，给每个观察者命名

从最普通的 Tor 情形开始，把每一跳都标注出来。本地网络和运营商看到的是连到一个 Tor 入口，外加它的大小和时间。入口守卫看得到客户端地址，所以守卫是一段长期关系，而不是随机挑选。出口节点看得到目的地，以及所有没有做端到端加密的内容的明文；而目的地只看到一个出口地址，上面并没有挂客户端地址。

在加任何东西之前，先把这些标注写下来。图本身就是论证，而且很好核对。

两种顺序带来不同的观察结果

把 VPN 放在 Tor 前面，意味着流量离开设备前往 VPN 服务商，从该服务商出去，然后才到达 Tor 入口。本地网络完全看不到 Tor，而当一个网络封锁或监视 Tor 时，这正是全部目的。入口守卫现在看到的是 VPN 的地址而不是用户的地址，VPN 服务商则看到一个特定用户以特定的时间规律连接 Tor。这家服务商成了一个握有宝贵观察的新参与方，它的日志政策从此落在威胁模型之内，而不是之外。

经由 Tor 抵达 VPN 把顺序倒了过来，也把暴露面倒了过来：目的地看到的是 VPN 的地址，Tor 出口不再看到目的地，VPN 服务商看到的是涌进来的 Tor 流量，而不是用户的家庭住址。它还让连接多背两层延迟，并要求客户端支持，而很多商业应用并不提供这种支持。

在两者之间选择，问的是哪个观察者最重要，而不是哪个听起来更安全。想把 Tor 的使用对本地网络藏起来的用户要的是第一种顺序；想让目的地学不到任何能归到自己身上的东西的用户，需要的是另一套分析，而两种顺序都没有藏住账号名。

还有什么能识别会话

地址层面的观察者只是画面的一部分，而且常常不是决定性的部分。登录着的账号把活动系在身份上，与哪个出口地址承载了数据包无关；服务能对应到某个人的付款记录也是一样。浏览器的状态同样有份：一个长期 cookie、一次保存的登录或一个可识别的扩展，就能沿着本以为无法关联的链路把用户串起来。

提交给站点的内容是第三个信号。带元数据的文档、表单里敲进去的名字、独特的行文风格，都能穿过任意多层加密，而挡在它前面的工具没有一件是用来处理这个的。老老实实列出这些标识，比再加一跳更能保护自己。

为会消失的一层做准备

真正拉开差距的是失效时的行为，而这是配置的属性，不是哪件工具的功能。如果 Tor 被设置为经由 VPN 出网，而 VPN 掉线了，Tor 是停下来，还是悄悄从普通路径重连？后一种结果不算泄露给目的地，但它让本地网络知道有人在用 Tor，而这也许正是这套布置想避免的事。

设备级 kill switch 能靠拒绝隧道外的流量来落实答案的一部分，而它只覆盖设备自己路由的流量。被排除在隧道外的应用会绕开这层保护，连接建立时用到的解析器也可能泄露域名，哪怕载荷始终留在隧道里。与其假设开关覆盖了一切，不如去读排除项和解析器配置。

别动浏览器整包

Tor Browser 的防护依赖整个包按设计运行：它自带的代理配置、站点之间的隔离，以及指纹防御。把普通浏览器指向本地 Tor 端口，或者给 Tor Browser 加一个代理扩展，都会改变设计所依赖的前提。Tor Project 自己对把 VPN 与 Tor 合用的说明，把这种组合当成高级配置，而那份谨慎针对的正是这些相互作用，而不是 VPN 厂商。

在组合工具之前，要能用简单的句子说清正常路径、失效路径，以及每个运营方各自的角色。如果唯一的理由是两层听起来更安全，那就没有一个需要照着设计的要件，而真正加进来的东西只是一个新的失效模式。