近日，Tor项目宣布推出一款名为Snowflake Volunteer的安卓应用。该应用允许用户自愿分享部分网络带宽，以帮助那些有需求的人绕过流量审查、接入开放互联网。
这款应用由非营利组织Tor项目发布，其核心目的是扩大志愿者运行的Snowflake代理池，同时让用户能够控制电池消耗、网络使用和连接数量。目前已有约14.6万个活跃IP地址每天自愿贡献网络连接。
Snowflake的工作原理 Snowflake是一种Tor可插拔传输技术。它将用户的流量伪装成视频通话，并通过志愿者运行的短期代理进行路由。这样一来，流量比通过固定服务器发送的流量更难被审查者识别和封锁。
Tor项目称，绕过审查归根结底面临两大挑战：一是伪装网络流量以躲避审查，二是确保开放网络易于访问，Snowflake在应对这两大挑战方面尤为有效。
Tor项目在博客中解释称：“它将用户的流量伪装成视频通话的样子，并通过使用短期连接的志愿者代理进行路由，从而让流量更难被检测和封锁。”
Snowflake应用本身并不具备浏览功能，它只是在后台运行代理代理，将流量转发给需要帮助的用户。用户可以看到连接数量和数据传输量等统计信息，还可以选择限制电池消耗、限制使用移动数据，或完全关闭该功能。
为了融入普通互联网流量，Snowflake使用了Web实时通信（WebRTC）技术。这项技术原本用于点对点音频、视频和数据共享。对审查者来说，这些流量看起来就像普通的视频或语音通话。
描述中写道：“因此，审查者若想封锁这类规避工具，成本会非常高，因为他们需要封锁互联网的大部分内容才能达到最初的目标。”
Snowflake Volunteer应用的开发背景与现状 这款应用由葡萄牙的Bloco工作室开发，该公司此前联系了Tor的反审查团队，希望制作一款独立的Snowflake志愿者工具。这一想法源于Bloco与开放网络干扰观测站（OONI）的合作。开发人员在合作中看到，活动人士和非政府组织如何依赖审查规避工具来保持连接。
在此之前，志愿者可以使用浏览器扩展程序、网站嵌入、桌面命令行工具，安卓用户还可以使用Orbot的Kindness Mode（爱心模式）。
根据Tor的数据，在2026年上半年，Snowflake代理平均每天记录约14.6万个唯一志愿者代理IP地址。其中约三分之一与Orbot的Kindness模式相关。这一贡献表明，推出专门的安卓应用有望吸引更多志愿者。
Snowflake Volunteer基于Guardian Project开发的移动Tor组件，包括帮助开发者将Tor及其可插拔传输集成到移动应用中的IPtProxy库。借助这些现有组件，Bloco得以专注于降低电池消耗、保持服务在后台运行，以及让不熟悉Tor基础设施的用户也能理解该应用。
志愿者可以配置应用仅在未计量网络（如Wi-Fi）上运行、仅在设备充电时激活，并限制同时帮助的人数。启用后，应用会与Snowflake代理服务器签到，并自动将寻求临时代理的用户连接到Tor网络。志愿者无需逐一批准连接。
在经过与Tor社区的初步测试和反馈后，Snowflake Volunteer于今年4月正式上线。5月份，Tor项目观察到平均每天约有1300个独立代理 IP 地址。到6月份，这一数字上升到每天约1700 个，一个月内增长了29%。在初期阶段，代理活跃度最高达到每天超过2100个。这表明，一款专门的应用程序可以为Snowflake社区吸引更多志愿者。
安全性与使用注意事项 Tor项目强调，使用该应用是安全的：所有活动都是不可见的，其他用户在网络上的行为都会附上Tor出口节点的IP地址。
该应用不收集任何数据，但需要10项权限才能正常工作，包括网络访问、前台运行、发布通知、开机启动、重新排序运行中的应用、忽略电池优化、防止手机休眠等。
该应用目前可在Google Play商店、F-Droid以及开源代码仓库中获取。目前Google Play上的下载量超过100次。相比之下，Orbot应用已积累超过1000万次下载。如果用户想对应用进行一些修改，也可以从源代码进行编译。目前，这款应用目前已支持8种语言（中文、英文、法文、德文、日文、葡萄牙文、土耳其文和越南文）。
开发者建议，用户应在Wi-Fi或无限流量套餐下使用该应用，并了解代理可能会略微减慢连接速度。网络会限制同时连接的设备数量。开发团队已尽力确保应用在尽量少耗电的情况下运行。
有意成为志愿者的用户应考虑自己的移动数据限制、电池使用情况、当地法律以及工作场所或学校的网络政策。将应用限制在Wi-Fi和充电时段可以减少对设备的影响。同时，应只从官方渠道安装应用，并保持更新，以获取Snowflake和Tor审查规避组件的最新改动。
如何启用Snowflake Snowflake默认已嵌入Tor浏览器、Orbot应用、iPhone上的Onion Browser，以及点对点即时通讯应用Ricochet-Refresh中，但并未默认开启。无法接入Tor网络的用户需要手动选择此桥梁。
在Tor浏览器中启用Snowflake的方法是：进入设置，选择“连接”（或在地址栏输入about:preferences#connection）。在“桥梁”部分，找到“从Tor浏览器内置桥梁中选择”选项，点击“选择内置桥梁”，然后从菜单中选择“Snowflake”。其他应用也可通过各自的设置页面激活Snowflake。
Tor浏览器里的可插拔传输技术（Pluggable Transport）并不是什么神秘黑科技，本质上是一套把Tor流量伪装成普通网络行为的中间层。面对流量审查系统越来越精细的主动探测和协议指纹识别，单纯靠加密已经不够，必须让流量在字节层面、握手行为、连接建立方式上都尽量“不像Tor”。目前主流可用的四类是obfs4、meek、Snowflake和WebTunnel。
根据某学术文章介绍：严格来讲，obfs4、meek、Snowflake和WebTunnel本身均为可插拔传输技术，而非网桥（Bridge）。不同之处在于，obfs4和WebTunnel通常由志愿者部署服务端，供Tor的其它用户使用，任何用户可以自由搭建和部署obfs4和WebTunnel网桥；而meek通过CDN等前置基础设施将流量转发至运行meek-server的后端网桥；Snowflake先由broker撮合客户端与短生命周期志愿代理，再经该代理将流量转发至Snowflake网桥，并进一步接入Tor网络，其中前置CDN、broker和Snowflake志愿代理均不是Tor中继节点，当然也就不能称之为网桥。meek和Snowflake的网桥数量很少，大多数由Tor官方维护。Tor Browser将这四类可插拔传输技术统一置于网桥配置界面中，属于连接配置层面的产品分类，并不意味着可插拔传输技术与网桥在技术概念上等同。
下面“暗网下/AWX”从技术机制本身拆开讲这4种可插拔传输技术。
obfs4：把流量变成几乎无法区分的随机字节流 obfs4的核心思路是“先认证，再加密，最后把一切弄得看起来像噪声”。它采用基于ntor的认证密钥交换，并用Elligator2把Curve25519公钥的线上表示藏起来，避免公钥本身暴露可识别的特征。握手完成后，会话密钥建立，后续数据会被加密、认证，同时加入填充，使整体字节分布接近真正的随机流。
关键点在于，攻击者如果事先不知道通过桥接行（Bridge Line）带外分发的 Node ID 和身份公钥，几乎无法确认对面跑的是不是obfs4服务。主动探测也因此变得困难——你发探测包过去，对方不会给出可区分的错误响应。
时间线上，obfs4proxy 0.0.1在2014年9月3日首次发布，Tor Browser 4.5-alpha-1于同年11月18日在alpha版本正式加入。后续几个版本的安全修补很关键：0.0.11统一了握手失败时的处理逻辑，避免不同失败原因产生不同的可观测行为；0.0.12和0.0.14则专门修复了Elligator2实现里的可区分性问题。这些改动直接降低了协议指纹，增强了抗主动探测能力。
meek：躲在HTTPS和域前置后面 meek的思路完全不同。它不试图让流量“随机”，而是把Tor流量完整封装进HTTPS请求里，再利用域前置（domain fronting）把真正的目标藏起来。客户端看起来是在访问某个大厂的CDN或云服务域名，实际流量却被转到 meek 服务器。
早期实现比较独立。Tor Browser 4.0-alpha-1在2014年8月12日首次纳入meek 0.10客户端，当时还没有后来的 meek_lite。后来obfs4proxy 0.0.6加入了meek_lite，0.0.9引入uTLS来模拟浏览器式的TLS指纹，0.0.13又一度停止使用uTLS。再往后，Tor维护的0.0.14-tor2恢复了uTLS支持，Lyrebird 0.1.0把它纳入正式主线。Lyrebird 0.8.0进一步加入了多组URL/front组合，请求失败时可以自动轮换。
需要注意的是，uTLS在这里主要负责塑造ClientHello的浏览器式指纹，并没有改变meek基于HTTPS加域前置的基本架构。整个设计的前提是审查者很难大规模封锁主流CDN的域名和 IP，因为那样会误伤大量正常服务。
Snowflake：用志愿者浏览器当临时跳板 Snowflake走的是另一条路——利用大量临时、动态的志愿者代理。它的broker只负责会合与信令，撮合客户端和当前可用的志愿者代理。客户端与代理之间建立WebRTC数据通道，代理再通过WebSocket把流量转发给真正的Snowflake服务端。
这里有个容易误解的地方：志愿代理只是流量转发层，并不是Tor中继节点。它们不参与电路构建，也不知道最终目的地，只是临时把数据从一端搬到另一端。这种设计让审查者很难通过封锁固定IP或域名来彻底掐断，因为代理池是不断变化的。
Tor Browser 7.0a1在2017年1月25日首次允许Linux用户测试Snowflake，到2021年7月6日的TorBrowser 10.5才正式作为内置网桥选项向Stable用户开放。Lyrebird 0.5.0的意义在于把Snowflake客户端统一集成进来，而不是说Snowflake协议本身到2024年才出现。
WebTunnel：伪装成普通网站的WebSocket流量 WebTunnel相对较新，目标是把Tor流量封装成看起来像普通WebSocket的HTTPS连接，并且能借助反向代理，和真实网站共用同一个域名、IP和端口。审查者如果只看端口和SNI，很难区分这是正常网站访问还是隧道。
Tor Project在2024年3月12日宣布它稳定可用。Lyrebird 0.2.0加入WebTunnel客户端时已经支持HTTPS/TLS，并可以通过utls参数显式选择uTLS。到Lyrebird 0.7.0，uTLS被设为默认路径，同时加入了证书链哈希固定、多个TLS服务名候选以及sni-imitation等增强。uTLS启用后主要改变的是TLS ClientHello的可观测指纹，替代了标准Go TLS握手留下的特征。
和meek类似，WebTunnel也依赖“伪装成合法网站流量”这一思路，但它更强调与现有Web基础设施的共生，而不是单纯依赖域前置。
这四类可插拔传输技术解决的其实是同一类问题的不同侧面：obfs4追求字节级随机性与抗探测，meek靠HTTPS和域前置隐藏目标，Snowflake用动态志愿者池对抗固定封锁，WebTunnel则试图彻底融入普通网站流量。没有哪一种是万能的，实际使用中往往需要根据网络环境切换，或者组合使用。技术细节会随着审查手段的升级继续演进，但核心逻辑——让流量在观察者眼里“不像Tor”——始终没变。