Tor 网桥与 VPN：各自解决什么问题？

访问被封锁、Tor 浏览器连不上，而摆在面前的两种解决方案是网桥和 VPN。它们的失效位置不同，修复的东西也不同。网桥是 Tor 的一个不在中继目录中公开的入口，而 VPN 是通往你自选运营者的隧道。在两者之间做选择，首先要说清楚究竟哪里坏了。

两种工具，两项不同的工作

网桥改变的是 Tor 浏览器接入 Tor 网络的方式。客户端仍然构建电路，仍然为公开网络使用出口中继，并且除第一跳之外，其余一切仍然依赖目录权威。VPN 改变的是本地机器抵达你所选端点的方式，而该端点之后的一切都是运营者的事。

这个差别决定了每种工具能处理哪种故障。如果通往已知 Tor 入口地址的连接被封锁，网桥会提供另一个入口，Tor Project 的网桥文档说明了受支持的获取方式。如果网络检查所有流量，网桥可能有用也可能没用，因为可插拔传输改变的是连接的形态，而不是保证无人能够识别它。如果本地网络在监视目的地，那答案就是完全不同的问题。先把症状带来，再带产品来。

网桥到底隐藏了什么

网桥是一个不出现在公开目录中的中继，通过内置请求流程或电子邮件等独立渠道分发。它向任何阅读公开列表的人隐藏入口，这就是全部目的。

它并不对访问的网站隐藏目的地，因为发出该请求的仍然是出口中继。它也不会让本地网络失明，因为连接离开机器时仍然带着地址和时间模式。网桥首先是可达性工具，其次才是隐私工具。

通过 VPN 运行 Tor 会改变什么

通过 VPN 运行 Tor 会把第一跳挪走：本地网络看到的是 VPN 端点，而 VPN 运营者看到的是一条通往 Tor 入口的连接。电路本身从那一点起没有变化。

这种安排把谁能观察入口连接挪了位置，并增加了一个需要维护的账户、客户端和故障模式。它也改变了 VPN 运营者能够关联什么，这是政策问题而非技术问题。VPN 默认并不覆盖机器上的每个程序，因此单独的邮件客户端或同步工具可能仍走普通路径。把任何连接指示当作关于某个程序的证据，而不是关于设备的证据。

验证你真正在意的程序

要测试出问题的那个程序，而不是图标是否存在。正在监听的 SOCKS 端口和可用的电路是两件不同的事实，只有后者才有意义。

tor --verify-config
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip

第一条命令检查 Tor 进程是否接受其配置，第二条报告网络实际看到哪个出口地址。如果第二条失败而第一条通过，问题不在电路，而在本地代理设置。用当初失败的工具重复检查，因为浏览器扩展可能自带代理配置。

把证据留在工单里：所用的传输、入口类型和观察到的出口。这三行无需再做产品比较，就能解决大多数连通性争论。