摘要

随着全球网络审查日益加剧，各类审查规避工具相继涌现。然而，这些工具的经济成本直接影响用户选择和提供方运营的可持续性。近期的审查规避研究尝试将基础设施即服务（IaaS）竞价实例用作桥接节点，以提高成本效益，但网络连接和实例维护仍会产生可观费用。

在本研究中，我们提出 CensorLess——一种利用无服务器平台独特优势的审查规避代理。CensorLess 由三个组件构成：管理客户端通信并执行无服务器安全约束的本地代理、定期重新生成桥接节点的函数刷新器，以及维持连接连续性的实时迁移机制。

得益于其设计，CensorLess 继承了无服务器计算的若干关键特性：成本效益、短暂性、可扩展性、并发性和高性能。与现有低成本的最先进审查规避技术相比，CensorLess 将运行成本降低了 97%，同时通过轮换桥接节点提供稳健的抗审查能力。

关键词：审查规避、代理系统、无服务器计算

1. 引言

网络审查仍是全球信息获取的一大障碍，审查规避工具因而应运而生。审查规避系统的经济成本一直是用户和系统提供方共同关注的关键因素。对审查规避工具提供方而言，获得资金是一项普遍而严峻的障碍，因为维持审查规避系统运行需要承担服务器租金、上游带宽费用、持续轮换 IP 地址等诸多成本 [91, §5.3]。由于这些系统的用户数量大幅增加，Open Technology Fund 近期提高了对审查规避工具的资助 [30, 48, 81]。大规模审查规避工具的运行成本可能高得令人难以承受 [80]。例如，Tor 项目在 2018 年 2 月为一台第三方服务器支出了 $11,152.72 [69]。近期针对审查规避工具用户的调查 [29, §4.3]、[74, §5.2] 表明，价格几乎总能位列用户选择工具时最看重的三项要求。尤其对技术水平有限至中等的用户而言，价格是其决策中的主要因素；71.1%（613 人中有 436 人）的用户将价格列入最重要的三项要求 [74]。

近来，基于代理的审查规避系统开始利用云计算来降低运行成本。在基于代理的审查规避工具中，受审查地区的用户将流量发送到一台可以访问互联网的代理服务器，该代理服务器再将流量转发至真实目的地。代理服务器在整个通信过程中充当桥接节点或中继，使用户能够自由访问互联网。代理可以部署在多种网络中，包括互联网服务提供商（ISP）[41]、内容分发网络（CDN） [96]、边缘网络 [53, 64] 和云基础设施 [17, 54]。现代基于云的审查规避代理使用按用量计价的云实例构建分布式桥接节点网络，以控制成本  [54]。

本文利用无服务器云平台（亦称函数即服务，FaaS），以降低审查规避代理相较于以往方法的运行成本。无服务器云支持按请求随用随付、自动扩缩容、高并发和短暂性。按请求计价模式显著降低了设计审查规避代理的成本。更重要的是，无状态、短生命周期的无服务器函数可最大限度提升审查规避能力。无服务器函数被调用时会创建安全且相互隔离的执行实例（例如容器） [10, 57]。这些实例具有短暂性（例如在 AWS Lambda 中最长存续 15 分钟  [9]），且新实例启动时会获得新的 IP 地址。这种动态、随机的 IP 地址轮换 [11] 加大了基于 IP 实施封锁的难度。此外，无服务器云原生支持的自动扩缩容和高并发使 CensorLess 能够轻松扩展并服务大量客户端。我们设计了 CensorLess，这是首个利用这些特性的无服务器审查规避系统，能够提供稳健且成本效益极高的审查规避能力。

设计无服务器审查规避代理颇具挑战，因为无服务器云软件栈在很大程度上并不透明。在无服务器平台中，我们只能有限地访问应用层以下各层的信息，因而无法进行套接字通信或捕获 IP 层数据报。禁用套接字通信的影响尤为严重，因为这会妨碍无服务器函数充当代理。无服务器云中另一种网络通信方案需要使用额外的付费云服务（例如 API Gateway、Virtual Networks）。然而，引入额外云服务与我们以最低成本提供审查规避能力的目标相悖。

我们为 CensorLess 设计了三项核心机制，以克服上述挑战：

请求转换、自动生成桥接节点和实时迁移。鉴于低成本是审查规避工具的核心目标，CensorLess 在客户端使用本地代理服务器，以规避套接字通信限制。该代理服务器将互联网流量转换为 HTTPS 请求，使用户在受无服务器函数限制的情况下仍能透明地浏览网站。

为避免基于 DNS 和 TLS SNI 的封锁，CensorLess 会定期停用无服务器函数桥接节点，并在多个地区创建新的函数桥接节点。

为在桥接节点之间迁移连接并确保服务不中断，CensorLess 会无缝转移活动网络连接，并通过当前桥接节点传递迁移信息，以免暴露新的无服务器函数桥接节点。

CensorLess 通过这三项机制轮换桥接节点并利用无服务器函数的短暂性，增强了抵御审查方封锁或过滤的能力。

此外，我们观察到，某些无服务器环境（例如 AWS Lambda）提供域前置能力 [39]，使 HTTPS 请求可以呈现一个获准访问的主机名，实际却抵达另一个后端。我们推测这一能力之所以得以保留，是为了方便客户将无服务器函数与 Amazon CloudFront 等 CDN 服务搭配使用  [50]。由于无服务器函数调用本就源自短暂且广泛分布的 IP，并可经由 CDN 边缘域名访问，域前置可让客户端呈现看似正常的 TLS SNI，而无服务器函数桥接节点则接收真实请求——这实际上把审查规避流量伪装在正常的云流量之中。该设计显著提高了网络审查的附带成本，通过分离对外可见的主机名与后端主机名增强了抗封锁能力，同时避免使用额外的长生命周期基础设施。在支持域前置的无服务器部署中，CensorLess 可选择利用这一能力：本地代理选用看似正常的 TLS SNI，并将流量转发至负责后端路由的无服务器函数桥接节点。

CensorLess 还支持一种隐私保护更严格的模式，即采用虚拟专用服务器（VPS）提供加密通信信道并兼容 SOCKS 代理，且相较 CensorLess 标准模式仅增加很少的成本。当支持 50 个无服务器代理时，私密模式的成本比标准模式增加 20%。在 第 6 节中，我们的评估展示了 CensorLess 无可比拟的成本效益和性能。与最先进的审查规避代理相比，CensorLess 至少节省 97% 的成本（私密模式节省 63.3%），即使扩展至 300 个代理，每日成本仍低于 $3.50。

根据第 6 节中的实验结果，我们为部署无服务器函数桥接节点时维持最低成本提供了运行指南。CensorLess 的贡献概括如下：

• 我们开发了 CensorLess ¹，这是一种利用无服务器计算设计原语、无需额外开销即可最大限度节省成本的审查规避代理。

  1. ¹ 源代码见：https://bitbucket.org/umass-lab/censorless/src/842c2e4458042d210c15f516fdc5fbb902a6f315/↩︎

• 我们基于最受欢迎的无服务器云服务之一 AWS Lambda 实现了 CensorLess，只需进行少量修改即可支持其他无服务器云。

• 我们使用标准基准测试全面评估了 CensorLess 的性能、审查规避效果和相关成本，并将其与最先进的方法进行比较。与此前成本最低的方法 SpotProxy 相比，CensorLess 最多可降低 97% 的成本  [54]。

2. 背景与相关工作

2.1. 网络审查

世界各地的审查方采用了多种技术和设备来检查并过滤网络流量。

网站审查。 世界各地的审查方常常综合运用多种审查技术封锁网站和互联网服务，其中包括但不限于 IP 地址封锁 [19, §4]、DNS 注入 [4, 8, 27, 46]、基于 HTTP Host 的过滤 [72]、基于 TLS (E)SNI 的过滤 [14, 19, 45]、QUIC 流量过滤 [32] 和流量限速 [3, 93]。这些网站审查技术由多个国家的政府实施，包括中国 [15, 35, 45, 94]、伊朗 [13, 58]、俄罗斯 [55, 66, 73, 92]、印度 [52]、土库曼斯坦 [65]等。除了国家层面的实施，审查还已扩展至地区层面，地方政府开始部署自己的过滤系统 [34, 94]。

代理检测。 资源更加充足、能力更强的审查方，包括中国 [2, 90]、伊朗和俄罗斯，还会识别并封锁代理协议和端点，使审查方与网民之间形成猫鼠博弈 [6]。已有记录表明，审查方会针对完全加密的代理 [2, 90]（例如 Shadowsocks [22]、VMess [23] 和 Outline [51]）以及基于 TLS 的代理 [75]（例如 Trojan [82] 和 Tor [28, 33, 87, 88, 89]）。中国、伊朗和俄罗斯都在使用基于被动流量分析的审查技术来识别代理协议 [2, 42, 90]；但已知只有中国还在开发主动探测基础设施及相关技术，以更准确地识别代理服务器 [2, 5, 7, 43]。

2.2. 审查规避

对于互联网访问受限地区的用户而言，规避网络审查仍是一项关键挑战。多年来，随着网络技术与审查技术不断发展，应对这一挑战的方法也层出不穷。本节考察采用不同方法的审查规避工具格局。

基于代理的方法。 基于代理的审查规避工具已被广泛用于对抗审查技术。这些系统将代理服务器 [26, 47] 部署在未受审查的地区，使客户端能够通过这些中间节点访问互联网。VPN [36, 95] 等传统工具虽较易为非技术用户使用，却往往采用静态 IP 地址，容易被审查方识别并封锁。研究人员尝试将代理部署到多种网络环境中，例如互联网服务提供商（ISP） [41]、内容分发网络（CDN） [96] 和边缘网络 [53, 64]，以增强抵御检测的能力。更复杂的方法会利用点对点架构 [37]，例如将普通用户（即志愿者）用作代理的 MassBrowser [64]；又如 Tor [24]，它通过多个节点上的电路式多跳路由提供更强的匿名性。

基于云的审查规避系统。 以往研究利用云服务的独特特性为审查规避工具设计代理。CloudTransport [17] 率先通过加密云存储服务为网络流量建立隧道，利用云基础设施抵御审查。这一方法利用了公共云存储系统所提供的常用加密媒介：无论在审查方控制的网络内外均可访问，因而审查方难以区分审查规避流量与正常的存储访问。

CloudTransport 侧重将云产品用作加密隧道，而 SpotProxy [54] 则直接将 IaaS 虚拟机（VM）用作桥接节点。Kon 等人以竞价实例作为代理，并实现了函数更新组件：反复寻找成本更低的实例、创建新 VM 或更换 IP 地址，再据此迁移代理。

为在这些切换过程中维持连接连续性，他们采用网络地址转换（NAT）技术，在迁移期间临时中继流量。与持续运行的实例相比，SpotProxy 通过使用竞价实例有效降低了成本，但也引入了可观的运行开销，包括反复寻找成本更低的实例、实施两种更新（IP 更新和实例更新）、维护 NAT 基础设施，以及承受新实例较长的配置时间。CensorLess 利用无服务器计算降低运行复杂度，从而消除这些低效之处。

