The Deep Infrastructure Architecture of Cloudflare
A deep technical breakdown of Cloudflare's infrastructure: BGP Anycast routing, XDP/eBPF packet processing, Pingora proxy framework, Keyless SSL, and origin hardening strategies.
Hello everyone,
I hope you’re doing well and having a great day.
In this article, we’ll explore a topic that I found both interesting and worth sharing. My goal is to break it down in a practical and easy-to-follow way while highlighting the concepts that matter most from both a security and engineering perspective.
When network engineers and security architects look at Cloudflare, they don’t simply see a CDN or a web application firewall. They see one of the most sophisticated distributed systems operating on the Internet today.
Marketing materials often describe Cloudflare as a reverse proxy running on an Anycast network. While technically correct, that description barely scratches the surface. Behind the scenes lies a highly engineered platform built on commodity x86 servers, custom networking stacks, kernel-level optimizations, and globally distributed infrastructure capable of processing millions of requests every second.
In this article, we’ll move beyond the marketing terms and take a closer look at the low-level request lifecycle, traffic routing, packet processing, and architectural decisions that allow Cloudflare to operate at Internet scale.
Let’s get started.
1. Traffic Ingestion: BGP Anycast and Asymmetric Routing
Cloudflare announces its IPv4 and IPv6 prefixes from all of its global data centers simultaneously using BGP (Border Gateway Protocol) Anycast. Every edge node advertises the exact same IP addresses.
1
2
3
4
5
[ Internet Core / ISP Routers ]
/ | \
/ | \
[Edge: Cairo] [Edge: Frankfurt] [Edge: London]
(All advertising the same IP: 104.16.0.1)
While Anycast elegantly solves geographic latency by routing users to the nearest topological node, it introduces a massive engineering challenge: BGP Route Flapping.
If an internet backbone link fluctuates mid-session, packets belonging to an active TCP connection can suddenly be re-routed to a completely different Cloudflare data center. In standard architectures, this second data center would drop the packet and return a RST flag, because its local Linux kernel has no record of the initial TCP Three-Way Handshake.
The Solution: “Unimog” Layer 4 Load Balancing
To prevent connection termination due to BGP route shifts, Cloudflare routes internal edge traffic through a proprietary L4 Load Balancer called Unimog.
When a packet arrives at an edge node, Unimog checks the connection state. If the packet belongs to a TCP connection initiated at a different data center, Unimog encapsulates the packet and forwards it over an internal backbone mesh to the correct data center holding the actual TCP socket state.
2. Kernel-Level Packet Processing: XDP, eBPF
Once a packet passes the L4 boundary and hits an individual machine, passing it through the standard Linux network stack would destroy performance. A volumetric DDoS attack would immediately choke the kernel’s memory management and lock up the CPU.
To prevent this, Cloudflare processes packets at the lowest possible layer using XDP (eXpress Data Path) and eBPF (Extended Berkeley Packet Filter).
1
2
3
4
5
[ NIC Ring Buffer ] ──> [ XDP Driver Layer (eBPF) ] ──> (Drop L3/L4 DDoS)
│
[ Standard Linux Network Stack ]
│
[ User-Space: "Pingora" ]
The L3/L4 Mitigation Layer: Before the kernel allocates an sk_buff structure, custom eBPF programs running at the NIC driver level inspect packet headers. Volumetric floods, spoofed UDP packets, and malformed SYN floods are dropped here using minimal CPU cycles.
3. The Application Layer: Transitioning to Pingora
Once a valid TCP connection is established and the TLS handshake completes, the raw HTTP/HTTPS bytes must be interpreted. For over a decade, Cloudflare relied on a heavily customized NGINX variant.
Today, Cloudflare’s core data plane relies on Pingora, a custom-built, multi-threaded HTTP proxy framework written entirely in Rust.
1
2
3
4
5
6
[ User Request ] ──> [ Pingora (Rust Core) ]
│
┌───────────────┴───────────────┐
▼ ▼
[ WAF / Security Engine ] [ Quicksilver KV Store ]
(Lua / Rust-Wasm Pipeline) (Cache Policies & Config)
Inside the Pingora Request Pipeline:
The Security Engine (WAF execution): The WAF acts as an inline inspector within the Pingora pipeline. HTTP headers, URIs, and request bodies are processed through a highly optimized matching engine.
Global State Sync (Quicksilver): Cloudflare engineered Quicksilver, a low-latency, globally distributed Key-Value store. It propagates configuration changes worldwide within seconds, allowing Pingora to execute cache and routing lookups against local RAM rather than an external database.
4. Advanced Cryptographic Architectures: Keyless SSL
When handling HTTPS for enterprise customers, security compliance often prohibits companies from exporting private SSL/TLS keys outside their infrastructure.
Cloudflare solved this with Keyless SSL.
1
2
3
4
5
[ Client ] ──> [ Cloudflare Edge ] ────────────────────> [ Customer Infrastructure ]
│ (Performs TLS Handshake) │
│ │
└─> [ Cryptographic Session Request ] ─────> [ Keyless Keyserver ]
(Signs handshake via private key)
During a Keyless SSL TLS handshake, the Cloudflare edge node manages the entire session creation except for the step requiring the private key signature. The private key never leaves the customer’s premises.
TLS 1.3 and Zero Round-Trip Time (0-RTT)
Cloudflare prioritizes TLS 1.3 with 0-RTT. Returning clients can send encrypted HTTP data alongside their first TLS handshake packet.
To prevent Replay Attacks, Cloudflare allows 0-RTT exclusively for idempotent HTTP requests (GET) while holding stateful requests (POST, PUT) until the full handshake finishes.
5. Security Implications: The Bypassing Matrix
From an offensive and defensive perspective, understanding Cloudflare’s architecture shifts how security posture is evaluated.
1
2
3
[ Attack Path A: Through Cloudflare ] ──> (Block/Mitigate) ──> [ Cloudflare Edge ]
│
[ Attack Path B: Direct-to-Origin ] ────────────────────────────────────┴──> [ Origin ]
The Direct-to-Origin Vulnerability
Cloudflare is effective only if traffic is forced to route through it. If an attacker discovers your origin IP address, they can attack the backend directly, rendering the WAF and DDoS layers useless.
Hardening the Architecture
To defend against origin exposure:
Authenticated Origin Pulls (AOP): Configure your origin server to require Mutual TLS (mTLS), rejecting any handshake not signed by Cloudflare’s certificate.
IP Access Control Lists (ACLs): Implement firewall rules dropping all incoming traffic on ports 80 and 443 unless the source IP belongs to Cloudflare’s IP ranges.
Conclusion
Cloudflare’s success comes from rethinking how modern infrastructure should be built, optimized, and secured at scale.
From Anycast routing to kernel-level packet processing with XDP and eBPF, Cloudflare demonstrates how software engineering solves problems that once required specialized hardware. The transition to Pingora, Quicksilver, and Keyless SSL shows how distributed systems are evolving to meet Internet demands.
For security professionals, understanding these architectural decisions explains how defensive technologies operate, where weaknesses may exist, and why certain security controls are implemented.
The deeper we understand the systems powering the Internet, the better equipped we become to secure, assess, and improve them.
Thank you for taking the time to read this article.
I hope you found it useful and learned something new.
Until the next article, stay curious and keep learning.
— Abdulrahman Mohamed
ء
References & Further Reading
- Cloudflare Blog: How we built Pingora
- Cloudflare Blog: Keyless SSL
- Cloudflare Blog: eBPF and XDP
- Cloudflare Docs: Authenticated Origin Pulls
- Cloudflare IP Ranges
Let’s Connect
Have a question, suggestion, or topic you’d like to discuss?
Abdulrahman M. Fathi