OpenResty Edge 内建了 DDoS 防护能力。它不是一个独立的安全产品，而是平台基础设施的一部分，与网关、节点、Agent 共享同一套交付和运维体系。其核心目标是在不破坏内核完整性的前提下，将千万级 PPS 的防护能力直接内建到生产环境中。本文将介绍这套防护体系的设计思路、多级防护机制与控制台能力。在此之前，我们先简要回顾它所针对的核心工程问题。

1. DDoS 防护的"不可能三角"

当 DDoS 防护从外围补丁变成系统核心路径的一部分，技术团队通常面临一个长期存在的"不可能三角"——以下三个目标难以同时达成：

1. 极限吞吐性能
2. 内核与生态兼容性
3. 长期工程可维护性

现有方案往往只能满足其中一到两个，同时在第三个维度上付出代价。

1.1 旁路内核方案：高性能但牺牲系统完整性

为了在高 PPS 攻击下获得极致性能，一类方案选择绕过内核网络栈，将防护逻辑直接推到网卡附近。性能问题被解决了，但代价是：

• 网络路径被分裂为两套体系
• 现有的监控、诊断、运维工具失效
• 防护系统本身变成一个难以触碰的特殊组件

一次性能优化，换来了长期的系统复杂度和运维风险。

1.2 纯内核方案：兼容性好但性能天花板明显

另一类方案将防护逻辑严格限制在现有内核框架内——不改变网络架构，不引入额外运行时，完全复用成熟的内核机制。这种方式工程上更易接受，但系统的处理路径已经固定，性能上限也随之固定。

在真正的高频攻击下，CPU 很快成为瓶颈，防护系统甚至可能在攻击尚未被完全识别之前就先行失效。

1.3 混合方案：理论可行但工程复杂度难以控制

理论上最理想的状态是防护足够靠前、同时又不破坏系统完整性。但现实中，这条路往往意味着：

• 对操作系统版本和特性的强依赖
• 受限的编程模型和执行环境
• 部署、升级和回滚过程难以标准化

技术上可行，但工程上难以复制，更难以在大规模生产环境中长期维护。 系统一旦稳定运行，团队往往对它"敬而远之"——没有人愿意轻易触碰一套高风险、高维护门槛的核心组件。

2. OpenResty Edge 的设计选择：让三个目标同时达成

我们的设计思路并非挑战物理极限，而是选择一个更具工程价值的技术定位：在不破坏内核完整性的前提下，最大化利用内核最前沿的数据处理能力。 针对上述不可能三角的三个维度，我们的设计原则逐一给出回应：

我们关注的核心问题从“能否更快”转变为：能否将千万级 PPS 的处理能力，安全、稳定地部署在生产环境中，并使其易于管理和维护。

2.1 「四级联防」：从全局基线到单块网卡

OpenResty Edge 将防护配置划分为四个自上而下、与真实拓扑对齐的维度，便于在大型企业环境中分责、分域管理：

• 全局级别（Global）：设定整个 Edge 网络的默认 SYN PPS、DNS RPS 等上限与下限基线，作为所有下游实体的安全兜底；新接入的集群若暂未单独调参，也会继承这一层的基础防护。
• 集群级别（Cluster）：按业务或地域隔离。例如可针对某一测试集群（如 test-yuannn）按实际业务体量单独微调防护参数，而不影响其他集群。
• 单机节点级别（Node）：对集群内单台机器定向加固。若某台服务器性能相对薄弱或正遭受定向打击（如节点 jenkins-slave-2），可在该层级独立收紧或放宽策略。
• 网络接口级别（Interface）：防护可下沉到单块网卡。在混合云或容器化场景中，可对特定接口（如 Kubernetes 环境中常见的 cni0 等容器网卡）单独设限，实现对某段微服务网络的隔离与保护。

2.2 配置继承与按需覆写

在多层级并存时，OpenResty Edge 提供 继承（Inherit） 机制，降低重复配置与误配风险：

