近日，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”——始终没变。
Tor官方在2024年底对该非盈利性重大隐私保护工程一年的工作进行了回顾，“暗网下/AWX”对Tor项目的文章进行了翻译与总结。Tor官方称，每当人们谈论Tor时，总会提到几个关键问题：性能、安全性和网络健康、审查规避以及第三方集成的兼容性。这些是Tor项目工作的重中之重，2024年Tor项目在这些领域都取得了重大进展，这篇文章里，Tor官方回顾了其是如何为解决这些核心问题和挑战而开展的一些新项目和正在进行的项目。
一、提高性能和安全性 洋葱服务改进：洋葱服务是一种使用Tor网络交换数据的通信技术。它们通过将所有通信保留在Tor网络内，来提供端到端加密和增强的匿名性。2024年，Tor项目推出了OnionSpray，这是一款即插即用的工具包，可以更轻松地将现有明网网站转换为可以使用.onion域名访问的暗网网站。OnionSpray具有代理功能，允许现有网站与“洋葱服务”无缝集成。通过简化设置，运营者可以快速受益于.onion暗网网站的抗审查和拒绝服务保护功能，而无需修改其现有基础设施。如需深入了解该功能，可以查看Tor项目早期采用者之一的案例研究。
支持Vanguards：从2024年夏天开始，Arti支持Vanguards，这是一种针对针对洋葱服务和洋葱服务客户端的防护发现攻击的防御措施。Vanguards于2018年首次作为v3洋葱服务的附加组件推出，旨在降低去匿名化攻击的风险并确保用户安全。
内存配额跟踪：Tor工程师和志愿者在Arti方面取得了重大进展，Arti是Tor核心的现代重写版本，采用Rust语言编写。Arti的模块化设计提高了可维护性、安全性和性能。为了抵御内存耗尽攻击，2024年Tor项目实现了内存配额跟踪。此功能允许Tor监控和限制其内存使用情况，优先关闭较旧的连接，以降低内存使用率并保持系统稳定性。这为所有用户提高了可靠性，并降低了高流量期间系统超负荷的风险。
带宽扫描仪：Tor保持网络稳定和健康的持续策略依赖于有效利用网络数据的能力。带宽扫描仪通过测量Tor网络中的中继容量，在网络的性能和安全性中发挥着重要作用。然后，这些数据会被用来指导如何构建与Tor网络连接的路径。这样做的目的是优化网络中的负载分布，最终提高浏览速度和可靠性。
二、扩大抗审查能力 发布WebTunnel：2024年年初，Tor项目成功推出了WebTunnel，这是一种新型桥接器，旨在与普通网络流量无缝融合，使审查者更难阻止Tor连接。通过模仿常见的互联网协议，WebTunnel提高了Tor网络在审查严格的地区的适应能力和弹性。自2024年上半年推出以来，该桥接器确保优先考虑较小流量的下载，以便更方便地分发，并简化了对uTLS集成的支持，进一步模仿了更广泛使用的浏览器的特性。这使得Webtunnel对普通用户来说是安全的，因为它有助于隐藏正在使用Tor等工具的事实。在为用户提供可靠的开放网络访问方面，这种方法已经显示出良好的前景，尤其是在像俄罗斯这样审查严格的地区。Tor官方一直希望扩大这些努力，如果有用户愿意通过运行新桥接器来支持Tor，可以考虑参与并学习相关的技术知识。
Snowflake更新：浏览器扩展程序Snowflake于2021年推出，是Tor对抗网络审查的一大飞跃。它使设置代理变得像打开网页一样简单。为了遵守Google Chrome扩展程序框架的变化，Tor项目重新设计了Snowflake的WebExtension，以符合Manifest V3标准。更新后的版本已于9月份成功部署，确保在Google逐步停止对Manifest V2的支持后，Chrome浏览器上的用户仍可使用Snowflake。Tor项目还通过自动化发布流程、替换过时的内容交付网络和修订协议来不断改进Snowflake。这些努力确保Snowflake对全球用户保持可靠和有效。
过渡到Rdsys：2024年，Tor项目从BridgeDB成功过渡到Rdsys，这是Tor项目的下一代桥接分发系统。Rdsys采用模块化架构，可帮助Tor项目快速适应新出现的审查策略，并允许Tor项目试验桥接分发渠道，更有效地覆盖用户所在的地理位置。
三、推进外联和宣传 与Tails联手：合作一直是Tor项目工作的核心，例如Tor项目与Tails的合并，就是一个很好的例子。Tails是一个便携式操作系统，使用Tor保护用户免受数字监控。2024年，Tails推出了几项影响深远的更新，包括一项防止数据丢失的新备份功能。展望未来，该团队正在探索如何在Tails上支持Signal等消息应用程序，使用户能够安全地进行通信，同时将敏感通信与可能受到入侵的设备隔离开来。
分散培训工作：Tor官方从自己开展全球培训课程转变为为当地培训师提供教授Tor的技能。Tor官方将2022年首次启动的”隐私弹性资助计划“扩展到49个国家/地区，使培训师能够开展本地化的Tor活动。培训师们报告了培训带来的重大影响，例如改善了对监控和协作学习的保护。
中继倡导：Tor官方继续扩大与大学的合作伙伴关系，以促进中继运营。这些努力不仅通过访问强大的中继节点增强了Tor网络，而且还通过树立积极的榜样鼓励更多组织为其基础设施做出贡献。
四、为Tor的未来做好准备 RPC子系统：2024年Arti最重要的进展之一是开发了一个完全重新构想的RPC子系统。该系统通过提供进程外应用程序接口（out-of-process API）、改进模块化和应用隔离，重新定义了应用程序与Tor的交互方式。与现有的控制端口不同，RPC子系统可防止应用程序访问敏感信息。。这种设计将使开发人员能够更轻松、更安全地构建使用Tor的工具和服务。
人性化的.onion地址：冗长复杂的.onion域名一直是可用性方面的难题与挑战。今年，Tor官方开始研究创建更人性化的替代方案，旨在提高新用户的可访问性，同时保持强大的安全性。这些努力将使”洋葱服务“更加平易近人，更加方便用户使用。
Android版本辅助功能：为了准备使用“辅助功能”——一项意在自动规避审查的功能——Tor项目重新设计了Android版本Tor浏览器的连接体验，采用了全新的“原生”实现方式。这是Tor项目长期努力将“连接辅助”引入安卓系统的长期努力的必要步骤，并为安卓用户提供了一系列小的改进，使其体验与桌面更加一致，并允许用户在连接前访问设置，从而实现更顺畅的故障排除和更高的可访问性。
Tor官方最后总结称，所有这一切都得益于Tor社区和用户的持续支持。Tor官方可以共同为数字权利打造一个更强大、更具弹性的未来。
3月6日，Tor项目发布了Tor浏览器13.0.11小版本，Tor项目称这是一个紧急更新版本，修复了域名前置（domain fronting）问题引起的snowflake连接问题。
Tor项目官方博客发布更新公告，宣布Tor浏览器 13.0.11现在已经可以从Tor浏览器下载页面以及Tor项目的分发目录中获取。文章称这是一个紧急版本，更新了Snowflake可插拔传输的域前端配置，以及审查规避系统使用的rdsys 后端的Moat连接。
根据@tor4zh之前的说法，部分用户反馈，2024年3月1日起，Tor浏览器内置的Snowflake开始在俄罗斯等部分国家出现连接问题，影响了Tor浏览器用户和Orbot用户的使用。
具体表现为Tor浏览器无法启动引导，如果检查日志文件，会显示类似这样的提醒：
[notice] Managed proxy "./client": offer created
[notice] Managed proxy "./client": broker failure Unexpected error, no answer. 原因似乎因为这个（Fastly阻止了域名前置）：
https://lists.torproject.org/pipermail/anti-censorship-team/2023-October/000328.html
Tor官方论坛提醒大家：如果遇到这个问题，可以尝试手动添加网桥地址来解决。具体地址请见官方论坛的这个帖子：
https://forum.torproject.org/t/fix-problems-with-snowflake-since-2024-03-01-broker-failure-unexpected-error-no-answer/11755
本次更新后，Tor浏览器 13.0.11修复了此问题，增强了Tor浏览器连接的稳定性。
获取网桥地址 由于网桥地址不是公开的，用户需自行索取。方式如下：
1、访问 bridges.torproject.org 并按照说明操作，或者使用 Gmail 或 Riseup 的邮箱服务发送电子邮件至[email protected]
2、在 Tor 浏览器中使用 Moat 获取网桥。
3、通过 Telegram 向 @GetBridgesBot 发送消息。在聊天中点击“开始”，或者输入/Start或/bridges。
使用网桥地址 Tor 浏览器桌面版：点击汉堡菜单 (≡) 的“设置”，然后点击侧栏中的“连接”。 在“网桥”部分，找到选项“输入已知网桥”，点击“手动添加网桥”，然后分行输入网桥地址。
Tor 浏览器 Android 版：点击“设置”'(⚙️)，然后点击“配置网桥”。开启“使用网桥”并选择“输入已知网桥”，并输入网桥地址。