HTTP 代理。 HTTP 代理 [86] 因其简单且兼容标准网页流量，成为审查规避系统中部署最广泛的代理类型之一。这类代理在应用层运行，将客户端的 HTTP 请求中继至目标网站服务器，再返回响应。传统 HTTP 代理运行在具有静态 IP 地址的专用服务器上，容易被审查方发现并封锁。现代审查规避系统通过请求加密、流量混淆等功能增强了 HTTP 代理机制 [67, 68]，以提高抵御检测的能力。HTTP 或 SOCKS 代理尤其易于使用：用户只需在浏览器设置窗口中填入 URL，无需安装专用软件即可访问被封锁的内容。尽管审查方持续采取对策，HTTP 代理仍凭借其灵活性和相对简单的实现方式，成为许多审查规避系统的基础。

CensorLess 以这一代理机制为基础，同时采用无服务器云架构的核心特性来克服其局限，从而提供成本效益更高、韧性更强的 HTTP 审查规避方案。

域前置。 域前置 [39] 是 HTTP 代理机制的一种复杂演进形式，它利用内容分发网络（CDN）规避网络审查。该技术使 HTTPS 请求看起来发往获准访问的域名，实际上却在访问被封锁的内容。域前置的核心机制是在 TLS 层与 HTTP 层使用不同的域名。通常，HTTPS Host 请求头、DNS 查询与 TLS 服务器名称指示（SNI）扩展使用相同的域名。在域前置中，连接在 DNS 查询与 TLS 层的 SNI 中使用相同域名，却在 HTTP Host 请求头中使用另一个域名。这种有意设置的不一致使审查方无法识别真实目的地：他们只能监测 DNS 请求和 TLS SNI 扩展，无法查看加密 HTTP 层中的主机名。前端服务器收到请求后，会根据 HTTP Host 请求头中的主机名，将通信正确路由至隐蔽目的地。

3. 为何使用无服务器计算？

无服务器计算，又称函数即服务（FaaS） [62]，是一种现代云计算范式：请求以事件驱动方式执行，基础设施管理则对开发者透明。无服务器云将资源管理、负载均衡、函数部署和执行的责任从开发者转移给云服务商 [85]。借助这种方法，开发者可以部署根据请求负载自动扩缩容的无状态函数（本文称为无服务器函数，即函数级脚本）。与传统的基础设施即服务（IaaS）模型（例如 Amazon EC2、Google Compute Engine 和 Azure Virtual Machines）不同，用户无需管理底层硬件与软件栈，只需面对高层抽象。Amazon AWS、Google Cloud 和 Microsoft Azure 等主要云服务商均已采用无服务器架构，提供随用随付的定价模式；通常每百万次调用收费约 $0.20，具体价格会因内存分配、存储需求和执行时长而异。由服务商托管资源、细粒度扩缩容、成本效益高和简化开发等优势共同推动，无服务器计算已成为云计算领域日益重要的范式。以往项目已经将无服务器函数用作代理，从简单实现到面向机器学习应用研究的反向代理 [61] 不一而足，但利用无服务器计算构建有效审查规避工具的潜力仍未得到探索。无服务器云的固有特性为审查规避代理的设计同时带来机遇与挑战。本节讨论如何利用无服务器云函数开发低成本审查规避代理 CensorLess，并分析其中的机遇与挑战。

3.1. 无服务器计算的优势

无服务器函数的无状态特性意味着所有资源 ——包括 IP 地址——在设计上都具有短暂性。访问无服务器函数时使用 URL 或基于 REST 的 API 调用，而非直接使用 IP 地址；其底层 IP 地址会以不可预测的方式轮换 [11]。

这从根本上加大了审查方依据 IP 地址跟踪或封锁用户的难度，也降低了受审查地区客户端敏感信息暴露的风险。

无服务器函数的另一项显著特性是采用事件驱动模式。

传统 IaaS 云无论使用情况如何，都会按照租用并运行计算实例的整个时段收费；无服务器平台则只在函数被调用并执行时产生费用。这种事件驱动模型无需维护持续运行的实例，也无需投入精力寻找成本更低的实例。对于将成本视为关键因素的受审查地区用户和审查规避工具提供方而言，这种按请求计价的模式相较传统代理方法具有显著优势。

无服务器平台提供自动扩缩容能力，可根据函数请求量自动调整，并部署事件触发的实例来处理并发请求。这项能力无需人工干预即可灵活应对使用量激增，在高需求期间确保服务持续可用的同时，降低审查规避工具提供方的运行开销。

云服务商通常在全球众多地区提供无服务器函数，使代理能够迅速部署至不同地理位置。这种分布能力可增强抵御地区性封锁的能力，并允许有策略地部署代理，以优化特定受审查地区用户的访问性能。

3.2. 设计挑战

无服务器函数的短暂性虽然为抵御审查带来显著优势，同时也对系统开发与设计施加了重大约束。

• 无服务器软件栈对租户而言在很大程度上并不透明，限制了开发者对函数实例内部（例如容器）的访问。因此，网络可见性仅限于应用层，无法使用套接字连接、数据包捕获、内核级操作等功能。云服务商虽然提供 API Gateway、静态 IP 地址和虚拟网络等附加服务来弥补这些限制，但采用这些服务会削弱无服务器计算的成本优势。因此，构建 CensorLess 的首要挑战是在保持成本效益的同时，仅使用应用层库实现有效的网络通信；这最终促使我们采用 HTTP GET 和 POST 方法，详见第 4.4 节。

• 如果某个无服务器函数近期未被调用，承载该函数的实例就会从部署环境中移除；云平台可能需要先初始化其执行环境，才能处理新的请求，从而引入“冷启动”延迟 [57]。这种延迟可能影响用户体验，尤其会影响时间敏感的浏览活动。

• 无服务器平台对载荷大小施加限制，可能影响代理功能。AWS Lambda 将载荷限制为 6 MB（在特定条件下可扩展至 20 MB） [56]；Google Cloud Functions 将未压缩 HTTP 大小限制为 10 MB（第二代为 32 MB） [21]；Microsoft Azure Functions 的响应大小在技术上没有限制，但实际限值约为 250 MB [44]。这些约束要求系统在处理较大的网页内容时审慎设计。我们在 AWS 环境中实现 CensorLess，并使用 Node.js 将载荷大小上限扩展至 20 MB。

在构建 CensorLess 时，我们采用创新的设计模式，审慎应对上述挑战。据我们所知，CensorLess 是首个利用无服务器云固有的短暂性来实现成本效益与抗审查韧性的审查规避方案。

4. 系统设计

本节介绍 CensorLess 的设计。CensorLess 是一款用于规避网络审查的无服务器代理。

4.1. 设计目标

我们为 CensorLess 制定了以下设计目标：

• 降低成本： CensorLess 仅使用无服务器函数提供代理服务，无需采用云服务商提供的 API Gateway、Virtual Networks 等额外付费服务，以最大限度降低成本。

• 抗审查能力： 为了成为有效的审查规避工具，CensorLess 通过轮换桥接节点，有效抵御基于 IP 地址的流量追踪，以及通过 DNS 和 TLS SNI 实施的封锁。

• 可扩展性： CensorLess 提供强大的并发支持，既能服务个人用户，也能扩展至大型组织，同时保持稳定的性能。

4.2. 威胁模型

  我们假设 CensorLess 客户端位于受审查地区，而充当代理的无服务器函数部署在未受审查的地区。对于 CensorLess 的其他组件，我们作出如下信任假设：运营方不得披露客户端与桥接节点的映射关系，也不得在标准模式下检查或记录流量；私密模式所用的 VPS 必须正确转发流量且不保留日志。审查方能够观察来自客户端的互联网流量；若客户端尝试访问遭审查的网站，审查方可以封锁或干扰其流量。

审查方有能力检查、操纵和封锁流经其管辖范围的网络流量。我们认为系统中的每个参与方都是理性的。审查方独立于云服务商，是一个在实施封锁措施时力求尽量减少附带损害的理性对手。例如，封锁云服务商的整个 IP 地址段或域名会给合法服务造成严重附带损害，因此审查方不太可能这样做。审查方还可以充当 CensorLess 客户端，试图识别桥接节点并破坏服务；他们可能主动探测疑似桥接端点，并尝试枚举各个无服务器函数实例。

我们还假设云服务商会理性行事 [54, 64]，即只要服务用户不会使其面临任何风险，他们就愿意提供服务。例如，云服务商可能会依据粗粒度的安全政策披露加密的网络通信。在现实中，云服务商也可能作出非理性行为，例如迫于法律或经济压力与审查方合谋。我们在第 7 节讨论了这种情况。

我们不假设审查方有能力攻陷终端用户设备（例如安装监控软件），因为这会使任何隐私增强技术都失去意义。尽管审查方可能像俄罗斯那样，利用深度包检测（DPI）识别与审查规避工具相关的流量模式，或封锁整个云服务商，但无服务器函数桥接节点的短暂性给此类识别工作带来了重大挑战。

4.3. 概述

CensorLess 在受审查地区的客户端与其预期目的地之间建立基于无服务器计算的短生命周期桥接节点，从而规避网络审查。如图 1所示，在时刻 t₁，受审查地区的客户端向位于未受审查地区的无服务器函数发送请求。

无服务器函数桥接节点检查请求并充当代理，将流量转发到客户端的预期目的地。目的地将无服务器函数桥接节点视为实际客户端，向其返回数据，再由函数将数据返回给原始客户端。运营方可以是任何愿意支付按调用计费成本的个人或组织；只要能使用云服务，就可以位于任何地区，负责管理无服务器函数桥接节点并协调连接迁移。

经过一段时间到达时刻 t₂ 后，客户端会将桥接节点更换为随机选取的、位于不同未受审查地区的无服务器函数，从而持续混淆审查方所观察到的流量模式。

CensorLess 还提供一个隐私保护组件。私密模式在保护客户端请求隐私的同时，成本效率有所下降。用户可以根据自身偏好与优先级，在 CensorLess 标准模式与私密模式之间选择。当用户选择私密模式时，客户端使用 SOCKS 代理，通过 HTTPS 向无服务器函数桥接节点发送加密消息。随后，无服务器函数桥接节点将消息中继至虚拟专用服务器（VPS），再由 VPS 将加密消息转发至互联网上的目的地。除了发送加密消息并额外将 VPS 作为连接互联网的桥接节点之外，其余流程均与 CensorLess 标准模式相同，包括运营方对无服务器函数桥接节点的管理与桥接节点轮换。

进一步来看，该系统包含三项关键机制，用于解决基于无服务器计算的主要设计挑战，另有四个模块为这些关键机制提供支持。三项关键机制分别是请求转换、自动生成桥接节点和实时连接迁移。我们会将这些机制分为客户端侧与运营方侧流程，并在第 4.4 节和第 4.5 节中详细介绍。私密模式的端到端流程见第 4.6 节。

