KechuAI

Pingora：Cloudflare 开源的 Rust 代理框架，NGINX 的内存安全替代品

Pingora
Rust
NGINX
开源
网络代理
Cloudflare
2026/10/2
·

阅读时间: 大约 14 分钟

Pingora：Cloudflare 开源的 Rust 代理框架，NGINX 的内存安全替代品

Pingora 吉祥物：戴安全帽的 Rust 螃蟹在雪山旁收线（Cloudflare 官方）

2024 年 2 月 28 日，Cloudflare 在官方博客宣布将内部使用多年的 HTTP 代理框架 Pingora 以 Apache License 2.0 开源。Pingora 是一个用 Rust 编写的异步多线程网络服务框架，定位不是”开箱即用的 Nginx 替代品”，而是”用来可编程地构建 HTTP 代理、负载均衡、网关的引擎”。本文基于 Cloudflare 2022 年《How we built Pingora》与 2024 年《Open sourcing Pingora》两篇一手工程博客，梳理它解决了什么问题、官方数据到底说明了什么，以及这些数字背后的口径偏向。

一、背景：为什么 Cloudflare 要换掉 NGINX

Cloudflare 的全球网络在客户端浏览器与源站服务器之间承担代理角色，其 CDN、Workers fetch、Tunnel、Stream、R2 等产品都依赖同一套”回源代理”。长期以来，这套代理建立在 NGINX（C）+ OpenResty（Lua）之上。随着规模扩大，官方在博客中列举了三类难以绕过的痛点：

  1. 请求—进程绑定导致连接池碎片化：NGINX 每个 worker 是独立进程，请求一旦落到某个 worker，就只能复用该 worker 内的上游 TCP/TLS 连接池。机器上 worker 越多，连接池被切得越碎，连接复用率反而下降，TTFB 变慢。
  2. worker 内任务互相阻塞：CPU 密集或阻塞 IO 的请求会拖慢同一 worker 上的其他请求，Cloudflare 多年来花了大量精力绕开这一限制。
  3. 可编程性与内存安全两难：NGINX 核心是 C，易出内存安全问题；补业务逻辑的 Lua 动态类型、性能弱；且重试换头、自定义故障转移等高级行为 NGINX 本身不允许。官方还直言 NGINX 社区活跃度下降、开发”behind closed doors”。

Cloudflare 每季度重新评估过三条路：继续投资 NGINX/fork、迁移到 Envoy 等第三方代码库、从零自研。最终选择第三条——自研一个”干净石板”的平台，用 Rust 做内存安全，用多线程 + work-stealing 做连接池共享。

二、是什么：一个框架，不是一个可执行二进制

Pingora 官方明确定位：它是发动机，不是整车。它提供的是一组 Rust 库和 API：

  • 基于 HTTP/1、HTTP/2、TLS、裸 TCP/UDS 构建客户端、服务端与代理；
  • 作为代理支持端到端 HTTP/1.1、HTTP/2、gRPC、WebSocket 代理，官方称 HTTP/3 在路线图上（开源公告时仍未支持）；
  • 内置可定制的负载均衡与故障转移策略；
  • TLS 层同时支持 OpenSSL 与 BoringSSL，具备 FIPS 合规与后量子加密（post-quantum crypto）能力；
  • 提供”请求生命周期”回调（request filter、upstream_peer、upstream_request_filter 等），API 形态刻意对齐 OpenResty 的 *_by_lua，方便 Nginx/OpenResty 工程师迁移；
  • 运行时能力：零停机优雅重启（graceful restart，不丢一个在途请求）、Syslog/Prometheus/Sentry/OpenTelemetry 可观测性集成。

开源公告里官方用约 30 行 Rust 代码演示了一个 round-robin 负载均衡器：实现 ProxyHttp trait 的 upstream_peer() 方法选上游，再用 upstream_request_filter 改写 Host 头，即可把 1.1.1.1 与 1.0.0.1 做成上游池。整个请求经过回调的路径如下图：

Pingora 请求在 upstream_peer 与 upstream_request_filter 两个回调间的流转（官方图）

三、技术机制：共享连接池是性能红利的真正来源

官方在 2022 年那篇博客里反复强调：Pingora 的提速不是因为 Rust 代码跑得比 C 快——老服务处理请求本身就是亚毫秒级，新老差距不在这里。真正的红利来自架构：

  • 多线程而非多进程：所有 worker 线程共享一个全局连接池，任意线程都能复用到任意一条到上游的已建立连接，省去 TCP + TLS 握手；
  • work-stealing 调度：基于 Tokio 异步运行时，任务在线程间窃取，避免 NGINX 那种核间负载不均；
  • 共享内存更便宜：NGINX 共享内存里只能放字符串/数字且每次访问都要加互斥锁；Pingora 用原子引用计数直接共享对象引用；
  • 避免语言间数据拷贝：OpenResty 下 Lua 访问一个 HTTP 头要从 NGINX C struct 读出、分配 Lua string、拷贝过去、再由 Lua GC 回收；Pingora 里是直接字符串访问。

NGINX 每个 worker 一个独立连接池，新增 worker 会产生更多新握手（官方图）

对比之下，Pingora 的模型是所有线程共用一个连接池：

