Why Cloudflare Replaced Nginx with Pingora: A Faster, Safer Proxy

Introduction

Pingora is Cloudflare’s new internally built HTTP proxy written in Rust. It handles more than 1 trillion requests per day, improves performance, and runs on roughly one‑third the CPU and memory of the previous proxy infrastructure.

Why Build a New Proxy?

As the world’s largest free CDN, Cloudflare’s edge layer processes the greatest volume of web requests. The legacy Nginx‑based architecture could no longer meet the performance, scale, and feature requirements of such a massive system.

Architectural Limitations of Nginx

The Nginx worker‑process model creates load imbalance because each request is handled by a single worker, preventing efficient CPU utilization. Connection reuse suffers because connections are pooled per worker; adding more workers fragments the pool, increasing hardware usage and response time.

Choosing to Build Our Own

Cloudflare evaluated three options: continue customizing Nginx, migrate to another third‑party proxy (e.g., Envoy), or develop a new platform from scratch. Over several years the team repeatedly chose the path of least resistance, but eventually the ROI of a purpose‑built proxy became clear, leading to the decision to create Pingora.

Pingora Project

Design Decisions

Rust was selected for its ability to deliver C‑level performance with memory safety. Instead of relying on existing HTTP libraries like hyper, Cloudflare built its own library to maximize flexibility and enable rapid innovation.

To support the myriad non‑RFC‑compliant HTTP traffic seen on the Internet, Pingora implements a tolerant, customizable HTTP stack. The project also adopts a multithreaded model with work‑stealing, leveraging the Tokio async runtime for efficient resource sharing.

A programmable request‑lifecycle interface, similar to Nginx/OpenResty, allows developers to inject custom logic (e.g., request filters) without modifying core proxy code.

Pingora Is Faster in Production

Performance measurements show that Pingora reduces median TTFB by 5 ms and the 95th‑percentile TTFB by 80 ms compared to the legacy service. These gains stem from a shared‑across‑threads connection pool that dramatically improves connection reuse.

Across all customers, Pingora creates only one‑third as many new connections per second as the old service. For a major client, connection‑reuse rose from 87.1 % to 99.92 %, cutting new connections by a factor of 160 and saving an equivalent of 434 years of handshake time per day.

More Features

Pingora’s extensible design enables rapid addition of core capabilities such as HTTP/2 upstream support, paving the way for gRPC. The recent Cache Reserve feature integrates Cloudflare R2 storage as a caching layer, unlocking new product possibilities.

Higher Efficiency

Compared with the legacy service, Pingora consumes about 70 % less CPU and 67 % less memory under identical traffic loads. Rust’s performance and the multithreaded architecture eliminate costly Lua‑to‑C string copying and reduce lock contention associated with shared memory.

Greater Security

Rust’s memory‑safety guarantees protect Pingora from undefined‑behavior crashes. The codebase has processed trillions of requests without a single crash attributable to the service itself, and any rare failures have been traced to hardware or kernel issues rather than the proxy code.

Conclusion

Cloudflare has deployed Pingora as a faster, more efficient, and more flexible internal proxy platform that will serve current and future products. The company plans to open‑source Pingora after further maturation.