如图 2所示，我们的系统由四个主要模块组成：控制器、函数刷新器、无服务器函数池和本地代理。控制器与函数刷新器均由运营方管理，两者协同协调无服务器函数桥接节点之间的网络连接迁移。函数刷新器与控制器协同工作，管理无服务器函数桥接节点的生命周期。它定期在不同地区批量生成新的无服务器函数，应用适当的安全配置，并通知控制器这些函数已可用。通过定义无服务器函数桥接节点的规模，它可以调整无服务器函数池的可扩展性。

控制器维护客户端—函数映射数据库，跟踪为每个客户端分配的无服务器函数桥接节点。

控制器更新该数据库时，会为当前无服务器函数标记迁移所需的信息，从而通知客户端其新分配的桥接节点。

无服务器函数池包含多批无服务器函数桥接节点。每个桥接节点都会修改来自客户端的传入请求头，并构造新的传出数据包，使其看起来仿佛无服务器函数桥接节点本身就是客户端。私密模式会解析 HTTPS 载荷，并将其作为完整请求转发。当无服务器函数桥接节点收到客户端目的地返回的响应时，会将响应原样返回客户端。这些无服务器函数仅作为最简桥接节点，因此十分轻量（CensorLess 标准模式的 Docker 镜像为 147 MB）。

本地代理负责大部分请求修改工作，以减少桥接节点的处理开销。本地代理面临的最大障碍是 FaaS 的根本限制。由于 FaaS 不允许函数通过套接字通信，本地代理通过与无服务器函数桥接节点建立应用层连接并进行协议转换来克服这些限制。本地代理由两个组件组成：(1) 转换器，将客户端请求转换为与无服务器函数兼容的 HTTPS，私密模式下则使用 SOCKS 代理；(2) 迁移信息获取器，定期检测新的桥接节点 URL，并无缝切换至这些 URL。

4.4. 客户端侧

客户端通过安装本地代理服务器来启动 CensorLess，该服务器已预先配置初始无服务器函数桥接节点 URL。桥接节点会在后台定期更新。客户端运行本地代理后，网络流量会中继至分配的无服务器函数桥接节点，目标目的地返回的数据则经由该桥接节点送回。为与目标网站进行透明的 HTTPS 通信，本地代理服务器采用了一项关键机制：请求转换。

请求转换。 请求转换解决了无服务器函数的一项根本限制：它们无法支持如今广泛使用的、基于套接字的通信。为克服这一限制，CensorLess 使用本地代理服务器中的两个主要组件转换 HTTP 请求：转换器和迁移信息获取器。

转换器监听指定端口，拦截客户端的 HTTP GET 和 POST 请求，从而避开使用套接字通信的 HTTPS CONNECT 方法，并对请求进行处理，以便安全传输至无服务器函数桥接节点。鉴于标准 HTTP 请求固有的安全漏洞，转换器会将其转换为 HTTPS，同时修改或删除无关的请求头。

转换后的流量随后通过 HTTPS 加密隧道直接转发至分配的无服务器函数桥接节点。在桥接节点处，系统仅对请求作最少修改，以模拟真实端点、重新建立 HTTPS 隧道，并将流量发送至预期目的地。由于无服务器函数存在固有限制，而且系统需要在不使用额外云服务的情况下尽量降低成本，因此系统将通信协议拆分处理。

通过无服务器函数桥接节点收到目的地的响应后，转换器会执行反向转换，将 HTTPS 响应恢复为客户端可用的 HTTP 格式。该过程包括删除不必要的 HTTPS 相关响应头，并在需要时修改响应正文。在私密模式下，系统使用 SOCKS 代理；转换器通过 HTTPS 隧道，将从客户端截获的加密消息发送至无服务器函数桥接节点。此外，本地代理还实现了流式响应和管线化，以提升网络性能。

为增强抵御审查方检测的能力，客户端只与分配给自己的无服务器函数桥接节点通信，而不直接同其他系统组件交互。迁移信息获取器会定期检查当前桥接节点响应中嵌入的迁移标签。检测到新的桥接节点 URL 后，它无需外部组件，也不会引入通信开销，即可无缝迁移连接。这种基于 HTTP 的方法在保持服务连续的同时，让客户端能够透明且即时地完成迁移。

4.5. 运营方侧

为了有效混淆流量模式并提高抵御检测的能力，CensorLess 会定期轮换分布在不同未受审查地区的无服务器函数桥接节点。运营方通过两项关键机制实现这种轮换：自动生成桥接节点和实时迁移。客户端安装本地代理服务器并向 CensorLess 注册，系统由此启动。注册后，运营方从可用池中随机选择下一个无服务器函数桥接节点，将其分配给客户端，并在客户端—函数映射数据库中记录这一分配关系。由此开始持续的桥接节点轮换与管理周期。

自动生成桥接节点。 函数刷新器按照运营方定义的时间周期运行，批量创建新的无服务器函数，并移除已完成运行周期的函数。生成新的无服务器函数桥接节点时，它使用轻量级 Docker 镜像，并应用严格的安全策略，将访问权限限制在运行所需的最低范围内。新桥接节点部署后，函数刷新器通过 HTTP 请求通知控制器，以便随后迁移客户端。客户端从运行周期结束的桥接节点迁出后，函数刷新器会自动移除这些弃用函数，确保任何桥接节点都不会保持活动状态太久，以免被审查方识别并锁定。根据 Fifield 等人 [40]的报告，预计桥接节点在实际中被识别需 2 天；中国境内的 Tor 桥接节点会在 2-36 天内被发现。

实时迁移。 控制器通过管理客户端—函数映射数据库来协调迁移。收到函数刷新器发来的新桥接节点可用通知后，控制器会更新映射数据库，移除旧的桥接节点分配，并为客户端分配新节点。这一更新会触发迁移过程。针对无服务器函数的无状态特性，控制器实现了一种基于标签的迁移机制。控制器不会直接向客户端传达迁移指令，而是将新分配桥接节点的 URL 附加为标签。客户端的迁移信息获取器会检测这些标签，从而无缝切换至新桥接节点。客户端完成迁移后，函数刷新器会自动移除旧桥接节点。在整个过程中，控制器与客户端之间只保持最低限度的通信，主要同无服务器函数桥接节点交互。这一设计简化了迁移过程，并减少了可被检测到的通信模式。基于 HTTP 的实现无需复杂的协议或流程，即可高效完成实时迁移。通过这些相互协调的客户端侧与运营方侧机制，CensorLess 在定期改变网络路径的同时保持服务连续，有效规避基于 SNI 的网络审查。

4.6. CensorLess 的隐私保护

  CensorLess 以最低成本提供可规避审查的公共互联网连接。然而，恶意云服务商可能访问无服务器函数桥接节点处的数据。因此，我们为 CensorLess 提出一种保护隐私的私密模式，但它需要在成本及性能与隐私及匿名性之间作出权衡。我们在第 6.3 节比较了这种权衡所产生的额外成本。该模式可以防止无服务器函数桥接节点处的恶意运营方侵犯客户端隐私，但 VPS 处的恶意运营方仍可能分析入站和出站流量模式。我们在第 7 节讨论了这一局限。

隐私保护模块部署一台虚拟专用服务器（VPS），以支持 SOCKS 协议、长连接和消息加密，这会增加运行成本。如图 1所示，VPS 位于未受审查地区，在无服务器函数桥接节点之后、目标目的地之前。与 CensorLess 标准模式一样，客户端与无服务器函数桥接节点之间使用 HTTPS 连接，而无服务器函数桥接节点与 VPS 服务器之间则使用 TCP 通信。

加密模型。 为通过加密保护消息中的数据，客户端和 VPS 服务器各自拥有一对公钥和私钥（C_pr, C_pub, S_pr, S_pub），并在运营方协调的引导步骤中交换公钥。当客户端向服务器发送一条包含发往目的地的加密载荷（E(m)）的消息时，客户端使用服务器的公钥加密该消息（c_req ← E(S_pub,E(m))），并将其作为 HTTPS 载荷，经由无服务器函数桥接节点发送至服务器。服务器使用自己的私钥解密消息（E(m) ← D(S_pr,c_req)），并验证消息中包含的递增一次性数。服务器向目标目的地发送请求时，会分配连接 ID （ConnID），并使用服务器的私钥为其签名（DS ← Sign(S_pr,ConnID)）。服务器从目标目的地收到加密响应（E(r)）后，会将已签名的连接 ID 附加至加密响应，再使用客户端的公钥加密整条消息（c_res ← E(C_pub,DS|E(r))）。最后，客户端使用自己的私钥解密服务器的消息（E(r) ← D(C_pr,c_res)），从而收到响应。

该加密模型维持了四项安全属性。我们使用 Ed25519 [31] 公钥签名系统进行加密，客户端与服务器通过带外配置的 Ed25519 公钥相互认证。为防止重放攻击，我们采用单调递增的一次性数。已签名的连接 ID 可证明客户端拥有该连接，所有加密载荷则保证机密性。私密模式安全属性的形式化证明留待未来工作完成。

端到端通信。 发起通信的客户端是一个 SOCKS 代理。为符合无服务器函数的限制，它会像 CensorLess 标准模式一样，将消息嵌入 HTTPS 载荷，再转发至无服务器函数桥接节点。该请求（即客户端发送的 HTTPS 载荷）包含 SOCKS 地址格式的 VPS 服务器地址，用以同服务器建立连接；请求还包含使用服务器公钥加密的载荷。无服务器函数桥接节点收到客户端发来的 HTTPS 请求后，会与 VPS 服务器建立 TCP 连接，并解析 HTTPS 载荷，将其作为消息转发。服务器收到桥接节点发来的 TCP 段后，使用自己的私钥解密载荷，并针对所收到的公钥验证递增的一次性数。接着，服务器会建立 TCP 连接，或通过无服务器函数桥接节点的连接在客户端与目标目的地之间传递数据。服务器会按公钥识别各个客户端，并为其缓冲响应，直到客户端再次调用无服务器函数桥接节点来请求这些响应。系统使用超时和最大缓冲区大小来控制并清理已缓冲的响应。

服务器收到目标目的地的响应后，会使用客户端的公钥加密响应，并通过 TCP 连接将其发回无服务器函数桥接节点。无服务器函数桥接节点将 TCP 段置于 HTTPS 载荷中，并通过 HTTPS 发送请求。随后，客户端解析载荷，使用自己的私钥解密来自目标目的地的实际响应。最后，客户端可以将数据路由至 SOCKS 通信通道。

4.7. CensorLess 中的域前置

为增强审查规避能力，CensorLess 可以选择利用某些无服务器平台支持的域前置技术。

域前置利用通信协议不同层之间的差异来隐藏 HTTPS 流量的真实目的地 [39]。

包括 AWS、Google 和 Microsoft 在内的主要 CDN 已不再支持域前置。这在很大程度上是为了维持其与实施审查国家的商业关系 [16, 38, 60, 77, 79]。