• 在集群或节点等层级，可选择 Inherit，直接沿用上一级的防护策略，无需逐项重填。
• 当某一节点或接口需要例外处理时，再将其切换为 Enabled 或 Disabled 等模式进行覆写，实现 「全局统一缺省、局部按需定制」 的运维心智模型。

2.3 SYN 与 DNS Flood 的精细化参数

在接口级及相应配置面板中，可对向量做细粒度控制，例如：

• SYN Flood：除全局限速（最大/最小 PPS）外，还可配置 每 IP 的 SYN 速率（SYN/IP/s）、每 IP 的 ACK 速率（ACK/IP/s），并可对特定端口（如 80）单独监控与设限。
• DNS Flood：可限制整体 每秒查询率（RPS）、每 IP 查询率（DNS/IP/s），并支持限定生效的 域名（Domains） 与 IPv4 地址范围，以抑制伪造源地址的放大与滥用类攻击。
• 自动检测模式（Auto detect attack mode）：一键开启后，系统会结合实时流量模型自动判断是否进入防护介入状态，与下文所述的全自动攻防闭环相呼应。

3. 性能不是口号，而是工程事实

性能应是可量化、可复现的工程事实，而非市场口号。

3.1 基准性能与成本效益

在一台低规格的云主机（以 AWS t3.small 为例）上，不依赖任何专用硬件或特殊的系统配置，我们的系统在处理小包 UDP/TCP SYN Flood 时，实测可稳定处理 17-18万 PPS 的流量。

这一数据表明，通过优化数据路径和选择正确的架构位置，可以在通用硬件上实现极高的性能密度，避免了通过大量实例进行水平扩展或采购昂贵专用硬件的传统模式。性能提升源于架构设计，而非硬件堆砌。

3.2 防御冗余（Headroom）的价值

根据对线上真实攻击的观测，典型的攻击流量峰值约为 30–40 Mbps。而上述配置的系统可稳定处理约 100 Mbps（对应约 18 万 PPS 的小包流量）的攻击。

这个差值，即“性能冗余”至关重要。它意味着在真实攻击发生时，系统远未达到其处理极限，为监控、决策和策略调整预留了充足的缓冲空间，确保了系统的确定性和响应的从容。

3.3 架构的可扩展性

在更高规格的硬件上，系统性能可随 CPU 核心数近似线性增长。我们的架构设计已在实验室环境中验证了处理千万级 PPS 流量的能力。这意味着：

• 防护能力可以随硬件迭代平滑升级，保护了长期投资。
• 未来即使面临更大规模的攻击，也无需进行颠覆性的架构重构。

4. 自动化不是“加分项”，而是 DDoS 防护的前提

DDoS 防护的有效性，不仅取决于峰值性能，更取决于响应速度和准确性。

4.1 全自动攻防转换

系统设计目标是实现自动化防御闭环：

• 自动检测攻击流量模式，触发防御策略。
• 在控制台侧，还可为具体层级开启 自动检测攻击模式（Auto detect attack mode），由系统依据实时流量特征自动判断并介入。
• 攻击结束后，自动回撤策略，恢复常规路径。

这直接带来了可量化的收益：显著降低 MTTR（平均响应时间），并消除了人工干预可能引入的延迟和误判，使安全响应成为一个确定性的系统行为。

4.2 策略决策的系统化

系统内置的流量分析引擎能够区分不同攻击向量（如非法域名请求、CC 攻击等），并自动匹配最优防御策略。其核心价值在于：将“是否拦截、如何拦截”的判断，从依赖人类专家的应急响应，转变为系统内置的、可重复执行的决策逻辑。

这意味着防护能力被固化为平台能力，降低了对特定安全专家的依赖，提升了团队整体的稳定性。

5. 可观测性：透明是信任的基础

任何运行在核心数据路径上的系统，如果是一个“黑盒”，其本身就是潜在的风险源。我们的系统设计将可观测性作为一级公民。

