XDP DDoS Mitigation in Production: Million-PPS Kernel-Native Defense, Built into OpenResty Edge

XDP DDoS mitigation is viable in production—without bypassing the kernel. OpenResty Edge ships DDoS protection built on XDP eBPF+: it drops attack packets at the earliest point of the Linux kernel data path, sustaining roughly 170k–180k PPS of small-packet SYN/UDP flood on a modest AWS t3.small and lab-validated million-scale PPS on a single machine—while normal traffic keeps flowing through the standard kernel network stack.

This article walks through the engineering trade-offs of XDP-based defense versus kernel-bypass and pure in-kernel designs, the multi-tier policy model with fine-grained SYN and DNS flood controls, and the observability that makes it operable in production.

The “impossible triangle” of DDoS mitigation architectures

When DDoS defense moves from a perimeter bolt-on to part of the system hot path, engineering teams face a long-standing “impossible triangle”—three goals that are hard to satisfy at once:

1. Peak throughput performance
2. Kernel and ecosystem compatibility
3. Long-term engineering maintainability

Existing approaches usually satisfy one or two, and pay in the third dimension.

Kernel-bypass designs: high performance at the cost of system integrity

To reach extreme performance under high-PPS attacks, one family of designs bypasses the kernel network stack and pushes defense logic right next to the NIC. The performance problem is solved, but the price is:

• The network path splits into two separate stacks
• Existing monitoring, diagnostics, and operations tools stop working
• The defense system itself becomes a hard-to-touch, special-case component

A one-time performance optimization trades away long-term system complexity and operational risk.

Pure in-kernel filtering: compatible but with a clear performance ceiling

Another family keeps defense strictly inside existing kernel frameworks—no change to the network architecture, no extra runtime, and full reuse of mature kernel mechanisms. That is easier to accept in engineering terms, but the processing path is fixed, and so is the performance ceiling.

Under truly high-frequency attacks, CPU quickly becomes the bottleneck; the defense stack may fail before the attack is fully identified.

DIY XDP programs: powerful in theory, hard to sustain in practice

In theory, the ideal is to place defense far enough forward without breaking system integrity—the do-it-yourself XDP/eBPF route is the canonical example. In practice, that path usually implies:

• Heavy dependence on OS versions and features
• Constrained programming models and execution environments
• Deploy, upgrade, and rollback procedures that resist standardization

Technically doable, but hard to replicate in engineering practice—and harder still to sustain for years at production scale. Once the system is stable, teams often keep their distance: nobody wants to touch a high-risk, high-maintenance core component.

How OpenResty Edge delivers XDP DDoS mitigation for all three goals

Our design philosophy is not about pushing the laws of physics; it is an engineering stance: without compromising kernel integrity, maximize use of the kernel’s cutting-edge data-path processing power. For each vertex of the impossible triangle, our principles answer as follows:

The question shifts from “can we go faster?” to whether single-machine million-scale PPS throughput together with fully dynamic complex defense policies can be deployed safely and reliably in production, and kept easy to manage and maintain.

Four-tier defense policies: from global baseline to a single NIC

OpenResty Edge organizes defense settings into four top-down tiers aligned with real topology, so large enterprises can separate responsibilities and administrative domains:

• Global: Set default upper- and lower-bound baselines for SYN PPS, DNS RPS, and similar metrics across the entire Edge network—a safety net for all downstream entities. Newly attached clusters inherit this tier’s baseline protection until individually tuned.
• Cluster: Isolate by workload or geography—for example, tune only a test cluster (such as test-yuannn) to match real traffic volume without affecting other clusters.
• Node: Target hardening for a single machine in the cluster. For a relatively underpowered server or a node under targeted fire (e.g. jenkins-slave-2), tighten or relax policy at this tier alone.
• Interface: Push defense down to a single NIC. In hybrid cloud or containerized environments, apply limits to specific interfaces (such as the cni0-style container NIC common in Kubernetes) to isolate and protect a slice of the microservice network.

Policy inheritance and override across tiers

When multiple tiers coexist, OpenResty Edge provides an inheritance mechanism to reduce duplicate configuration and misconfiguration risk:

• At tiers such as cluster or node, you can choose Inherit to adopt the parent tier’s defense policy wholesale, without re-entering every field.
• When a given node or interface needs an exception, switch it to modes such as Enabled or Disabled to override—delivering the operational model of one global default, with local customization where needed.

Fine-grained SYN flood protection and DNS flood protection controls

At interface scope and in the corresponding configuration panels, you can exercise fine-grained control over attack vectors, for example:

• SYN flood: In addition to global rate limits (min/max PPS), configure SYN rate per IP (SYN/IP/s) and ACK rate per IP (ACK/IP/s), and monitor and rate-limit specific ports (e.g. port 80).
• DNS flood: Cap aggregate queries per second (RPS) and queries per IP (DNS/IP/s); limit where policies take effect using Domains and IPv4 ranges to curb amplification and abuse with spoofed sources.
• Auto detect attack mode: With one-click enablement, the system, informed by live traffic models, decides whether to enter a defense-active state—aligning with the fully automated attack–defense closed loop described later.

XDP DDoS mitigation performance: measured numbers, not slogans

Performance should be a quantifiable, reproducible engineering fact—not marketing copy.

170k–180k PPS on an AWS t3.small: baseline cost-effectiveness

On a modest cloud instance (e.g. AWS t3.small), without dedicated hardware or unusual system tuning, we have measured stable handling of roughly 170k–180k PPS under small-packet UDP/TCP SYN flood workloads.

That figure shows how optimizing the data path with XDP eBPF+ and attaching at the right hooks in the kernel yields very high performance density on commodity hardware, avoiding the traditional pattern of horizontal scale-out with many instances or buying expensive purpose-built appliances. Customer workloads still use the operating system kernel’s ordinary network protocol stack for normal traffic—unlike many NIC-centric bypass designs where applications or edge services abandon the kernel stack to chase mitigation throughput. The gain comes from architecture plus tight engineering integration with fully dynamic complex defense policies—not from dedicated hardware.

Why performance headroom matters under real attacks

From observations of real attacks in production, typical attack traffic peaks around 30–40 Mbps. The configuration above sustains on the order of 100 Mbps (corresponding to roughly 180k PPS of small packets).

That gap—performance headroom—is essential. It means that during real attacks the system stays far below its processing ceiling, leaving ample buffer for monitoring, decision-making, and policy adjustment—predictable behavior and room to respond calmly.

Scaling to million PPS on a single machine

On higher-spec hardware, performance scales roughly linearly with CPU core count. In the lab we have validated single-machine throughput on the order of millions of PPS. This implies:

• Defense capacity can grow smoothly with hardware generations, protecting long-term investment.
• Even larger attacks call for incremental scaling, not a rip-and-replace architecture.

Automated DDoS response is a prerequisite, not a perk

The effectiveness of DDoS defense depends not only on peak performance, but also on the speed and accuracy of response.

Fully automated attack–defense transitions

The system is designed to deliver a closed loop of automated defense:

• Automatically detect attack traffic patterns and activate defense policies.
• In the console, Auto detect attack mode can be enabled for specific tiers so the system judges and intervenes based on live traffic characteristics.
• When the attack ends, policies are rolled back automatically and normal paths resume.

This delivers measurable benefits: significantly lower MTTR (mean response time), and it removes the delay and false positives that manual steps can introduce—turning security response into deterministic system behavior.

Systematic policy decisions

The built-in traffic analytics engine distinguishes attack vectors (such as abusive hostname requests and CC-style floods) and automatically selects appropriate defenses. Its core value is this: moving the decision of whether to block and how to block from human, expert-driven firefighting to repeatable, system-embedded decision logic.

Defense is baked into the platform, reducing reliance on individuals and improving stability for the whole team. For application-layer floods that get past the packet tier, the same gateway composes with rate limiting by custom keys and a built-in captcha challenge to absorb CC-style attacks.

Kernel-level malicious-IP bans: autonomous per-machine blocking, not hand-written iptables orchestration

Kernel-level banning of abusive source IPs is per-machine behavior: the deny list is not replicated cluster-wide as one identical global blacklist. On each machine, the Agent observes attacks as seen on that host; built-in platform logic automatically decides which source IPs to block and applies those rules in the local kernel. Different nodes can legitimately carry different blocked sets, depending on the attack surfaces each sees.

Meanwhile, policy is still centrally published from the Console: protection thresholds, toggles, and tier-wide orchestration still flow through Agents that automatically fetch changes, reconcile versions, and activate configuration. What this subsection clarifies is that exactly which IPs are blocked at any moment is decided on each machine from local telemetry—the Console does not push one fleet-wide blocklist.

That still contrasts with stacking iptables (or nftables) by hand: no SSH marathon to tweak chains, fragile one-off scripts, or runbooks that drift away from /etc; blocking decisions plus kernel enforcement close the loop locally inside the product, while the Console still provides unified observability and audit, versus the brittle model of manually curating firewall rules.

Observability: real-time DDoS mitigation metrics build trust

Any system on the core data path that behaves as a “black box” is itself a risk. Our design treats observability as a first-class concern.

Real-time telemetry includes:

• Attack status (yes/no)
• Identified attack type
• Live and cumulative packet drop and pass-through counts
• Kernel-side implementation health and resource usage