不过，我们发现 AWS Lambda 仍然支持域前置。我们在 Microsoft Azure 函数上测试了域前置，但它不允许 SNI 与 Host 不匹配。CensorLess 额外提供通过域前置建立连接的选项；利用审查方封锁无服务器函数需要付出高昂成本这一事实，我们增强了 CensorLess 的抗审查能力。

机制。 CensorLess 对传统域前置加以调整，使其适用于无服务器环境。在这种方法中，客户端连接到获准访问的云域名（例如 AWS Lambda 的 *.lambda-url.*.on.aws），并发送一个加密的 HTTPS 请求，其中使用另一个 Host 请求头来表示遭审查的目的地。

该过程包括：(1) 在本地与目标目的地域名建立连接；(2) 在加密通道内，将 HTTP Host 请求头设为特定的无服务器函数桥接节点；(3) 利用云服务商的内容分发基础设施将请求正确路由。本地代理服务器会选择 TLS SNI 值，确保域前置请求在网络审查系统和云服务商基础设施看来都合理合法。该子域名可以与同一地区其他无服务器函数所用的子域名相同，甚至可以是一个完全虚构、未向 AWS 注册的子域名。

这种实现格外有效，因为审查方面临两难选择——封锁所有通往主要云服务商的流量，会对合法服务和应用造成严重的附带损害。

此外，无服务器端点的短暂性又进一步加大了过滤难度。

无服务器计算带来的韧性提升。 传统域前置实现依赖一组数量有限的前置域名 [39]，与之不同，CensorLess 可以将请求分散到大量无服务器函数上；这些函数部署在云服务商域名空间内不同的地区和命名空间中。这种分散方式显著提高了全面封锁的成本。

即使 AWS Lambda 决定禁用域前置，不使用域前置的 CensorLess 仍可在多个地区之间动态选择无服务器函数域名，从而保持抵御识别和过滤的能力。此外，CensorLess 允许运营方自定义域名选择间隔，增强系统抵御网络审查的稳健性。在 CensorLess 的抗审查机制中加入域前置，可以避免真实前端暴露，并提高封锁系统的成本，从而带来更强的抗封锁能力。

5. 实现

我们实现了 CensorLess，以验证设计并展示其实用性。我们的实现包含约 2,000 行代码，使用 TypeScript、Node.js 和 Python 编写。由于 AWS 应用广泛，我们主要以它为部署平台；不过，该架构的设计不依赖特定云服务商，只需对无服务器函数管理组件进行少量修改，即可部署到其他云服务商。

我们的实现采用了多项技术优化，以尽量减少延迟与开销。我们实现了带请求管线化的 HTTP 流式响应，从而降低延迟并提高吞吐量，对网页浏览应用尤其有效。通过在本地代理与无服务器函数桥接节点之间分配处理职责，我们将无服务器函数层的计算开销降至最低，因为该层的执行时间会影响成本。

无服务器函数桥接节点。 无服务器函数桥接节点是我们审查规避系统的核心。实现该组件时，我们格外注重尽量减少资源消耗和执行时间。桥接节点使用 Node.js 开发，代码库不到 100 行，并被容器化为 146.7 MB 的 Docker 镜像，以便快速部署。我们将依赖项限制为 4 个外部库：axios、https、stream 和 aws-sdk；同时仅实现最低限度的请求处理逻辑，以保持高效。桥接节点还集成了用于协调迁移的标签机制，在单个函数中分别处理标签请求和常规 HTTP 流量。

为确保安全，每个无服务器函数桥接节点均遵循最小权限原则运行。安全策略只授予运行所必需的 AWS 权限：Amazon Resource Group Tagging API:TagResources 和 GetTagValues ²、Elastic Container Registry:GetRepositoryPolicy ³，以及 Lambda:InvokeFunctionUrl、CreateFunction 和 ListFunctions ⁴。这组受限权限在保留完整功能的同时，尽量减少了潜在的安全漏洞。

函数刷新器使用 Docker 镜像创建新的无服务器函数，将函数部署到不同地理区域，为每个新建函数应用安全策略，并使用 AWS Software Development Kit boto3，在桥接节点完成使用周期后移除过期节点。只有拥有无服务器函数池的运营方才能访问无服务器函数桥接节点并使用 boto3。

本地代理服务器。 客户端通过运行以 TypeScript 实现的本地代理服务器应用（代码不到 400 行）与系统交互。本地代理服务器处理来自用户指定端口的请求头，将 HTTP 请求转换为 HTTPS，从而克服无服务器平台的限制。它必须接受以下请求头名称：’Cookie’、’User-Agent’、’Host’、’Content-Type’、’Permission-Policy’、’Accept’、’Accept-Encoding’ 和 ’Accept-Language’。如果请求中包含 ’Strict-Transport-Security’ 请求头，本地代理会将其值改为 ’max-age=0’；如果 ’Referer’ 或 ’Origin’ 请求头包含 ’http:’，则将其替换为 ’https:’。接受必要的请求头后，本地代理将 Host 重新定义为无服务器函数桥接节点，并添加一个名为 ’target-url’ 的新请求头，用于指示真实目的地。最后，本地代理使用重新组装的请求头，向无服务器函数桥接节点发送 HTTPS 请求。采用域前置时，它会向一个子域名发送请求，并在请求中使用真实无服务器函数桥接节点的 Host 请求头。本地代理收到无服务器函数桥接节点的响应后，会过滤可接受的请求头以保持呈现给用户的一致性，并以管线化方式流式传输数据。如果数据中包含 ’https:’，本地代理会将该字符串替换为 ’http:’。

私密模式协议。 由于私密模式会与 VPS 服务器建立连接并使用 SOCKS 代理，因此需要为 HTTPS 请求载荷定义一种协议。HTTPS 载荷是与 VPS 服务器通信的消息，其中包括 SOCKS 地址格式的 VPS 服务器地址、服务器端口、载荷长度和加密载荷。加密载荷由客户端公钥、防止重放攻击的一次性数和消息组成。VPS 服务器会解释消息，消息可分为若干类型。“开始连接”消息包含目标地址和目标端口。“数据”消息包含已签名的连接 ID、指示数据是否压缩的压缩标志、原始数据长度、压缩后长度和数据。长度为 0 的数据消息被视为“保活”消息。“关闭连接”消息仅包含一个签名。

对于 VPS 服务器发往客户端、使用客户端公钥加密的响应消息，它同样遵循规定的消息结构。“建立连接”消息携带类型和连接 ID。“数据响应”消息包含类型、连接 ID、压缩标志、原始数据长度、实际长度和数据；“关闭连接”消息包含类型、连接 ID、消息长度和消息。如果发生错误，消息会传达类型、连接 ID、错误码、消息长度和消息。

此外，VPS 会过滤私有 IP 地址段，以防止服务器端请求伪造（SSRF）攻击。对环回地址段、私有网络、链路本地地址、多播、广播、文档专用地址段和未指定地址段中地址的连接尝试，均会被拒绝并返回错误码。

6. 评估

本节说明 CensorLess 能够在保持合理性能和低成本的同时实现有效的审查规避。我们从四个关键维度评估这一基于无服务器计算的审查规避系统：系统性能、无服务器函数作为桥接节点时的性能、运行成本和审查规避效果。

6.1. CensorLess 性能

为了评估系统能力，我们使用 Selenium 脚本保证一致性，在单用户条件下针对不同内容加载场景测量吞吐量：从包含大量对象的网页阅读文章、下载 PDF，以及通过实际浏览与交互播放流媒体视频（点击、下载和观看视频）。我们比较了不使用 CensorLess、标准模式下采用静态无服务器函数桥接节点、单个客户端每 20 秒迁移一次桥接节点，以及私密模式下采用静态无服务器函数桥接节点时的系统性能。实际使用中，迁移周期可设为长于 20 秒，与观察到的封锁周期一致（见第 6.4 节）。图 3表明，从总执行时间来看，无论是否迁移，CensorLess 标准模式都比不使用代理和私密模式耗时更长；不过，由于需要建立安全连接，私密模式在收到第一个响应前需要更长时间。这些用例及 CensorLess 各模式的加载时间瀑布图见附录 A.1。尽管 CensorLess 标准模式的请求会经由无服务器函数桥接节点路由，但其吞吐量模式与不使用代理时非常接近，开销可以忽略且没有显著性能损失，代价则是牺牲隐私。即使系统没有主动加载内容，私密模式也会通过轮询产生持续流量，以维持 SOCKS 通信信道。对比迁移和非迁移场景，吞吐量模式没有显著差异，迁移期间的总执行时间仅略有增加。由于系统通过 HTTPS 与无服务器函数桥接节点通信，连接迁移无需耗费太多时间或处理步骤，因此有无迁移在三种场景中都呈现相似模式。

6.2. 无服务器函数桥接节点性能

系统性能与无服务器函数配置直接相关。我们评估了三个关键配置参数：超时时间、内存大小和临时存储大小。对所有实验而言，将超时时间设为 15 秒效果最佳，因为更短的超时时间无法正确加载流媒体内容，而更长的超时时间并未带来显著的性能收益。同样，在内存分配保持不变时，临时存储大小影响的是临时存储容量而非性能。

不过，内存分配会影响执行时间。我们采用不同的无服务器函数内存配置，重复执行相同任务（浏览搜索引擎、浏览新闻网站，以及观看一段流式短视频，每项任务重复三次）来测量吞吐量。评估期间，我们改变内存分配，同时保持其他所有配置不变（例如，15 秒超时时间和 512 MB 默认存储大小）。如图 4所示，执行相同任务时，内存分配较大的无服务器函数（512 MB）比内存分配较小的函数（128 MB、256 MB）总执行时间更短。这是因为较大的内存分配使无服务器函数能够同时存储和处理更多数据。不过，在实际使用中，采用 15 秒超时时间、512 MB 默认存储大小和 128 MB 默认内存大小的无服务器函数桥接节点已经足够，不会造成可察觉的性能和可用性下降。

FaaS 的一大优势是通过自动扩缩容实现并发。借助并发与自动扩缩容，无服务器函数能够提供稳定的服务，CensorLess 也不例外。我们根据以往实验日志，通过分析平均持续时间和成功率这两个并发指标，评估单个无服务器函数桥接节点在集中请求负载下的系统可靠性。

如图 5所示，在初始阶段（约 0-50 次调用），两个指标均出现明显波动。部分函数的平均持续时间会飙升至 6000 ms 以上，成功率则偶尔降至 90% 以下。这种初始不稳定源于无服务器环境中常见的冷启动现象：新迁移到的桥接节点在首次调用时，需要额外时间初始化和部署容器。在 100-200 次调用之间，系统明显趋于稳定，平均持续时间始终低于 1000 ms，成功率则高于 95%。这表明 FaaS 平台的自动扩缩容能力可以动态分配资源来处理不断增加的负载，确实行之有效。尽管突发负载可能偶尔出现，但 CensorLess 在 AWS Lambda 上实现的无服务器函数桥接节点默认即使面对 1000 次并发调用，也能提供稳定服务 [57]。这种固有的可扩展性使 CensorLess 在高负载下仍然可靠。

