obfs4、Snowflake 还是 WebTunnel：2026 年如何选择 Tor 网桥
当审查者封锁了人人都知道的 Tor 入口节点时，实用的对策是网桥：一台不列入 Tor 公共目录的中继，配合一个可插拔传输，让连接在线路上的样子发生变化。2026 年承担大部分这项工作的是三种传输：obfs4、Snowflake 和 WebTunnel。它们解决同一个问题——让 Tor 连接看起来像被允许的流量——但在获取方式、隐蔽程度和速度上差别很大。选错了很少意味着立即失败；通常意味着昨天还能用的网桥，下周就失效了。
网桥的共同点
Tor Browser 手册将网桥描述为排除在 Tor 公共目录之外的中继，因此审查者无法像枚举普通中继那样枚举它们；伪装由中继前面的可插拔传输负责。三种主流类型都遵循这一模式，而且都可以在 Tor Browser 的连接设置中选择或申请——手册的突破网络审查章节连同内置选项一起对此作了说明。另一项共同属性就没那么令人安心了：网桥和其他任何 IP 地址一样，审查者一旦得知，就能像其他地址一样将其封锁。可用不等于免疫。正因如此，分发本身是一项独立的工程——rdsys（Tor 对 BridgeDB 的重写）的存在，就是为了决定哪些网桥线路送到哪些用户手里。obfs4，成熟的默认选择
obfs4 把 Tor 流量包进看似随机的字节里，没有稳定签名；三者之中它的服役时间最长。Tor 的社区文档在比较各种传输时用一句话概括了这种权衡：obfs4 快速且经过验证，但难以分发。随机化经得起协议指纹识别，但网桥地址仍暴露给扫描，一条线路流通的时间越长，审查者已经把它编入目录的可能性就越大。所以对 obfs4 的抱怨很少关于速度；抱怨的是：使用频繁、长期存活的网桥往往会停止工作。关于 obfs4 如何建立连接的逐条讲解，见我们此前的文章。Snowflake，由志愿者拼成
Snowflake 走了另一条求生之路。入口点是志愿者运行的代理，流量则装扮成 WebRTC——浏览器视频和语音通话背后的协议族。项目网站描述流量经由未受审查国家的志愿者代理转发——这种伪装让审查者难以出手，因为封掉它就意味着封掉日常视频通话的流量模式。三者之中它的配置最简单：Snowflake 作为可选传输内置在 Tor Browser 中，项目还通过浏览器扩展招募算力。代价是性能。志愿者代理的带宽参差不齐、来来去去，Tor 的社区文档把 Snowflake 评为三者中较慢的选项。要预期比专用网桥更高、更不可预测的延迟；每次会话的质量取决于当时恰好承载它的那位志愿者。WebTunnel，穿上 HTTPS 外衣的 Tor
WebTunnel 是三者中最新的；Tor GitLab 上的参考实现可追溯到 2022 年 8 月。它基于 HTTPT——一种构建在 HTTP 之上的隧道协议——Tor 的社区文档直白地描述了意图：把 Tor 流量伪装成 HTTPS 网页浏览。面对深度包检测，这给审查者出了最难的难题，因为过滤 WebTunnel 意味着损害普通的 HTTPS——大多数网络唯一破坏不起的协议。成本落在运营者一侧：运行 WebTunnel 网桥需要一台有 root 权限的 Linux 服务器、一个域名、DNS 记录、有效的 TLS 证书以及 NGINX、Caddy 或 Apache 之类的反向代理，Docker 是替代方案。同一份文档警告说，绑定域名的网桥花钱且可能成为单点故障。对用户来说这些都不重要——WebTunnel 网桥到手时就是一行粘贴进网桥栏的文本。设定预期
- obfs4：最快、验证最久。通过 Tor Browser 的申请流程获取新线路，并预期热门线路会陆续被封。
- Snowflake：配置最容易，伪装搭视频通话流量的便车，代价是更慢、更波动的速度。
- WebTunnel：对协议指纹识别最有力的回应，依赖愿意维护域名和证书的运营者。