Why Cloudflare Replaced Nginx with Pingora: Design, Performance, and Security Advantages
The article explains how Cloudflare built the Rust‑based Pingora reverse proxy to overcome Nginx's architectural limits, achieve higher performance, better connection reuse, lower CPU/memory usage, and stronger safety, while supporting new features for its edge platform.
1 Introduction
Cloudflare announced last year that it would retire Nginx in favor of its own next‑generation reverse‑proxy service, Pingora, claiming it is faster, more efficient, and more secure. This article, based on Cloudflare’s official blog post, details where Pingora outperforms Nginx.
Why Build a New Proxy
As Cloudflare grew, Nginx could no longer meet the performance and feature requirements of their massive scale. Limitations in Nginx’s architecture prevented the needed throughput and flexibility for complex environments.
Architectural Limits Hurt Performance
Nginx’s worker‑process model creates load‑balancing inefficiencies because each request is handled by a single worker, leading to CPU core imbalance and slower speeds.
The request‑process lock also means heavy CPU or blocking I/O tasks can slow down other requests.
Connection reuse is especially problematic: each worker maintains its own connection pool, so adding more workers reduces reuse rates, increasing TCP/TLS handshakes and TTFB.
Solving the fundamental worker/process model would automatically resolve many of these issues.
Some Features Are Hard to Add
While Nginx is an excellent web server and load balancer, Cloudflare needed capabilities beyond its scope, such as custom request‑retry logic and per‑origin header manipulation, which Nginx does not support.
The C codebase of Nginx is not memory‑safe, making it prone to bugs; adding Lua mitigates some risks but introduces performance and type‑safety drawbacks.
The Nginx community is relatively inactive, limiting collaborative development.
Choosing to Build Our Own
Cloudflare evaluated three options: continue investing in Nginx customizations, migrate to a third‑party proxy like Envoy, or build an internal platform from scratch. Over several years, the path of least resistance was to keep enhancing Nginx, but in some cases the ROI of a custom proxy became compelling.
Ultimately, they decided to design a new proxy tailored to Cloudflare’s scale and use cases.
2 Pingora Project
Design Decisions
Pingora is written in Rust to achieve C‑level performance with memory safety.
Instead of using existing HTTP libraries such as hyper, Cloudflare built its own library to maximize flexibility and enable rapid innovation.
The proxy must handle many non‑standard, RFC‑non‑compliant HTTP traffic, requiring a tolerant and customizable HTTP stack.
To support unconventional status codes (e.g., 599‑999), Cloudflare contributed changes upstream to hyper.
Pingora uses a multithreaded model with Tokio for asynchronous I/O, allowing easy sharing of resources like connection pools and implementing work‑stealing to avoid performance bottlenecks.
The design includes a programmable request‑lifecycle API similar to Nginx/OpenResty, letting developers write filters that can modify or reject requests, facilitating a smooth transition for engineers familiar with Nginx.
3 Pingora Is Faster in Production
Pingora now handles the majority of HTTP traffic that interacts with origin servers, collecting extensive performance data.
Median TTFB improved by 5 ms and the 95th percentile by 80 ms, not because the code runs faster per request, but because the new architecture shares connections across all threads, improving reuse and reducing handshake overhead.
Pingora creates only one‑third as many new connections as the legacy service; for a major client, connection‑reuse rose from 87.1 % to 99.92 %, cutting new connections by a factor of 160 and saving roughly 434 years of handshake time per day.
New features such as HTTP/2 upstream support and, subsequently, gRPC became easy to add, whereas implementing them in Nginx would require substantial engineering effort.
Cache Reserve, which uses R2 storage as a cache layer, is another capability enabled by Pingora.
More Efficient
Under the same traffic load, Pingora consumes about 70 % less CPU and 67 % less memory than the previous service.
Rust code runs more efficiently than the prior Lua implementation, and the architecture avoids costly string copying and garbage collection present in Nginx/OpenResty.
The multithreaded model enables direct atomic reference‑counted sharing of data, eliminating mutex‑protected shared memory used by Nginx.
Reduced new‑connection creation also lowers TLS handshake costs.
More Secure
Rust’s memory‑safety guarantees protect Pingora from undefined behavior, allowing rapid feature development without the risk of memory‑related crashes.
Since its launch, Pingora has processed trillions of requests without a single crash caused by its own code.
When rare crashes have occurred, they were traced to kernel bugs or hardware issues, not to Pingora itself.
4 Summary
In summary, Cloudflare has built a faster, more efficient, and more versatile internal proxy that serves as a foundation for current and future products.
Source: nginx (ID: nginx-study)
Backend Community Group
We welcome developers, technical recruiters, and anyone who wants to share job referrals to join our high‑quality technical exchange community.
We encourage civil discussion focused on technical exchange , job referrals , and industry topics .
Advertisements are prohibited; do not trust private messages to avoid scams.
Selected Java Interview Questions
A professional Java tech channel sharing common knowledge to help developers fill gaps. Follow us!
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.