VPN 进 Tor、Tor 进 VPN：链路为何会断
当 VPN、Tor 和应用代理层层叠加时，顺序决定谁能解析域名、谁能承载流量。先找出第一处断掉的边界，再动手改这三个设置。
把 VPN、Tor 和应用代理叠在一起，感觉像是在成倍增加隐私，实际上也是在成倍增加连接可能死掉的位置。常见的结果是浏览器一直转圈，而三个工具都自称状态正常。一次性把三个设置全改掉，你就失去了唯一能判断是谁在撒谎的线索。
先按顺序画出你想要的路径，标明每个连接由哪个程序发起，以及每一步由谁来解析域名。
层次不会相加，只会相互作用
VPN 放在 Tor 前面，意味着Tor 客户端的入口连接是在隧道里走的。把 VPN 套在 Tor 后面，意思是 VPN 客户端自己的端点必须能通过 Tor 访问到，这是完全不同的要求。浏览器代理又多出一跳，操作系统对它一无所知。三种排列，三份各自独立的依赖清单。
每种排列都会改变谁能解析、谁能承载，以及谁看见第一个数据包。其中只有一种才是你真正想要的配置。
把直连路径也画进图里。备用路由、分离隧道例外或代理绕过，都可能让页面打开，却悄悄跳过了你想测的那条链路，而这种成功比失败更具误导性。
顺序决定能承载什么
Tor 通过它的 SOCKS 接口承载 TCP 流，客户端如果让代理去解析主机名，查询就会留在电路内部。UDP 在常规配置下不走这条路，所以要在 Tor 里嵌套 WireGuard 隧道，中途必须再加一个 TCP 中继。
OpenVPN 可以被强制走 TCP，所以这种排列至少还描述得清楚。它也慢得多、脆弱得多，而且它出问题时的表现跟端口被封一模一样。要把这两者区分开，花的时间会比修复其中任何一个都长。
解析是另一半。用 --socks5-hostname时代理去解析目的地，而单纯用 --socks5会先问本地解析器，把域名泄露到电路之外。这一个参数就决定了 域名查询是留在链路里，还是交给你的 ISP。
| Order | What must resolve the endpoint | What usually breaks |
|---|---|---|
| VPN, then Tor | The tunnel's resolver | Entry guards blocked by the VPN provider's filters |
| Tor, then VPN | The SOCKS proxy, remotely | UDP transports, which Tor does not carry |
| App proxy on top | The application itself | Proxy bypass rules and cached connections |
定位第一处断掉的边界
按数据包经过的顺序测试每一段，用无害的请求，遇到第一个失败就停下。记下先跑了哪条命令，因为顺序本身就是证据的一部分。两条命令可以区分是电路死了还是出口死了：
curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip curl -4 -s https://api.ipify.org; echo
第一条判断请求到底能不能通过 SOCKS 代理完成，第二条显示当前网络实际呈现的地址。如果第一条失败而第二条成功，问题就在 Tor 客户端或其之前。如果两条都成功而浏览器仍然失败，那说明应用走的是跟 shell 不同的路径。
公网 IP 页面只能描述最后一个可见出口。它没法告诉你前面经过了几跳，所以要把它和每个工具受支持的状态输出配对看，不要把单个数字当成链路图。
什么时候该停止再加层
如果你没法用一句话说清某一层贡献了什么，就把它去掉。目的不明的链路，凌晨三点没人能修；而一个说不清楚的跳，带来的隐私收益通常小于你损失的可用量。
如果某一层确实值得保留，先单独测它，再加上下一层，用同样两条命令重新确认路径。日常使用前要恢复完整链路，并且保持 TLS 校验和认证开启；为了让页面打开而接受的证书警告，是一种绕行手段，不是修复。趁记忆还新，把最终定下的顺序记下来。
把顺序写下来，包括每一层由哪个解析器作答。你能描述出来的可用链路，扛得住下一次更新；而靠反复试凑出来的可用链路，会随更新一起消失。写上日期和版本号，这样以后再出问题，可以和已知正常的状态作对比，而不是凭记忆争论。文本文件里十行字，能省掉一晚上的猜测。