6.3. 运行成本

成本效益是本系统的最高优先事项。

我们将每月运行成本与现有低成本审查规避工具 SpotProxy [54] 和 MassBrowser [64] 进行比较。SpotProxy 给出了三种使用竞价实例的场景：使用最便宜的单网卡竞价实例、使用多网卡竞价实例（其假设使用 3 个网卡，成本约为单网卡的三分之一），以及使用静态竞价实例。与要求运营方维护持久 VM 的 MassBrowser 不同，SpotProxy 和 CensorLess 的成本都主要来自对云服务的依赖：SpotProxy 按使用时间计费，而 CensorLess 按请求量计费。

为保证比较一致，我们沿用 SpotProxy 的成本分析假设 [54, §11.1]，即每个代理每月处理 6.76 GB 流量。随后，我们依据各系统公布的成本分析方法和定价模型比较费用 [12]。

对于本系统，我们依据 AWS Lambda 的实际账单计算成本，每个请求使用 0.00296 MB。6.76 GB 流量约产生 2,338,885 个请求（6.76 GB / (0.00296 MB/请求) = 2,338,885.14 个请求）；AWS Lambda 每百万次请求收费 $0.20，并且每月提供 1 百万次免费请求，因此每月成本仅为 $0.27（持续时间 1000 ms、内存 128 MB、存储 512 MB）。

由于本系统的私密模式还会使用 VPS（AWS 中的 EC2），我们采用了 t4g.micro EC2 实例（2 个 CPU 和 1 GB 内存）。根据 AWS Pricing Calculator，采用 EC2 Instance Savings Plans 时，VPS 成本为 $3.14。因此，私密模式的每月总成本为 $3.41（$0.27 + $3.14）。如图 6所示，本方案展现出卓越的成本效益，其成本仅为 SpotProxy 最经济的多网卡配置的 1/34.4（节省 97.1%）；即使是成本最高的私密模式，成本也仅为该配置的 1/2.72（节省 63.3%）。

我们以 SpotProxy 为基准评估了本系统的成本可扩展性。我们假设每个代理在一小时内依次每秒处理一个请求，这与 SpotProxy 的成本分析场景类似 [54, §11.1]。SpotProxy 使用的竞价实例为 m6g.large，这是能够运行 SpotProxy 程序的最便宜实例（竞价 VM 的每小时价格为 $0.0383）。SpotProxy 按实例使用小时数收费，而本系统按请求数量收费。代理实例数和请求数以恒定速率增加。对于私密模式，单个 VPS 还会产生额外费用（t4g.micro 每小时费用为 $0.004）。私密模式仅使用一个代理提供服务时，单个请求可能较慢。运营方可增加 VPS 实例来缓解速度下降，但费用也会随之增加。图 7显示，即使扩展到 300 个代理，本系统的成本仍低于 $3.50。这表明，利用 FaaS 比使用最便宜的 IaaS 服务更具成本效益。即使采用私密模式，增加 VPS 实例以提升速度或增强隐私时，成本仍低于 IaaS 服务，而且只会缓慢地小幅线性增长（见附录 A.2）。

6.4. 审查规避效果

6.4.1. 模拟

我们评估了 URL 刷新方法的审查规避效果，采用的是 Nasr 等人提出的、用于审查规避的先进博弈论模拟框架  [63]。该模拟器采用三种效用函数：客户端效用函数（U_ai^t(p_x)）、代理效用函数（U_px^t(a_i)）和审查方效用函数（U_C^t)），分别对应客户端 a_i、代理 p_x 和审查方 C。客户端效用函数（公式（1））是以下代理重要性因素的加权和：知道该代理的用户数（B_px^t）、连接到该代理的用户数（c_px^t）、代理的累计使用时间 τ_px^t，以及客户端位置（d_ai, px）。β₁、β₂、β₃ 和 β₄ 是设定各代理指标相对重要性的缩放因子；在评估中，我们将所有缩放因子均设为 1。

代理效用函数（公式（2））是客户端指标的加权和，其指标包括代理使用时间（T_ai）、请求新代理地址的次数（R_ai^t）、分配到的已封锁代理数量（γ_ai^t）、用户所知的已封锁代理数量（δ_ai^t）和客户端位置（d_ai, px），目标是分配尽可能多、未被封锁且存续时间长的代理。我们将缩放因子 α₁、α₂、α₃、α₄ 和 α₅ 分别设为 2、1、1、2 和 10。

审查方效用函数（公式（3））在代理发现能力与封锁影响这两个相互竞争的目标之间作出权衡。

∑_ai ∈ JU_C^t(a_i) 表示所有审查代理 J 的总体代理发现能力，r_Blocked 表示无法获得可用代理的受审查客户端所占比例，ω 是体现审查方策略偏好的权重因子。审查代理 a_i 的效用 U_C^t(a_i)，是各代理对 a_i 评分的平均值（即 𝔼_px ∈ P[U_px^t(a_i)]）。在实现中，我们沿用 SpotProxy 的封锁能力设定，即审查方在发现代理 2 个时间单位后将其封锁。

我们对这些效用函数的实现作了少量调整，因为我们的客户端获分配的是无服务器函数桥接节点 URL，而该模拟器根据 IP 地址向客户端分发代理。考虑到基于 SNI 的封锁，我们假设每个无服务器函数桥接节点对应一个 IP 地址，且被封锁的 URL 不能再次使用。因此，我们的封锁机制与基于 IP 的封锁完全相同。为实现基于 URL 的代理分配，我们遵循无服务器函数的 URL 生成规则；尤其是在 AWS Lambda 中，唯一 URL 是由字母与数字随机混合而成的定长字符串。

我们以连接用户比例和未封锁代理比例为指标，针对最优审查方评估系统的审查规避效果。最优审查方采用最优博弈论方法作为审查策略，例如调整发现新代理前的等待时间，以及封锁工作的频率或强度，以实现最大审查效果，力求发现更多代理并封锁更多客户端。我们将 50% 的客户端设为审查代理，并比较刷新周期等于或两倍于封锁周期的场景。所有超参数与配置均采用 SpotProxy 在评估中使用的优化值 [54, §8]；审查规避效果的对比见附录 A.3.1。

面对最优博弈论审查方（图 8），即使刷新频率较低，本系统在客户端和代理两个维度上都表现出更稳定、更高的连接率。为最大限度提高可靠性，我们建议迁移周期至少与预期审查周期一样频繁。

6.4.2. 在受审查地区

我们通过实验检验 CensorLess 如何在中国南京这一真实受审查地区成功规避审查。为测试域名封锁，我们从 Sheffey 等人开展的 5,000 个域名 DNS A 记录实验中，收集了 500 个在中国大陆被封锁的域名 [76]。测试的被封锁域名包括搜索引擎、AI 工具、社交媒体、新闻、娱乐、内容分享、色情内容等类型的网站。中国现行的审查模式会持续阻止用户接收这些网站的内容。我们使用 curl 命令向每个域名发送 2 个请求，并测量网站是返回 HTTP 状态码，还是在 100 秒内没有响应。为明确区分遭审查与响应延迟，我们将 100 秒内没有响应的网站视为遭审查（状态码通常会在 15 秒内返回）。若在 100 秒内收到响应，我们便向下一个域名发送请求。表 1列出了 10 个网站的结果，50 个网站的结果见附录 A.3，完整结果则收录于研究工件中。如表 1所示，CensorLess 标准模式与私密模式对发往被封锁域名的每个请求都收到了响应（私密模式访问 tubegays.xxx 失败；原因见附录 A.3：该网站的策略拒绝来自 AWS VPS 的请求）。

本实验在有限条件下开展：出于伦理原因，CensorLess 客户端部署在中国南京 Alibaba Cloud 网络的自治系统号（ASN）AS45090 内，而非住宅网络中。在地区内持续超过 36 小时的测试期间，我们使用了 50 个不同的无服务器函数，系统未遭到封锁。

7. 安全性讨论与局限性

本节讨论针对 CensorLess 的潜在攻击场景及相应防御措施。

HSTS 预加载。 无服务器计算是 CensorLess 设计的核心，而无服务器计算的一项固有限制是服务提供商不允许套接字通信。因此，CensorLess 标准模式依赖于在本地截获 HTTP 请求并将其转换为 HTTPS。面对采用 HTTP 严格传输安全（HSTS） [25] 的现代网站时，这种方法会遇到问题。浏览器维护 HSTS 预加载列表，在发生任何网络通信之前，自动将面向指定域名的 HTTP 请求重定向至 HTTPS。客户端的这种强制机制使 CensorLess 无法通过本地代理捕获这些请求，因而无法访问 HSTS 预加载列表中的网站。

HSTS 预加载问题有两种解决方案。第一种是让客户端使用 CensorLess 私密模式，但这会牺牲标准模式的成本优势。由于私密模式的本地代理使用 SOCKS 代理并与 VPS 建立 TCP 连接，客户端不会遇到浏览器从 HTTP 到 HTTPS 的强制重定向。第二种是使用不含 HSTS 预加载列表的早期版本浏览器访问网站。

我们于 2025 年 4 月上旬开展实验时，所有网站均可在 Firefox 中访问，未出现 HSTS 预加载问题。

作为非理性行为者的云服务提供商。 在第 4.2 节中，我们假设云服务提供商会理性行事，并避免采取会给其客户造成大范围附带损害的措施。不过，我们承认，服务提供商也可能与审查方串通，采取基于目的地的封锁，或通过流量模式与运营方行为模式分析进行检测等对策。由于无服务器函数通常会调用互联网上的第三方 API 或充当网络爬虫，监控目标目的地（即通往公共互联网的方向）无法有效区分 CensorLess 流量与其他流量。采用私密模式并部署多个无服务器函数桥接节点，可以防范基于流量分析的封锁。尽管审查方可能通过检测运营方的行为模式（例如反复创建函数）来限制 CensorLess，但可通过改变无服务器函数桥接节点的创建周期并采用当前桥接节点的 URL 更新来缓解这一威胁。事实上，针对 CensorLess 的激进封锁也会干扰其他基于云的审查规避工具（例如 Shadowsocks [22]、V2Ray [83]）和大量正常服务，从而给服务提供商带来强烈的经济与声誉阻力。基于这些原因，我们在模型中将服务提供商视为理性行为者。此外，CensorLess 依据 Amazon Web Services（AWS）公开文档所述的无服务器功能进行设计与实现。

