💻 computer science

CensorLess: Cost-Efficient Censorship Circumvention Through Serverless Cloud Functions

本文提出了名为 CensorLess 的无服务器云函数代理系统，通过利用其成本效益、弹性及并发特性，结合本地代理、函数刷新和实时迁移机制，在实现强韧抗审查能力的同时将成本较现有低技术方案降低了 97%。

原作者： Dayeon Kang, Jade Sheffey, Mingshi Wu, Pubali Datta, Amir Houmansadr

发布于 2026-03-03

📖 1 分钟阅读☕ 轻松阅读

原作者： Dayeon Kang, Jade Sheffey, Mingshi Wu, Pubali Datta, Amir Houmansadr

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这是一篇关于CensorLess（无审查者）的论文介绍。简单来说，这是一项利用“云技术”的新发明，旨在用极低的成本帮助被网络审查限制的人们自由上网。

为了让你更容易理解，我们可以把整个系统想象成一个**“会瞬移的隐形快递员”**的故事。

1. 背景：为什么我们需要它？

想象一下，在一个被“围墙”（网络审查）围住的城市里，人们想读外面的书（访问被屏蔽的网站）。

以前的方法：大家通常雇佣固定的“快递员”（服务器）把书翻墙送进来。但是，这些快递员太贵了（服务器租金、带宽费），而且因为他们的住址（IP 地址）是固定的，审查员很容易把他们抓起来，或者把他们的路封死。
以前的尝试：有人尝试用“特价快递员”（云服务器的闲置实例），虽然便宜点，但还是要付租金，而且维护起来很麻烦，就像你租了一辆车，哪怕不开也要付钱。

2. CensorLess 的核心创意：云端的“瞬移”

CensorLess 发现了一个新招数：“无服务器计算”（Serverless）。

什么是无服务器？ 想象一下，你不需要租一辆车，也不需要付停车费。你只需要在需要的时候叫一辆“幽灵车”。车来了，你坐上去，车把你送到目的地，任务一结束，车就瞬间消失了。
优势：
1. 按次付费：只有车在跑的时候才收钱，不跑不收费。
2. 身份随机：每一辆“幽灵车”出来的时候，车牌号（IP 地址）都是随机生成的，而且用完就换。审查员根本抓不住它们，因为刚抓到一个，它已经消失了，下一个又带着新车牌出现了。

3. 系统是如何工作的？（三个关键角色）

为了让这个“幽灵车”系统跑起来，CensorLess 设计了三个聪明的机制：

A. 本地翻译官（Local Proxy）

问题：云端的“幽灵车”有个怪脾气，它只接受标准的“快递单”（HTTPS 请求），不接受直接打电话（Socket 连接）。
解决：你在电脑里装了一个“翻译官”。当你想访问被屏蔽的网站时，翻译官会把你的请求包装成标准的快递单，发给云端的幽灵车。等幽灵车把外面的书送回来，翻译官再拆包，让你看到内容。
比喻：就像你给一个只懂英语的外交官写信，你的翻译官先把你的中文信翻译成英语，外交官处理完后再翻译回中文给你。

B. 自动换车员（Function Refresher）

问题：如果一辆车跑太久，审查员可能会发现规律。
解决：系统里有个“自动换车员”。它每隔一段时间（比如 20 秒），就自动生成一批新的幽灵车，并通知大家换车。旧的幽灵车任务一结束就自动销毁。
比喻：就像接力赛，跑完一棒就立刻换人，审查员刚想记下这个人的特征，他早就换了一身衣服跑掉了。

C. 无缝换乘（Live Migration）

问题：换车的时候，会不会断网？
解决：系统设计了“无缝换乘”。当你正在下载大文件时，如果系统通知要换车，它会悄悄地把你的连接转移到新车上，就像在高速行驶的列车上换车厢，你甚至感觉不到停顿。
比喻：就像你在玩一个游戏，角色在跑动时，背景突然换了，但你还在跑，没有卡死。

4. 隐私模式：加个“保险箱”

虽然“幽灵车”很便宜且难抓，但如果你担心开车的“运营者”偷看你的信（因为普通模式下，运营者能看到你的数据），CensorLess 还有一个**“隐私模式”**。

做法：在幽灵车和最终目的地之间，再加一个**“保险箱”（VPS 服务器）**。
流程：你的信被加密后放进保险箱，幽灵车只负责运送这个密封的箱子。只有拥有钥匙的保险箱能打开它。
代价：这稍微贵一点点（因为要租那个保险箱），但比以前的方法还是便宜得多。

5. 为什么它这么厉害？（数据说话）

论文通过实验证明了 CensorLess 的惊人之处：

