Tor 还是 VPN：按每条路径迫使你信任谁来决定

在 Tor 与 VPN 之间做选择，归根结底取决于你能容忍哪一方看到连接的两端。VPN 把这一视野集中在你选定的一个运营商身上。Tor 则把它分散到各个中继，因此任何单个中继都不应得知你是谁、你取回了什么。

两种安排本身都不会让你匿名。选一个你能大声说出其剩余信任的安排，然后修补它未覆盖的部分。

数一数谁能把你与某个目的地关联起来

使用 VPN 时，每条被覆盖的流量在到达目的地之前都会先到达运营商的出口。该运营商必然看到你的源地址，并且对于任何不经它加密的内容，还会看到你所请求的目的地。TLS 把页面内容挡在这一视野之外，但通常在建立连接时会让主机名保持可见。因此，某一方就能把你与某个网站关联起来，而这种关联正是你给予的信任。

Tor 把这些两半分散到三个中继：知道你的地址但不知道目的地的守卫中继、两端都不知道的中间中继，以及知道目的地但不知道你的出口中继。该设计假设没有任何单个中继同时掌握这两项事实，这比信任一家公司更弱，也更有用。它并不假设中继是诚实的，也无法击败同时观察路径两端的监视者。

两种设计共有一个弱点，而且它就在目的地。如果你登录，无论数据包走哪条路径，服务都会把该会话与你的账户关联起来。路由改变的是请求看似来自何处，而不是页面要求你提供什么。

覆盖范围比路由示意图更重要

VPN 在网络层进行路由，因此设备上的每个应用都会继承隧道，除非你有意排除它。正是这种广度让它能同时服务于邮件客户端、包管理器和浏览器。

Tor 浏览器是一个打包产品，它的保护大多存在于浏览器内部：统一的指纹、站点之间的隔离，以及由安全级别而非你安装的扩展来限制的脚本。 把 Chrome 指向 SOCKS 端口只能买到路由，买不到上述任何一项，而这正是错置自信的常见来源。

桌面上的其余部分毫发无损。同步客户端、更新程序或在另一个程序中打开的下载文档会按该程序的配置联网，除非你在那里也做了设置，否则它们都不会经过 SOCKS 监听器。先列出会访问网络的应用，再问所选工具究竟覆盖了其中哪些。覆盖范围是配置的属性，而不是意图的属性。

按三个条件来选择

这个决定通常归结为三个问题：流量是来自一个应用还是整个设备，目的地是否必须无法识别你的地址，以及你是否需要访问私有网络？按这个顺序回答，工具通常自己就会选出来。

当两项要求冲突时，权衡你能落实哪一项。排除列表会漏的设备级隧道，比你能演示的仅限浏览器的路由更糟。

对两条路径来说，验证成本都很低，而且应该在你依赖其中任何一条之前进行：

curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip
curl -4 -s https://api.ipify.org; echo

第一条命令给出错误结果，意味着请求跑到了电路之外，而这正是值得及早抓住的故障。把第二条命令的结果与你的服务商分配的地址比较，而不是与上周记住的地址比较。

两种方案都修不好的东西

应用层加密仍然在做任何路由都做不到的事。穿过隐私网络的明文 HTTP 在出口处依然可读，而 HTTPS 仍是唯一从头到尾保护载荷的东西。TLS 也不说明你输入的主机名，因此目的地对任何终止这条路径的人依然可见。

账户会识别你，任何路由选择都改变不了这一点：无论头部里是什么地址，服务都知道是谁登录的。看到足够多网络的观察者所做的关联、你自己设备被攻破，以及你在表单里输入的一切，在两种设计中都依然存在。请把这两种工具看作搬移信任的方式，而不是删除信任的方式。

从每个项目都有文档的默认配置开始，用上面两条命令确认路径，然后才考虑在 Tor 之下再套一层 VPN。把它们嵌套起来是一种带有自身故障模式的配置，而不是免费的升级。