Pingora 全局共享连接池，所有请求复用同一组已建立连接（官方图）

四、官方公布的关键数据

以下数字均来自 Cloudflare 两篇官方博客（2022-09-14 内部生产数据；2024-02-28 开源时的累计口径）：

指标官方口径出处
日处理请求量每天超过 1 万亿（1 trillion）请求2022 博文引言
CPU/内存占用同等流量下比旧服务节省约 70% CPU、67% 内存（即约为旧资源的 1/3）2022 博文”More efficient”
TTFB 改善全网流量中位 TTFB 降低 5 ms，p95 降低 80 ms2022 博文”Pingora is faster in production”
新建连接数全网每秒新建上游连接数降至旧服务的 1/3同上
某大客户连接复用率从 87.1% 提升到 99.92%，到其源站的新建连接数减少 160 倍同上
握手时间节省折算下来每天为全网用户/客户节省 434 年的握手等待时间同上
崩溃记录自投产以来处理”数百万亿”请求，未因自身服务代码崩溃过一次；少数几次崩溃事后被定位为内核 bug 或硬件问题2022 博文”Safer”
开源后累计流量自 2022 博文到 2024 开源，全球网络上已处理**接近 1 quadrillion（10^15）**请求2024 开源公告

五、评测方法批判：这些数字怎么测的，偏向在哪

必须明确：上述数据全部来自 Cloudflare 自己的生产环境 A/B 对照，不是第三方 benchmark，也不是可复现的实验室压测。读这些数字时要注意三层口径偏差：

  1. 对比基线是”Cloudflare 自己的 NGINX+Lua 定制版”，不是 stock NGINX。Cloudflare 在 NGINX 上叠了大量自研补丁和 OpenResty Lua 逻辑，旧服务的 CPU/内存开销里有相当一部分是 Lua 字符串拷贝、GC 和补丁复杂度贡献的。换成全新 Pingora 后省下来的 70% CPU，有多少来自”Rust vs C/Lua”、有多少来自”架构重写”，官方没有拆分。对一个直接用 stock NGINX 做反向代理的中小团队，迁移收益不会是这个量级。
  2. TTFB 收益高度依赖”回源”场景与长连接。5 ms / 80 ms 的改善几乎全部来自 TCP+TLS 握手减少和连接复用率提升。如果你的业务大部分请求命中 CDN 缓存、或到上游本身就是同机房低延迟短连接，这部分红利会大幅缩水。160 倍新建连接缩减是”某一个大客户”的个例，不是全网平均。
  3. “434 年握手时间/天”是营销化折算，不是可直接测量的工程指标；它是把全网上每一条握手节省的毫秒数线性加总再除以一天秒数得到的概念值，用来直观表达量级，不能当成 SLA 数字引用。
  4. “零崩溃”的口径是”未因自身服务代码崩溃”。官方自己承认遇到过崩溃，但事后定位为内核 bug 和硬件问题——也就是说这是 Rust 内存安全带来的信心加成，不是严格意义上的”生产零故障”指标，不能直接等同于 MTBF。

此外，官方也明确承认：开源时 API 稳定性不保证（pre-1.0，filter/callback 签名可能破坏式变更）；非 Unix 系统不在路线图上（Windows 原生跑不起来）；HTTP/3 当时仍在路线图而非已支持。这些都是采用前要掂量的 nuance。

六、优势与局限

优势：

  • 内存安全 + 性能：Rust 语义在 Cloudflare 这种每秒数百万请求的规模上被验证能显著减少内存类事故；
  • 架构红利真实：全局共享连接池 + work-stealing，从根上解决 NGINX worker 模型的连接复用问题；
  • 可编程性对齐 OpenResty：回调模型让 Nginx/Lua 工程师心智迁移成本低；
  • 生产级可观测性与优雅重启：Prometheus/OpenTelemetry/Sentry 开箱集成，graceful restart 不丢在途请求；
  • Apache 2.0 协议，可商用，与 ISRG Prossimo 合作推进内存安全基础设施。

局限：

  • 是库不是产品：没有现成的配置文件、管理面板，你得写 Rust 代码，对运维团队门槛高；官方也说”batteries-included 的成品”要靠与 ISRG 的后续合作；
  • API 未稳定：1.0 之前升级可能破坏代码；
  • 仅 Unix：Windows 原生不支持，也不在路线图；
  • HTTP/3 当时未支持（路线图中）；
  • 性能数字是 Cloudflare 超大规模场景的产物，中小团队直接套用 70% CPU 节省的预期会落空。

七、适用人群与不适用人群

适合：

  • 需要构建自定义七层网关/负载均衡/反向代理、且团队有 Rust 能力的中大型工程团队；
  • 对内存安全有硬要求（合规、政府/金融场景），希望替代 C/C++ 代理栈的团队；
  • 已经重度使用 OpenResty、但受限于 NGINX 架构、想做深度定制的团队。

不适合：

  • 只想 yum install nginx 改几行配置就跑起来的小站站长——直接用 Caddy / NGINX 更省事；
  • 需要 Windows 原生部署的团队；
  • 期望直接获得 Cloudflare 同等 TTFB/资源收益、但业务规模和回源模型完全不同的团队。

参考来源