省钱：和目前最便宜的方案相比，CensorLess 能节省 97% 的费用！
- 比喻：以前送一份文件可能要花 100 块钱，现在只要 3 块钱。
抗审查：因为 IP 地址一直在变，而且利用了云服务商（如 AWS）的庞大网络，审查员很难封锁。如果审查员封锁了整个云服务商，会误伤无数正常企业，所以审查员通常不敢这么做。
速度快：虽然多了一层包装，但速度几乎和直接上网一样快。

6. 总结

CensorLess 就像是一个**“会瞬移、按次收费、还能自动换马甲”**的超级快递员网络。

它利用了现代云计算的一个特性（用完即走、按量付费），把原本昂贵的“翻墙”成本降到了几乎可以忽略不计的程度，同时让审查者难以捉摸。对于生活在信息受限地区的人们来说，这是一项既经济又高效的“数字逃生”工具。

一句话总结：以前翻墙像“租房子”，又贵又容易被抓；现在 CensorLess 像“坐瞬移出租车”，便宜、灵活，而且审查员根本抓不住。

这是一份关于论文《CensorLess: Cost-Efficient Censorship Circumvention Through Serverless Cloud Functions》（CensorLess：通过无服务器云函数实现低成本的网络审查规避）的详细技术总结。

1. 研究背景与问题 (Problem)

随着全球互联网审查的加剧，网络审查规避工具的需求日益增长。然而，现有的规避系统面临着严峻的经济成本和可持续性挑战：

高昂的运营成本：传统的规避工具（如 Tor、Shadowsocks 等）依赖租用服务器、购买带宽和不断轮换 IP 地址，导致运营者（尤其是非营利组织）资金压力巨大。
现有低成本方案的局限性：虽然已有研究尝试利用云服务商的“竞价实例”（Spot Instances，如 SpotProxy）来降低成本，但这些方案仍涉及实例维护、网络连通性管理以及持续的 IP 轮换开销，且存在较高的运营复杂度。
技术挑战：无服务器（Serverless）平台（如 AWS Lambda）虽然具有按请求付费、自动扩展和 IP 动态轮换等优势，但其底层架构对开发者是“黑盒”的。主要限制包括：无法使用 Socket 通信（限制了传统代理功能）、冷启动延迟以及负载大小限制。

核心问题：如何设计一种既能利用无服务器架构的极致成本效益和动态特性，又能克服其技术限制（特别是无法直接进行 Socket 通信），从而实现高效、低成本且具备强抗审查能力的网络代理系统？

2. 方法论与系统设计 (Methodology)

作者提出了 CensorLess，这是首个基于无服务器云函数（Function-as-a-Service, FaaS）构建的审查规避代理系统。其核心设计思想是利用无服务器函数的瞬时性（Ephemerality）、按量付费和自动扩展特性。

系统架构

CensorLess 由四个主要模块组成：

本地代理（Local Proxy）：部署在客户端。负责拦截流量，将传统的 HTTP/Socket 请求转换为 HTTPS 请求，以适配无服务器函数的限制。
控制器（Controller）：由运营者管理，维护客户端与桥接函数（Bridge）的映射数据库。
函数刷新器（Function Refresher）：定期在多个区域批量生成新的无服务器函数实例，并销毁过期的实例。
无服务器函数池（Serverless Function Pool）：作为代理桥接点，处理转发请求。

三大核心机制

为了解决无服务器环境的限制并实现抗审查，CensorLess 采用了以下机制：

请求翻译（Request Translation）：
- 问题：无服务器函数（如 AWS Lambda）不支持 Socket 通信，无法直接建立 TCP 连接。
- 方案：本地代理将客户端的 HTTP/HTTPS 请求封装为标准的 HTTPS GET/POST请求发送给无服务器函数。函数端解析请求头，提取目标地址，重新发起对目标网站的请求，并将响应返回给客户端。
- 优势：完全规避了 Socket 限制，利用现有的 HTTPS 基础设施。
自动桥接生成与轮换（Automatic Bridge Generation & Rotation）：
- 机制：利用无服务器函数的瞬时性，系统定期（例如每 20 秒或更短）在多个地理区域生成新的函数实例，并分配给客户端。
- 抗审查：由于每个函数实例都有新的、随机的 IP 地址，且生命周期极短，审查者难以通过 IP 封锁或长期追踪来阻断服务。
实时迁移（Live Migration）：
- 机制：当需要切换桥接时，控制器通过当前活跃的桥接函数向客户端发送“迁移标签”（包含新桥接 URL）。客户端检测到标签后，无缝切换到新桥接，无需中断连接或暴露新桥接的元数据。
- 优势：实现了在不中断服务的情况下动态更新入口点，极大增加了审查者识别和封锁的难度。

隐私增强模式（Private Mode）