协议支持与 HTTPS 解封装。 由于无服务器函数对 WebSocket 通信的限制，CensorLess 标准模式仅支持 HTTPS GET 和 POST 方法，尽管 WebSocket 连接在现代互联网中已得到广泛应用。因此，CensorLess 在无服务器函数桥接节点处对 HTTPS 请求进行解封装。私密模式以略微增加运行成本为代价缓解了这些限制。在私密模式中，我们没有采用 HTTP CONNECT 和 MASQUE 等标准化方案，而是使用自定义代理协议，使其能够跨无服务器函数桥接节点的多次调用持续跟踪连接状态；这一设计利用了无服务器函数仅通过 HTTP 接收流量，并可在合理的时间与数据量范围内流式传输响应这一事实。

流量分析攻击。 审查方可以通过修改后的请求头或流量模式分析 HTTP 模式，但发送至无服务器函数的请求头由用户定义且可变。除非云服务提供商检查载荷，否则很难识别 CensorLess 流量；采用私密模式的 CensorLess 通过加密防止载荷暴露。由于无服务器函数被广泛用作网站域名或网络爬虫，CensorLess 流量不存在独有模式。无服务器函数还会共享公共 IP 地址，因此基于 IP 的封锁对审查方而言同样困难。未来工作将探索抵抗指纹识别的技术，例如对 User-Agent 进行标准化 [49]。

通过域名过滤实施封锁。 审查方可依据无服务器函数特有的域名模式实施过滤。例如，AWS Lambda 函数 URL 含有对应特定用途的特征字符串，可被用于整体封锁。然而，无服务器函数广泛、合法地应用于商业场景，如此宽泛的过滤会造成严重的附带损害，因此在实践中采取这种做法的可能性较低。如果出现此类过滤，基于 HTTPS 的 DNS（DoH） [18] 等技术可通过 HTTPS 加密会话来加密 DNS 查询，从而提供额外的混淆层。

DoS 攻击。 攻击者可能利用无服务器函数按请求量计费的即用即付定价模式，发送大量连接请求以耗尽资金。这类拒绝服务（DoS）攻击是无服务器环境中的已知风险，云服务提供商会以限制调用速率作为对策。在服务层面，我们通过在用户注册前增加客户端身份验证步骤来缓解 DoS 攻击。

冷启动攻击。 无服务器函数在配置新的执行环境时会经历冷启动 [78, 84]，这会引入延迟并消耗额外资源。恶意行为者可协调分布式机器人同时触发大量冷启动，借此降低性能并可能推高成本。正如 Ahmadi 等人所指出的，缓解此类攻击需要在冷启动阶段限制外部访问，以提高可靠性 [1]。我们的设计通过尽量减小函数代码规模和采用函数刷新机制，在一定程度上抵御了这种攻击，但仍易受复杂分布式攻击的影响。

8. 未来工作

该领域的未来工作可以探索若干很有前景的方向。可以研究性能优化方法，以改善 CensorLess 在不同网络条件下的响应能力，包括审查地区中常见的高延迟或拥塞网络。进一步研究还可探索自适应桥接节点分配策略，以动态响应网络审查模式和强度的变化。通过收集并分析连接失败和成功实现审查规避的实时数据，CensorLess 可以在不同地区和服务提供商之间智能分配流量，在最大化可用性的同时尽量降低成本。

由于 CensorLess 采用请求—响应模型，因此可以与其他反审查生态系统集成。例如，它可以支持 Tor 网桥或 Shadowsocks 机场 [20] 的分发，充当进入匿名网络的轻量级入口；也可以促进 Tor Browser [70]、Psiphon [71]、Lantern [59] 等最新审查规避工具二进制文件的安全分发。

9. 结论

本文提出 CensorLess，这是一种基于无服务器计算的新型审查规避系统，继承了无服务器计算的优势。我们的方法优先考虑成本效益、抗审查能力与性能，从而应对现有审查规避代理面临的根本性挑战。

CensorLess 表明，与传统的云端方案相比，无服务器函数能为审查规避带来显著优势。利用无服务器计算的短暂存续特性，我们的系统可以在不同地区快速部署并轮换桥接节点，使审查方难以通过 IP 地址和域名识别并封锁这些节点。

无服务器函数的无状态设计使桥接节点之间能够无缝迁移而不中断服务，从而为审查地区的用户提供持续连接。此外，我们还提供了 CensorLess 私密模式，支持基于 SOCKS 的隧道，但需在成本与隐私之间作出权衡。值得注意的是，凭借无服务器计算按请求数量计费的即用即付模式，CensorLess 可以节省 97% 的成本。

10. 伦理考量

在审查地区对 CensorLess 进行真实世界部署评估时，我们向已知被封锁的网站发送了多次请求。整个实验过程均遵守伦理规范。为尽量降低风险，测量通过一台由我们控制的 Alibaba Cloud 服务器完成，未使用个人设备或住宅网络连接。为减轻可能给云服务提供商造成的影响，请求仅限于检查响应状态的非交互式 curl 探测。因此，评估期间没有任何参与者面临风险。

CensorLess 标准模式在无服务器函数桥接节点处重新组装 HTTPS 数据包，从而在用户与桥接节点运营方之间形成信任关系，而后者在技术上能够访问用户流量。我们明确承认这一局限，并提供一种使用加密信道的隐私保护模式，但其成本更高。由于 CensorLess 向公众开放，用户需要仔细评估运营方是否值得信任。我们建议将无服务器函数桥接节点用于个人用途，或由实行严格无日志政策的可信组织运营。

致谢

本研究部分获得美国国家科学基金会（NSF）项目 CNS-2333965，以及美国国防高级研究计划局（DARPA）青年教师奖计划项目 DARPA-RA-21-03-09-YFA9-FP003 的资助。本文所表达的观点、意见和/或研究结果均属于作者本人，不应被解读为代表美国国防部或美国政府的官方观点或政策。

参考文献

