Tor 之前的 VPN：顺序究竟改变了什么

先连接 VPN 会产生一条特定链路：设备、VPN 端点、Tor 入口、Tor 回路、目的地。你的本地网络只看到一条通往 VPN 的加密连接，而 Tor 入口节点把 VPN 出口当作直接来源，而不是你的运营商地址。VPN 运营方则能看到通往 Tor 入口基础设施的连接，并能从目的地推断出 Tor 的使用。每个观察者都失去一些、得到一些，所以这个顺序是一种取舍，而不是升级。

这条链路不会改变网站从你的账户、Cookie 或输入内容中学到的任何东西。

顺序改变了什么

本地网络和 ISP 失去对 Tor 流量的直接可见性，因为第一跳现在是通往运营商的加密隧道。Tor 入口守卫失去了你的家庭地址，看到的是 VPN 出口。VPN 提供商获得了原本由你的 ISP 掌握的那些元数据：你联系哪些地址、在什么时间、移动多少数据。

过了入口守卫，回路的行为与之前相同。中继仍然区分入口、中间和出口的角色，VPN 看到的最终内容并不比你的 ISP 多。

确认真实使用的路径

分流隧道是预期链路与实际链路不符的常见原因。如果 Tor Browser 被排除在隧道之外，或者第二个配置文件走了不同的路由，那么即使界面看起来仍然连接着，入口守卫也会再次看到运营商地址。检查路由和实际观察到的出口，而不是图标。

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

经 9150 端口的 SOCKS 请求由 Tor Browser 自己的客户端应答，所以 IsTor true 的回复确认的是浏览器的回路，而不是其他每个程序都在使用它。解析器的输出值得记录，因为 DNS 可能走一条隧道没有覆盖的路径。把两份输出连同时间戳一起留存。它们是下一次比较的基线。

与普通终端发出的直连请求作比较：如果它也报告 Tor，说明还有别的东西在重定向流量，链路并非设计所假设的那样。

观察隧道断开时会发生什么

静默回落到本地接口的客户端会改变入口守卫看到的来源，而用户通常并不知道，因为页面仍然加载。真正值得测试的是这种故障，而不是顺畅路径。故意断开隧道，观察 Tor 流量是停止还是继续不受保护地传输。

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

阻止隧道之外出站流量的防火墙规则是唯一可靠的兜底控制，而且必须同时覆盖浏览器的 SOCKS 客户端和你在意的其他任何程序。浏览器扩展不是设备级 VPN，也不会影响其他程序或外部观察者。

判断额外一层是否值得信任

Tor 项目建议不要在没有能力自行评估配置的情况下把 VPN 放在 Tor 之下。他们给出的理由是额外的依赖：多一个当事方、多一个账户、多一种故障模式。如果目标是让 ISP 看不到你在用 Tor，VPN 正是针对这个观察者。如果目标是对抗全球观察者获得更强的匿名性，VPN 并不提供。

反过来也存在，而且名称不能互换：Tor over VPN 与 VPN over Tor 描述的是不同的信任关系和不同的故障行为。在混用之前先读比较。

写下你想移动哪个观察者，然后验证真实路径与设计一致，再验证故障行为。如果这三个答案不足以证明多出的账户和配置合理，那么有文档的 Tor Browser 配置要出错的地方更少。