为了应对不可信的云服务商或运营者，CensorLess 提供了一个“隐私模式”：

引入一个长期运行的 VPS（虚拟专用服务器）。
客户端通过 SOCKS 代理与 VPS 建立加密连接（使用公钥加密）。
无服务器函数仅作为加密流量的传输通道（隧道），无法解密内容。
代价：增加了少量成本（约增加 20%），但提供了端到端加密。

域名前置（Domain Fronting）

CensorLess 可选地利用 AWS Lambda 支持的域名前置技术。客户端在 TLS 层（SNI）使用合法的云域名，而在 HTTP 层（Host Header）使用被屏蔽的目标域名。这使得审查者难以在不破坏大量合法云服务的情况下进行封锁。

3. 主要贡献 (Key Contributions)

首个无服务器规避系统：提出了 CensorLess，首次将无服务器计算的原语（按请求付费、无状态、瞬时性）应用于审查规避领域，实现了极致的成本效率。
克服技术限制的创新设计：通过“请求翻译”和“本地代理”架构，成功解决了无服务器平台不支持 Socket 通信的致命缺陷，同时保持了低成本。
极致的成本效益：相比现有的低成本方案（如 SpotProxy），CensorLess 将运营成本降低了 97%。
全面的评估：在性能、抗审查有效性（通过博弈论模拟和真实环境测试）及成本方面进行了详尽的评估，并提供了隐私模式的成本 - 隐私权衡分析。
开源实现：提供了基于 AWS Lambda 的完整实现（TypeScript/Node.js/Python），代码量约 2000 行，易于移植到其他云厂商。

4. 实验结果 (Results)

成本对比：
- 在每月处理 6.76 GB 流量的假设下，CensorLess 标准版（Vanilla）的月成本仅为 $0.27。
- 隐私版（Private Mode，含 VPS）月成本为 $3.41。
- 相比之下，最先进的低成本方案 SpotProxy 的月成本约为 $9.28**（最优多网卡配置）至 **$ 54.58。
- 结论：CensorLess 比 SpotProxy 便宜 97.1%（标准版）和 63.3%（隐私版）。即使在扩展到 300 个代理节点时，每日成本仍低于 $3.50。
性能表现：
- 吞吐量：在浏览网页、下载 PDF 和流媒体视频等场景下，CensorLess 的吞吐量与无代理状态非常接近，开销极小。
- 并发能力：得益于无服务器的自动扩展，系统能稳定处理高达 1000 个并发请求，仅在初始冷启动阶段有短暂延迟。
- 迁移影响：桥接轮换（每 20 秒）对用户体验的影响微乎其微，总执行时间仅略有增加。
抗审查有效性：
- 博弈论模拟：在对抗最优审查策略（Optimal Censor）的模拟中，即使 50% 的客户端是审查代理，CensorLess 仍能保持约 95% 的用户连接率和未封锁代理比例。
- 真实环境测试：在中国南京（被审查区域）的实测中，使用 50 个不同的无服务器函数，在 36 小时的测试期间未被封锁，成功访问了 Google、ChatGPT、HuffPost 等被屏蔽网站。

5. 意义与局限性 (Significance & Limitations)

意义：

经济可持续性：CensorLess 证明了利用无服务器架构可以大幅降低审查规避工具的运营门槛，使得个人或小规模组织也能长期维持抗审查服务。
技术范式转移：展示了从传统的“长期运行实例”向“事件驱动、无状态函数”转变在对抗网络审查中的巨大潜力。
抗封锁能力：利用云函数的动态 IP 和域名前置特性，极大地提高了审查者的封锁成本（Collateral Damage），迫使审查者面临封锁整个云服务商的困境。

局限性与未来工作：

HSTS 限制：标准版依赖 HTTP 转 HTTPS 的转换，对于强制 HSTS 预加载的网站，本地代理可能无法拦截请求（需使用隐私模式或旧版浏览器）。
协议支持：标准版仅支持 HTTPS GET/POST，不支持 WebSocket 等实时协议（隐私模式通过自定义协议部分缓解）。
DoS 攻击风险：按量付费模式容易受到恶意的大规模请求攻击（导致运营者成本激增），需通过客户端认证和云厂商的限流机制来缓解。
云厂商合作风险：如果云厂商与审查者合谋（如主动封锁特定模式流量），系统可能失效。但作者认为基于经济理性，云厂商不太可能采取此类行动。

总结：
CensorLess 是一项突破性的工作，它巧妙地将无服务器计算的“劣势”（无状态、短生命周期）转化为对抗审查的“优势”（难以追踪、动态轮换），同时通过架构创新解决了技术限制，为未来低成本、高可用的网络自由工具提供了新的设计范式。