Why Cloudflare Replaced Nginx with Pingora: Inside the Next‑Gen Rust Proxy

Introduction

Cloudflare announced last year that it would retire Nginx in favor of its own next‑generation HTTP proxy, Pingora, claiming it is faster, more efficient, and more secure. The following summarizes the key advantages of Pingora over Nginx.

Why Build a New Proxy

As the world’s largest free CDN, Cloudflare handles over a trillion client requests daily. The existing Nginx‑based architecture could no longer meet performance, scale, and feature requirements.

Architectural Limits Hurt Performance

NGINX’s worker‑process model assigns each request to a single worker, causing load imbalance across CPU cores and slowing overall speed.

Requests that perform heavy CPU work or block I/O can degrade other requests. Connection reuse suffers because each worker maintains its own connection pool; adding more workers further fragments the pool, increasing hardware usage and response time.

Some Features Are Hard to Add

NGINX is an excellent web server and load balancer, but Cloudflare’s needs go far beyond that. Adding custom functionality often requires extensive modifications to NGINX’s upstream code, which is difficult and risky.

NGINX is written in C and lacks memory safety, making it prone to bugs and security issues. While Lua can extend NGINX, it introduces performance penalties and lacks static type checking.

Choosing to Build Our Own

Cloudflare evaluated three options over several years:

Continue investing in NGINX with custom development.

Migrate to another third‑party proxy such as Envoy.

Build an internal platform from scratch.

Although the path of least resistance was to keep extending NGINX, the long‑term ROI of a purpose‑built proxy justified starting from zero.

Pingora Project

Design Decisions

Pingora is written in Rust, offering C‑level performance with memory safety. Cloudflare chose to implement its own HTTP library rather than rely on existing ones like hyper to maximize flexibility.

The proxy must handle many non‑RFC‑compliant HTTP cases, so a tolerant, customizable HTTP stack was required.

Workload scheduling uses a multithreaded model with Tokio for async I/O, enabling efficient connection‑pool sharing and work stealing.

Pingora provides a programmable request‑lifecycle API similar to NGINX/OpenResty, allowing developers to write request filters that can modify or reject traffic.

Pingora Faster in Production

Pingora processes virtually all HTTP requests that need to talk to origin servers. Performance data shows a median TTFB reduction of 5 ms and a 95th‑percentile reduction of 80 ms compared with the previous service.

The gains stem from a shared‑connection architecture that improves reuse and reduces TCP/TLS handshake overhead.

Pingora creates only one‑third as many new connections per second as the legacy service, raising connection‑reuse rates from 87.1 % to 99.92 % and saving an estimated 434 years of handshake time per day.

More Features

The developer‑friendly interface eliminates previous limitations, enabling rapid addition of core features such as new protocols. For example, HTTP/2 upstream support was added with minimal effort, paving the way for gRPC.

Cache Reserve, which uses Cloudflare R2 as a storage layer, was also integrated.

More Efficient

Under the same traffic load, Pingora reduces CPU usage by ~70 % and memory usage by ~67 % compared with the old service.

Rust code runs faster than the previous Lua implementation, and the multithreaded model allows efficient shared‑data access without heavy mutexes.

More Secure

Rust’s memory‑safety guarantees protect against undefined behavior, allowing engineers to focus on feature development rather than debugging crashes.

Since its launch, Pingora has processed trillions of requests without a single crash caused by its own code.

Conclusion

In summary, Cloudflare has deployed Pingora as a faster, more efficient, and more versatile internal proxy that will serve as the foundation for current and future products, with plans to open‑source it after further maturation.