Below each tier’s defense settings in OpenResty Edge, an embedded Real-Time Metrics panel lets you compare policy and impact in one view: SYN- and DNS-related traffic for the current tier, such as Reply pps (replies per second), Dropped pps (drops per second), and states like Not Under Attack / Under Attack—so mitigation effects are visible immediately, not hidden behind a black-box security module.

This data ensures:

• Auditable policies: every defensive action is backed by evidence.
• Traceable troubleshooting: a single, reliable factual basis for diagnosis.
• Cross-team alignment: security, networking, and business stakeholders share a common vocabulary of facts.

Conclusion: a built-in, adaptive DDoS defense stack

The scale and complexity of network attacks keep increasing. The real architectural risk is often not the attack itself, but the heterogeneous bolt-on introduced to counter it—something alien to the rest of the stack—or brittle processes that still depend heavily on humans at the worst moment. We are fully aware that a security system with punitive operational overhead will not be accepted by engineering and operations teams. Delivering multi-tier policies as OpenResty Edge built-in capabilities is how we meet performance, compatibility, and operability inside a single product—without stacking another standalone “DDoS box” or a parallel operations surface. The same built-in philosophy extends up the stack to the programmable WAF.

• Console + Agent: Configure all policies in a centralized Console; Agents on each node pull and synchronize via API—no logging into servers one by one for manual changes.
• Progressive adoption: Start with non-core workloads or a single node as a pilot, validate results, then roll out to more servers and business lines in a smooth, controlled way.
• Complex-network fit: With network-namespace support, it works well in containerized environments (e.g. Docker, Kubernetes) or multi-tenant virtualization, applying independent defense policies per network interface.

An ideal DDoS defense architecture is a capability that integrates seamlessly, runs autonomously, and is robust in its own right. After deployment, technical leaders should be able to trust it to run on its own—not to dominate the on-call roster as a constant high-priority alert source. That is the core engineering problem this architecture sets out to solve.

FAQ: XDP DDoS mitigation

Can XDP be used for DDoS mitigation in production?

Yes. OpenResty Edge runs XDP eBPF+-based DDoS mitigation in production without bypassing the kernel: attack packets are dropped at the earliest point of the Linux data path, while normal traffic continues through the standard kernel network stack, keeping existing monitoring and operations tooling intact.

How many PPS can XDP-based DDoS mitigation handle?

On a modest AWS t3.small with no special tuning, we measured roughly 170k–180k PPS under small-packet UDP/TCP SYN flood workloads. Throughput scales roughly linearly with CPU cores; in the lab we have validated million-scale PPS on a single machine.

What is the difference between XDP and kernel-bypass DDoS protection?

Kernel-bypass designs push filtering next to the NIC and abandon the kernel network stack, splitting the path into two stacks and breaking existing tooling. XDP-based mitigation stays inside a standard Linux kernel—no bypass, no exclusive takeover—so compatibility with the network stack and ops toolchain is preserved.

How does eBPF DDoS protection work in OpenResty Edge?

Defense logic runs as XDP eBPF+ programs on the kernel’s fast data path, layered with fully dynamic defense policies that evolve at runtime. The platform provides a stable, manageable engineering environment instead of raw kernel interfaces, so teams get eBPF-level performance without the DIY engineering burden.

Does SYN flood protection support per-IP rate limits?

Yes. Beyond global min/max PPS limits, you can configure SYN packets per second per source IP (SYN/IP/s), ACK rate per IP (ACK/IP/s), and monitor and rate-limit specific ports such as port 80.

How do you mitigate DNS flood attacks?

Cap aggregate DNS queries per second and per-IP query rates (DNS/IP/s), and scope policies by domain and IPv4 ranges to curb amplification and spoofed-source abuse. Auto attack detection can activate these defenses based on live traffic models.

About The Author

Yichun Zhang (Github handle: agentzh), is the original creator of the OpenResty^® open-source project and the CEO of OpenResty Inc..

Yichun is one of the earliest advocates and leaders of “open-source technology”. He worked at many internationally renowned tech companies, such as Cloudflare, Yahoo!. He is a pioneer of “edge computing”, “dynamic tracing” and “machine coding”, with over 22 years of programming and 16 years of open source experience. Yichun is well-known in the open-source space as the project leader of OpenResty^®, adopted by more than 40 million global website domains.

OpenResty Inc., the enterprise software start-up founded by Yichun in 2017, has customers from some of the biggest companies in the world. Its flagship product, OpenResty XRay, is a non-invasive profiling and troubleshooting tool that significantly enhances and utilizes dynamic tracing technology. And its OpenResty Edge product is a powerful distributed traffic management and private CDN software product.

As an avid open-source contributor, Yichun has contributed more than a million lines of code to numerous open-source projects, including Linux kernel, Nginx, LuaJIT, GDB, SystemTap, LLVM, Perl, etc. He has also authored more than 60 open-source software libraries.