1. Sina Ahmadi. 2024. Challenges and solutions in network security for serverless computing. International Journal of Current Science Research and Review 7, 01 (2024), 218–229.
2. Alice, Bob, Carol, Jan Beznazwy, and Amir Houmansadr. 2020. How China detects and blocks Shadowsocks. In Internet measurement conference, 2020. ACM. Retrieved from https://censorbib.nymity.ch/pdf/Alice2020a.pdf
3. Collin Anderson. 2013. Dimming the Internet: Detecting throttling as a mechanism of censorship in Iran. University of Pennsylvania. Retrieved from https://arxiv.org/pdf/1306.4361v1.pdf
4. Anonymous. 2014. Towards a comprehensive picture of the Great Firewall’s DNS censorship. In Free and open communications on the internet, 2014. USENIX. Retrieved from https://www.usenix.org/system/files/conference/foci14/foci14-anonymous.pdf
5. Anonymous. 2021. How to Deploy a Censorship Resistant Shadowsocks-libev Server. Retrieved from https://gfw.report/blog/ss_tutorial/en/
6. Anonymous and Amonymous. 2022. Sharing a modified Shadowsocks as well as our thoughts on the cat-and-mouse game. Retrieved from https://github.com/net4people/bbs/issues/136
7. Anonymous, Anonymous, Anonymous, David Fifield, and Amir Houmansadr. 2021. A practical guide to defend against the GFW’s latest active probing. Retrieved from https://github.com/net4people/bbs/issues/58
8. Anonymous, Arian Akhavan Niaki, Nguyen Phong Hoang, Phillipa Gill, and Amir Houmansadr. 2020. Triplet censors: Demystifying Great Firewall’s DNS censorship behavior. In Free and open communications on the internet, 2020. USENIX. Retrieved from https://www.usenix.org/system/files/foci20-paper-anonymous_0.pdf
9. AWS. 2025. Configure Lambda function timeout - AWS Lambda — docs.aws.amazon.com. Retrieved from https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html
10. AWS. 2025. What is AWS Lambda? - AWS Lambda — docs.aws.amazon.com. Retrieved from https://docs.aws.amazon.com/lambda/latest/dg/welcome.html
11. AWS. 2025. Generate a static outbound IP address using a Lambda function, Amazon VPC, and a serverless architecture - AWS Prescriptive Guidance — docs.aws.amazon.com. Retrieved from https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/generate-a-static-outbound-ip-address-using-a-lambda-function-amazon-vpc-and-a-serverless-architecture.html
12. AWS. 2025. AWS Pricing Calculator — calculator.aws.
13. Kevin Bock, Yair Fax, Kyle Reese, Jasraj Singh, and Dave Levin. 2020. Detecting and evading censorship-in-depth: A case study of Iran’s protocol filter. In Free and open communications on the internet, 2020. USENIX. Retrieved from https://www.usenix.org/system/files/foci20-paper-bock.pdf
14. Kevin Bock, iyouport, Anonymous, Louis-Henri Merino, David Fifield, Amir Houmansadr, and Dave Levin. 2020. Exposing and circumventing China’s censorship of ESNI. Retrieved from https://github.com/net4people/bbs/issues/43\#issuecomment-673322409
15. Kevin Bock, Gabriel Naval, Kyle Reese, and Dave Levin. 2021. Even censors have a backup: Examining China’s double HTTPS censorship middleboxes. In Free and open communications on the internet, 2021. ACM. Retrieved from https://doi.org/10.1145/3473604.3474559
16. Russell Brandom. 2018. Amazon Web Services starts blocking domain-fronting, following Google’s lead — theverge.com.
17. Chad Brubaker, Amir Houmansadr, and Vitaly Shmatikov. 2014. CloudTransport: Using cloud storage for censorship-resistant networking. In Privacy enhancing technologies symposium, 2014. Springer. Retrieved from https://petsymposium.org/2014/papers/paper_68.pdf
18. Kimo Bumanglag and Houssain Kettani. 2020. On the impact of DNS over HTTPS paradigm on cyber systems. In 2020 3rd international conference on information and computer technologies (ICICT), 2020. IEEE, 494–499.
19. Zimo Chai, Amirhossein Ghafari, and Amir Houmansadr. 2019. On the importance of encrypted-SNI (ESNI) to censorship circumvention. In Free and open communications on the internet, 2019. USENIX. Retrieved from https://www.usenix.org/system/files/foci19-paper_chai_update.pdf
20. Yi Ting Chua and Ben Collier. 2019. Fighting the “blackheart airports”: Internal policing in the Chinese censorship circumvention ecosystem. In 2019 APWG Symposium on Electronic Crime Research (eCrime), November 2019. 1–9. https://doi.org/10.1109/eCrime47957.2019.9037500
21. Google Cloud. 2025. Quotas  |  Cloud Run functions Documentation.
22. Shadowsocks developers. 2025. Shadowsocks AEAD cihpher specification. Retrieved from https://shadowsocks.org/guide/aead.html
23. VMess developers. 2025. VMess. Retrieved from https://www.v2fly.org/en_US/developer/protocols/vmess.html
24. Roger Dingledine, Nick Mathewson, Paul F Syverson, and others. 2004. Tor: The second-generation onion router. In USENIX security symposium, 2004. 303–320.
25. Ivan Dolnák and Ján Litvik. 2017. Introduction to HTTP security headers and implementation of HTTP strict transport security (HSTS) header for HTTPS enforcing. In 2017 15th international conference on emerging eLearning technologies and applications (ICETA), 2017. IEEE, 1–4.
26. Frederick Douglas, Rorshach, Weiyang Pan, and Matthew Caesar. 2016. Salmon: Robust proxy distribution for censorship circumvention. Privacy Enhancing Technologies 2016, 4 (2016), 4–20. Retrieved from https://censorbib.nymity.ch/pdf/Douglas2016a.pdf
27. Haixin Duan, Nicholas Weaver, Zongxu Zhao, Meng Hu, Jinjin Liang, Jian Jiang, Kang Li, and Vern Paxson. 2012. Hold-On: Protecting against on-path DNS poisoning. In Securing and trusting internet names, 2012. National Physical Laboratory. Retrieved from https://www.icir.org/vern/papers/hold-on.satin12.pdf
28. Arun Dunna, Ciarán O’Brien, and Phillipa Gill. 2018. Analyzing China’s blocking of unpublished Tor bridges. In Free and open communications on the internet, 2018. USENIX. Retrieved from https://www.usenix.org/system/files/conference/foci18/foci18-paper-dunna.pdf
29. Agnieszka Dutkowska-Zuk, Austin Hounsel, Amy Morrill, Andre Xiong, Marshini Chetty, and Nick Feamster. 2022. How and why people use virtual private networks. In 31st USENIX security symposium (USENIX security 22), 2022. 3451–3465.
30. DW. 2024. DG8 leaders ask for more funding of censorship circumvention — corporate.dw.com. Retrieved from https://corporate.dw.com/en/dg8-leaders-call-for-more-funding-of-censorship-circumvention-tools/a-70846017
31. Ed25519. 2025. Introduction — ed25519.cr.yp.to.
32. Kathrin Elmenhorst, Bertram Schütz, Nils Aschenbruck, and Simone Basso. 2021. Web censorship measurements of HTTP/3 over QUIC. In Internet measurement conference, 2021. ACM. Retrieved from https://dl.acm.org/doi/pdf/10.1145/3487552.3487836
33. Roya Ensafi, David Fifield, Philipp Winter, Nick Feamster, Nicholas Weaver, and Vern Paxson. 2015. Examining how the Great Firewall discovers hidden circumvention servers. In Internet measurement conference, 2015. ACM. Retrieved from https://conferences2.sigcomm.org/imc/2015/papers/p445.pdf
34. Shencha Fan, Jackson Sippe, Sakamoto San, Jade Sheffey, David Fifield, Amir Houmansadr, Elson Wedwards, and Eric Wustrow. 2025. Wallbleed: A memory disclosure vulnerability in the Great Firewall of China. In Network and distributed system security, 2025. The Internet Society. Retrieved from https://gfw.report/publications/ndss25/data/paper/wallbleed.pdf
35. Yuzhou Feng, Ruyu Zhai, Radu Sion, and Bogdan Carbunar. 2023. A study of China’s censorship and its evasion through the lens of online gaming. In USENIX security symposium, 2023. USENIX. Retrieved from https://www.usenix.org/system/files/usenixsecurity23-feng.pdf
36. Paul Ferguson and Geoff Huston. 1998. What is a VPN? (1998).
37. Amos Fiat and Jared Saia. 2002. Censorship resistant peer-to-peer content addressable networks. In SODA, 2002. Citeseer, 94–103.
38. David Fifield. 2018. Domain fronting to App Engine stopped working (#25804) · Issues · Legacy / Trac · GitLab — gitlab.torproject.org.
39. David Fifield, Chang Lan, Rod Hynes, Percy Wegmann, and Vern Paxson. 2015. Blocking-resistant communication through domain fronting. Privacy Enhancing Technologies 2015, 2 (2015). Retrieved from https://www.icir.org/vern/papers/meek-PETS-2015.pdf
40. David Fifield and Lynn Tsai. 2016. Censors’ delay in blocking circumvention proxies. In Free and open communications on the internet, 2016. USENIX. Retrieved from https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.pdf
41. Sergey Frolov, Jack Wampler, Sze Chuen Tan, J. Alex Halderman, Nikita Borisov, and Eric Wustrow. 2019. Conjure: Summoning proxies from unused address space. In Computer and communications security, 2019. ACM. Retrieved from https://jhalderm.com/pub/papers/conjure-ccs19.pdf
42. Sergey Frolov and Eric Wustrow. 2019. The use of TLS in censorship circumvention. In Network and distributed system security, 2019. The Internet Society. Retrieved from https://tlsfingerprint.io/static/frolov2019.pdf
43. Sergey Frolov and Eric Wustrow. 2020. HTTPT: A probe-resistant proxy. In Free and open communications on the internet, 2020. USENIX. Retrieved from https://www.usenix.org/system/files/foci20-paper-frolov.pdf
44. ggailey777. 2025. Azure Functions scale and hosting — learn.microsoft.com.
45. Nguyen Phong Hoang, Jakub Dalek, Masashi Crete-Nishihata, Nicolas Christin, Vinod Yegneswaran, Michalis Polychronakis, and Nick Feamster. 2024. GFWeb: Measuring the Great Firewall’s Web censorship at scale. In USENIX security symposium, 2024. USENIX. Retrieved from https://www.usenix.org/system/files/sec24fall-prepub-310-hoang.pdf
46. Nguyen Phong Hoang, Arian Akhavan Niaki, Jakub Dalek, Jeffrey Knockel, Pellaeon Lin, Bill Marczak, Masashi Crete-Nishihata, Phillipa Gill, and Michalis Polychronakis. 2021. How great is the Great Firewall? Measuring China’s DNS censorship. In USENIX security symposium, 2021. USENIX. Retrieved from https://www.usenix.org/system/files/sec21-hoang.pdf
47. Amir Houmansadr, Giang T. K. Nguyen, Matthew Caesar, and Nikita Borisov. 2011. Cirripede: Circumvention infrastructure using router redirection with plausible deniability. In Computer and communications security, 2011. ACM, 187–200. Retrieved from https://people.cs.umass.edu/~amir/papers/CCS11-Cirripede.pdf
48. https://www.opentech.fund/news/author/ms-otf-usr1/. 2025. Surge and Sustain Fund — opentech.fund. Retrieved from https://www.opentech.fund/funds/surge-and-sustain-fund/
49. Tor Project Inc. 2025. Fingerprinting protections — tb-manual.torproject.org.
50. Samrat Karak Jaiganesh Girinathan. 2022. Using Amazon CloudFront with AWS Lambda as origin to accelerate your web applications | Amazon Web Services.
51. Jigsaw. 2025. Outline. Retrieved from https://getoutline.org/
52. Divyank Katira, Gurshabad Grover, Kushagra Singh, and Varun Bansal. 2023. CensorWatch: On the implementation of online censorship in India. In Free and open communications on the internet, 2023. Retrieved from https://www.petsymposium.org/foci/2023/foci-2023-0006.pdf
53. Patrick Tser Jern Kon, Aniket Gattani, Dhiraj Saharia, Tianyu Cao, Diogo Barradas, Ang Chen, Micah Sherr, and Benjamin E. Ujcich. 2024. NetShuffle: Circumventing censorship with shuffle proxies at the edge. In Symposium on security & privacy, 2024. IEEE. Retrieved from https://www.computer.org/csdl/pds/api/csdl/proceedings/download-article/1RjEabCelaM/pdf
54. Patrick Tser Jern Kon, Sina Kamali, Jinyu Pei, Diogo Barradas, Ang Chen, Micah Sherr, and Moti Yung. 2024. SpotProxy: Rediscovering the cloud for censorship circumvention. In USENIX security symposium, 2024. USENIX. Retrieved from https://www.cs-pk.com/sec24-spotproxy-final.pdf
55. John Kristoff, Moritz Müller, Arturo Filastò, Max Resing, Chris Kanich, and Niels ten Oever. 2024. Internet sanctions on Russian media: Actions and effects. In Free and open communications on the internet, 2024. Retrieved from https://www.petsymposium.org/foci/2024/foci-2024-0001.pdf
56. AWS Lambda. 2025. Lambda quotas.
57. AWS Lambda. 2025. Understanding Lambda function scaling.
58. Felix Lange, Niklas Niere, Jonathan von Niessen, Dennis Suermann, Nico Heitmann, and Juraj Somorovsky. 2025. I(ra)nconsistencies: Novel insights into Iran’s censorship. In Free and open communications on the internet, 2025. Retrieved from https://www.petsymposium.org/foci/2025/foci-2025-0002.pdf
59. Lantern. 2025. Lantern — github.com. Retrieved from https://github.com/getlantern
60. Colm MacCárthaigh. 2018. Enhanced Domain Protections for Amazon CloudFront Requests | Amazon Web Services — aws.amazon.com.
61. Nima Mahmoudi and Hamzeh Khazaei. 2022. Mlproxy: Sla-aware reverse proxy for machine learning inference serving on serverless computing platforms. arXiv preprint arXiv:2202.11243 (2022).
62. Garrett McGrath and Paul R Brenner. 2017. Serverless computing: Design, implementation, and performance. In 2017 IEEE 37th international conference on distributed computing systems workshops (ICDCSW), 2017. IEEE, 405–410.
63. Milad Nasr, Sadegh Farhang, Amir Houmansadr, and Jens Grossklags. 2019. Enemy at the gateways: Censorship-resilient proxy distribution using game theory. In NDSS, 2019.
64. Milad Nasr, Hadi Zolfaghari, Amir Houmansadr, and Amirhossein Ghafari. 2020. MassBrowser: Unblocking the censored web for the masses, by the masses. In Network and distributed system security, 2020. The Internet Society. Retrieved from https://www.ndss-symposium.org/wp-content/uploads/2020/02/24340.pdf
65. Sadia Nourin, Van Tran, Xi Jiang, Kevin Bock, Nick Feamster, Nguyen Phong Hoang, and Dave Levin. 2023. Measuring and evading Turkmenistan’s internet censorship. In The international world wide web conference, 2023. ACM. Retrieved from https://dl.acm.org/doi/abs/10.1145/3543507.3583189
66. Aaron Ortwein, Kevin Bock, and Dave Levin. 2023. Towards a comprehensive understanding of Russian transit censorship. In Free and open communications on the internet, 2023. Retrieved from https://www.petsymposium.org/foci/2023/foci-2023-0012.pdf
67. P Pandiaraja and J Manikandan. 2015. Web proxy based detection and protection mechanisms against client based HTTP attacks. In 2015 international conference on circuits, power and computing technologies [ICCPCT-2015], 2015. IEEE, 1–6.
68. Diego Perino, Matteo Varvello, and Claudio Soriente. 2018. ProxyTorrent: Untangling the free HTTP (s) proxy ecosystem. In Proceedings of the 2018 world wide web conference, 2018. 197–206.
69. Tor Project. 2018. [Tor-project] Summary of meek's costs, March 2018 — archive.torproject.org. Retrieved from https://archive.torproject.org/websites/lists.torproject.org/pipermail/tor-project/2018-April/001743.html
70. Tor Project. 2025. The Tor Project | Privacy & Freedom Online — torproject.org. Retrieved from https://www.torproject.org/
71. Psiphon Inc. 2025. Psiphon-automation: Circumvention system automation and server management. Retrieved from https://github.com/Psiphon-Inc/psiphon-automation
72. Raymond Rambert, Zachary Weinberg, Diogo Barradas, and Nicolas Christin. 2021. Chinese wall or Swiss cheese? Keyword filtering in the Great Firewall of China. In WWW, 2021. ACM. Retrieved from https://censorbib.nymity.ch/pdf/Rambert2021a.pdf
73. Reethika Ramesh, Ram Sundara Raman, Apurva Virkud, Alexandra Dirksen, Armin Huremagic, David Fifield, Dirk Rodenburg, Rod Hynes, Doug Madory, and Roya Ensafi. 2023. Network responses to Russia’s invasion of Ukraine in 2022: A cautionary tale for Internet freedom. In USENIX security symposium, 2023. USENIX. Retrieved from https://censoredplanet.org/assets/russia-ukraine-invasion.pdf
74. Reethika Ramesh, Anjali Vyas, and Roya Ensafi. 2023. " all of them claim to be the best": Multi-perspective study of {VPN} users and {VPN} providers. In 32nd USENIX security symposium (USENIX security 23), 2023. 5773–5789.
75. GFW Report. 2022. Large scale blocking of TLS-based censorship circumvention tools in China. Retrieved from https://github.com/net4people/bbs/issues/129
76. Jade Sheffey, Ali Zohaib, Dayeon Kang, Zakir Durumeric, Amir Houmansadr, and Qiang Wu. 2025. I’ll shake your hand: What happens after DNS poisoning. Free and Open Communications on the Internet (2025).
77. Signal. 2018. A letter from Amazon — signal.org.
78. Paulo Silva, Daniel Fireman, and Thiago Emmanuel Pereira. 2020. Prebaking functions to warm the serverless cold start. In Proceedings of the 21st international middleware conference, 2020. 1–13.
79. Microsoft Security Team. 2021. Securing our approach to domain fronting within Azure.
80. The4. 2025. What Are the 9 Operating Costs of a Virtual Private Network Provider? — businessplan-templates.com. Retrieved from https://businessplan-templates.com/blogs/running-costs/virtual-private-network-provider
81. Finbarr Toesland. 2022. Lantern, US-backed censorship circumvention tool records growth — techerati.com.
82. trojan developers. 2025. trojan. Retrieved from https://github.com/trojan-gfw/trojan
83. V2Ray developers. 2025. V2Ray. Retrieved from https://github.com/v2fly/v2ray-core
84. Parichehr Vahidinia, Bahar Farahani, and Fereidoon Shams Aliee. 2020. Cold start in serverless computing: Current trends and mitigation strategies. In 2020 international conference on omni-layer intelligent systems (COINS), 2020. IEEE, 1–7.
85. Erwin Van Eyk, Lucian Toader, Sacheendra Talluri, Laurens Versluis, Alexandru Uță, and Alexandru Iosup. 2018. Serverless is more: From paas to present cloud computing. IEEE Internet Computing 22, 5 (2018), 8–17.
86. Nicholas Weaver, Christian Kreibich, Martin Dam, and Vern Paxson. 2014. Here be web proxies. In International conference on passive and active network measurement, 2014. Springer, 183–192.
87. Tim Wilde. 2012. Knock knock knockin’ on bridges’ doors. Retrieved from https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors
88. Philipp Winter. 2013. GFW actively probes obfs2bridges. Retrieved from https://bugs.torproject.org/8591
89. Philipp Winter and Stefan Lindskog. 2012. How the Great Firewall of China is blocking Tor. In Free and open communications on the internet, 2012. USENIX. Retrieved from https://www.usenix.org/system/files/conference/foci12/foci12-final2.pdf
90. Mingshi Wu, Jackson Sippe, Danesh Sivakumar, Jack Burg, Peter Anderson, Xiaokang Wang, Kevin Bock, Amir Houmansadr, Dave Levin, and Eric Wustrow. 2023. How the Great Firewall of China detects and blocks fully encrypted traffic. In USENIX security symposium, 2023. USENIX. Retrieved from https://www.usenix.org/system/files/sec23fall-prepub-234-wu-mingshi.pdf
91. Diwen Xue, Anna Ablove, Reethika Ramesh, Grace Kwak Danciu, and Roya Ensafi. 2024. Bridging barriers: A survey of challenges and priorities in the censorship circumvention landscape. In USENIX security symposium, 2024. USENIX. Retrieved from https://www.usenix.org/system/files/usenixsecurity24-xue-bridging.pdf
92. Diwen Xue, Benjamin Mixon-Baca, ValdikSS, Anna Ablove, Beau Kujath, Jedidiah R. Crandall, and Roya Ensafi. 2022. TSPU: Russia’s decentralized censorship system. In Internet measurement conference, 2022. ACM. Retrieved from https://dl.acm.org/doi/pdf/10.1145/3517745.3561461
93. Diwen Xue, Reethika Ramesh, ValdikSS, Leonid Evdokimov, Andrey Viktorov, Arham Jain, Eric Wustrow, Simone Basso, and Roya Ensafi. 2021. Throttling Twitter: An emerging censorship technique in Russia. In Internet measurement conference, 2021. ACM. Retrieved from https://dl.acm.org/doi/pdf/10.1145/3487552.3487858
94. Tony Huiquan Zhang, Jianhua Xu, and Jinjin Liu. 2024. How do toothless tigers bite? Extra-institutional governance and Internet censorship by local governments in China. The China Quarterly 2024, (2024). Retrieved from https://www.cambridge.org/core/services/aop-cambridge-core/content/view/B1BB347F7458EBF033A65461D1C2D82A/S0305741024000602a.pdf
95. Zhensheng Zhang, Ya-Qin Zhang, Xiaowen Chu, and Bo Li. 2004. An overview of virtual private network (VPN): IP VPN and optical VPN. Photonic network communications 7, (2004), 213–225.
96. Hadi Zolfaghari and Amir Houmansadr. 2016. Practical censorship evasion leveraging content delivery networks. In Computer and communications security, 2016. ACM. Retrieved from https://people.cs.umass.edu/~amir/papers/CDNReaper.pdf

附录 A. 补充实验

A.1. CensorLess 性能

在图 9中，每幅子图分别展示了三种场景下加载内容所需的时间：浏览 cnn.com 网页、下载 PDF 文件和观看短视频。纵轴标签表示请求发往的目的地，↻ 表示复用与同一目的地的连接。不使用代理时，瀑布图结果可以明确显示目的地；使用 CensorLess 后，结果则成功隐藏了请求的目的地。无论是否迁移桥接节点，CensorLess 标准模式的加载时间模式都很相似，因为两者都只使用 HTTPS GET/POST 方法。在图 9(h)中，尽管桥接节点迁移发生在 0.5 至 1.0 秒之间，采用迁移的标准模式仍能无缝处理客户端请求。值得注意的是，CensorLess 私密模式加载网页所需的时间更长，因为流量需要额外经过一台 VPS，并经历用于安全通信的连接建立过程。

A.2. 运行成本

我们分析了单个代理的运行成本如何随安全级别变化。由于私密模式会产生按 VPS 使用小时数计算的额外费用，我们以使用私密模式的小时数衡量安全级别。安全级别为 0% 表示客户端在 24 小时内仅使用 CensorLess 标准模式；25% 表示在 24 小时中的 6 小时使用私密模式；100% 表示 24 小时内的全部流量均采用私密模式。最先进的低成本工具 SpotProxy 为各代理使用竞价实例（节省成本的 IaaS 实例）；CensorLess 标准模式则为各代理使用按请求计价的无服务器函数，并在私密模式中额外采用 IaaS 实例（即 VPS）。在我们的实验中，这台 VPS 所需的配置（2 个 CPU 和 1 GB 内存）低于 SpotProxy（2 个 CPU 和 8 GB 内存），因而每小时成本更低。图 10显示，随着私密模式使用时间增加，成本会缓慢地小幅线性增长。即使安全级别达到 100%（即 24 小时均使用私密模式），费用仍低于 SpotProxy 最便宜的场景。与 SpotProxy 类似，私密模式的成本主要取决于 VPS 成本；但私密模式中的一台 VPS 可以支持多个无服务器代理，因此代理越多，节省的成本也越多。

在分析大规模无服务器函数的经济性时，我们发现，由于函数持续时间各不相同，成本的线性关系会在较高并发水平下被打破。

表 2显示，调用次数较少时，冷启动反而会耗费更多时间；由于持续时间影响计费，这也会影响总成本。

我们研究了代理与客户端数量增加时，无服务器函数桥接节点的运行成本。图 11中，每组内处于相同位置的柱形，表示一个客户端向一个代理发送相同数量的调用。由于调用次数较少时持续时间相对较长，每客户端 10 次调用与每客户端 50 次调用的成本相近。当一个客户端向一个代理发送 100 个请求时，无服务器函数的费用会增加约 3.6 倍。

这意味着，在函数调用总数相同的情况下，使用更多代理并将每个客户端的调用量保持在适中水平（约 50 次），比使用较少代理处理突发流量更具成本效益。这一发现为实践中的系统优化部署提供了宝贵指导。

A.3. 审查规避效果

A.3.1. 模拟

我们从客户端和代理两个方面评估系统面对两类审查方时的审查规避效果：激进审查方和最优审查方。激进审查代理会立即封锁所识别出的任何新代理，而最优审查方则采用最优博弈论方法作为其审查策略。我们将 50% 的客户端设为审查代理，并比较刷新周期等于或两倍于封锁周期的场景。如图 12所示，当刷新周期设为封锁周期的两倍时，本系统的连接用户比例和未封锁代理比例在初始阶段均大幅波动；当刷新周期与封锁周期相同时，连接则保持稳定。即使 50% 的用户都是激进审查代理，CensorLess 仍能保证用户平均连接率达到 70%。

CensorLess 展现出与先进的基于 IP 的工具（例如 SpotProxy）相当的审查规避效果，因为它通过 URL 轮换代理来抵御审查。在该模拟中，审查方采用与基于 IP 的代理分配算法相同的方法，根据已识别的 URL 封锁用户与代理。如图 13所示，尽管占优算法随时间变化，但两者的平均连接用户比例相同：采用激进方法时为 77%，采用最优方法时为 99%。

A.3.2. 在受审查地区

我们针对中国大陆这一广为人知的受审查地区中 500 个被封锁网站开展了实验。其中针对 50 个被封锁域名的部分结果见表 3。CensorLess 标准模式对发往这些域名的每个请求都成功收到了响应，私密模式则只有 tubegays.xxx 未能收到响应。私密模式访问 tubegays.xxx 失败，是因为网站策略拒绝了 AWS VPS 的请求。尽管对网站的最终请求来自 AWS VPS，CensorLess 标准模式使用的是无服务器函数，因此成功收到了响应。