经 Tor 的 VPN：先检查传输层

Tor 前置意味着 VPN 客户端坐在 SOCKS 代理之后，隧道本身经 Tor 建立，应用程序流量从 VPN 终点出去。这是一种特定顺序，而不是大多数人搭的那种。把 Tor Browser 和一个普通 VPN 客户端同时打开，并不迫使两个程序走对方的路径。

按顺序做检查。每一项决定下一项是否值得开始。

你实际在搭哪一种顺序

两种顺序常在同一个讨论里被混淆。Tor 在前是指 VPN 客户端通过 SOCKS 代理到达自己的服务器，因此隧道建在 Tor 之上。VPN 在前是指 Tor 流量从隧道出去，这是多数人无意中搭出的结构，却常被说成另一种顺序。前者把转发边界集中在 VPN 运营商，后者把它集中在 Tor 的入口与出口。两者都不是同时打开两个程序就能得到的东西。

在配置任何东西之前，先写下任务需要哪一种顺序，因为两者要求的软件设置不同，失败的位置也不同。顺序标错会让你花一个小时排查错误的层。下文全部假定 Tor 前置。

先检查传输，再谈其他

Tor 的 SOCKS 接口承载 TCP 流，不提供通用的 UDP 关联。传输为 UDP 的 VPN 无法把该代理当作普通网络接口，客户端设置也改变不了代理愿意转发的范围。常规形态的 WireGuard 是明显的受害者。TCP 模式的 OpenVPN 配置是常见变通，而且仍须明确告知它使用该代理。

ss -lntp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 -o /dev/null -w '%{http_code}\n' https://example.com

在通过代理排查隧道之前，先确认代理在监听，并且能承载一个普通的 HTTPS 请求。如果普通请求失败，VPN 客户端就不可能成功，日志也不会告诉你原因。

重写观察者地图

Tor 入口能看到连入 Tor 的来源，除非更早的环节改变了它，因此这一跳会得知你的地址。VPN 提供商会收到来自 Tor 一侧的连接，但仍可能知道你在隧道内发送的账户、付款记录或凭据。经由 VPN 到达的目标看到的是它的出口，而不是 Tor 的出口，这就把最终的转发边界集中在一个运营商身上。

它也不会重建通往每个目标的分布式路径。Tor Browser 为每个站点新建一条电路；经 Tor 承载的 VPN 只建一条隧道，其后的所有站点共用这个终点。把这一差别当作设计事实，而不是需要消除的限制。

坏掉时数一数故障层级

坏掉的配置至少有四个相互独立的层：SOCKS 连接、与 VPN 服务器的 TLS 握手、VPN 自身的握手，然后是隧道内的路由或域名解析。每一层的症状不同，修法也不同。因为隧道起不来就放宽证书校验，是典型的误判，它把传输问题变成了安全问题。

记录第一个失败的层，并停在那里。代理拒绝和密钥被拒不是同一件事的变体。

如果威胁模型需要 Tor Browser 的防护，就停下

让任意应用经 Tor 承载的 VPN 走，并不会给这些应用带来 Tor Browser 的指纹与隔离特性。它们的账号、标识符以及自身网络行为仍然相关，隧道不会把其中任何一项正常化。如果目标是与其他用户混同的浏览器，这种顺序给不了。

Tor Project 自己也警告过用户无法正确配置的组合，而这一种对多数人都适用。它是为狭窄威胁模型刻意做的设计，而不是通向整机匿名流量的捷径。