提供的实时遥测数据包括：

• 攻击状态（是/否）
• 识别的攻击类型
• 实时/累计丢包数与通过数
• 内核侧实现运行状态与资源消耗

在 OpenResty Edge 的各层防护配置界面下方，还内嵌 Real-Time Metrics（实时指标） 面板，便于在同一视图中对照策略与效果：可查看当前层级的 SYN、DNS 相关流量概况，例如 每秒回复数（Reply pps）、每秒丢弃数（Dropped pps），以及系统是否处于 未受攻击（Not Under Attack）/ 正受攻击（Under Attack） 等状态，使防护效果所见即所得，避免“黑盒式”安全模块。

这些数据确保了：

• 策略可审计：所有防御动作都有据可查。
• 故障可追溯：为问题排查提供了统一、可靠的数据基础。
• 跨团队协同：为安全、网络、业务团队提供了共同的事实语言。

6. 结论：构建一个内建、自适应的防护体系

网络攻击的规模和复杂性在持续增加。真正的架构风险，并非来自攻击本身，而是来自为应对攻击而引入的、与现有体系格格不入的“异构系统”，或是那些在关键时刻高度依赖人工介入的脆弱流程。我们非常清楚，安全系统如果引入过高的运维成本，是不会被开发和运维团队所接受的。将上述 多级策略 以 OpenResty Edge 内建能力 交付，正是为了在单一产品边界内同时满足性能、兼容性与可运维性，而不是再叠加一套独立的“DDoS 盒子”或平行运维面。

• Console + Agent 模式：你可以在中心化的 Console 上配置所有策略，各个节点上的 Agent 会通过 API 自动拉取和同步，无需逐台登录服务器进行人肉操作。
• 渐进式接入：你可以先从非核心业务、单个节点开始试点，验证效果后再逐步推广到更多服务器和业务线，整个过程平滑可控。
• 复杂网络适配：通过对网络命名空间的支持，它能很好地在容器化（如 Docker, k8s）或多租户虚拟化环境中，为不同的网络接口提供独立的防护策略。

一个理想的 DDoS 防护架构，应当是：一个能够无缝集成、自主运行、且自身足够稳固的系统能力。部署后，技术负责人可以信任其自主运行，而不是将其列为值班表上需要高度关注的告警源。这正是我们通过此架构设计所致力于解决的核心工程问题。

关于作者

章亦春是开源 OpenResty^® 项目创始人兼 OpenResty Inc. 公司 CEO 和创始人。

章亦春（Github ID: agentzh），生于中国江苏，现定居美国湾区。他是中国早期开源技术和文化的倡导者和领军人物，曾供职于多家国际知名的高科技企业，如 Cloudflare、雅虎、阿里巴巴, 是 “边缘计算“、”动态追踪 “和 “机器编程 “的先驱，拥有超过 22 年的编程及 16 年的开源经验。作为拥有超过 4000 万全球域名用户的开源项目的领导者。他基于其 OpenResty^® 开源项目打造的高科技企业 OpenResty Inc. 位于美国硅谷中心。其主打的两个产品 OpenResty XRay（利用动态追踪技术的非侵入式的故障剖析和排除工具）和 OpenResty Edge（最适合微服务和分布式流量的全能型网关软件），广受全球众多上市及大型企业青睐。在 OpenResty 以外，章亦春为多个开源项目贡献了累计超过百万行代码，其中包括，Linux 内核、Nginx、LuaJIT、GDB、SystemTap、LLVM、Perl 等，并编写过 60 多个开源软件库。

关注我们

如果您喜欢本文，欢迎关注我们 OpenResty Inc. 公司的博客网站 。也欢迎扫码关注我们的微信公众号：

翻译

我们提供了英文版原文和中译版（本文）。我们也欢迎读者提供其他语言的翻译版本，只要是全文翻译不带省略，我们都将会考虑采用，非常感谢！