在同一套 208 条安全规则全部开启、仅使用 1 个 CPU 核心的条件下，OpenResty Edge 仍能保持约 5300 RPS 的吞吐量——是 ModSecurity Nginx 版（约 1400 RPS）的 3.7 倍，且随着请求复杂度增加，差距会拉大到 10 倍以上。原因在于：规则被编译成对请求数据的单趟扫描，而不是逐条解释执行。

本文将完整呈现这组 WAF 性能基准数据，解析其背后的编译器技术（正则规则合并为单一 DFA、EdgeLang 全局规则优化），并给出在边缘部署 WAF 的四个步骤。

申请试用 OpenResty Edge

基准测试：单核 CPU 上的 208 条 WAF 规则

OpenResty Edge WAF 与 ModSecurity for Nginx 的 RPS 性能对比图：单核加载 208 条规则，随 URI 参数数量增加的吞吐量变化

测试设置：

  • 1 个 Worker 进程，使用 1 个 CPU 核心
  • 所有系统加载并完整启用同一套 208 条 WAF 规则
  • 对比对象：OpenResty Edge WAF 与 ModSecurity Nginx 版，同时测量了 ModSecurity Apache 版和 OpenResty 上的 lua-resty-waf
  • 测量指标：每秒请求数（RPS，y 轴）随每个请求的 URI 参数数量（URI Args，x 轴）增加的变化——参数越多，WAF 需要检查的请求数据越多

之所以以 ModSecurity Nginx 版为主要对比对象，是因为它至今仍是自建 Nginx WAF 的事实基线。

测试结果：

  • 1 个 URI 参数时： OpenResty Edge 的吞吐量（约 5300 RPS）已经是 ModSecurity Nginx 版（约 1400 RPS）的 3.7 倍。
  • 20 个参数时： ModSecurity 的性能急剧下降——吞吐量跌至约 150 RPS，服务器资源被耗尽。
  • 100 个参数时： 即便在这样的极端负载下，OpenResty Edge 依然保持在 1500 RPS 左右——这个数字比 ModSecurity 在最轻负载下的表现还要好。

这在实践中意味着：

用户体验： 在同等硬件、全量 208 条规则开启的条件下，你无需在安全性和速度之间做妥协——用户获得完整的 WAF 防护，网站不会因此变慢。

成本： OpenResty Edge 仅用 1 个 CPU 核心即可达到竞品需要几个甚至十几个核心才能支撑的吞吐量。用更少的核心承载更多流量，直接缩减集群规模，降低 AWS/GCP/Azure 的月度账单。

为什么规则数量不必拖慢 WAF 性能

传统 WAF 受限于静态配置文件或低效脚本，规则被逐条顺序求值：每增加一条规则，就多一次对请求数据的扫描，延迟随规则集规模增长。上面的基准测试展示了另一条路——提前把整个规则集编译好，无论加载多少条规则，请求数据都只扫描一次。

用 EdgeLang 将规则编译为网关原生代码

OpenResty Edge 引入了我们自主研发的 EdgeLang——一种专为高性能网关设计的领域特定语言（DSL）。它比手写 Lua 代码更简洁，也更快：

  • 高效代码生成： EdgeLang 编译器会将你的规则编译为高度优化的 Lua 代码，在网关服务器上执行。借助算法优化和精细的代码生成策略，其实际运行速度通常快于手写的 Lua 代码。
  • 全局规则优化： 编译器不会逐条执行规则，而是对所有规则进行整体的整合与优化，简化整个规则集范围内的复杂交互。

无论多少条规则，请求只扫描一次

两项匹配技术将规则数量与扫描开销解耦：

  • 正则表达式合并（Regex Merging）： 编译器将所有正则表达式规则合并为一个完整的确定性有限自动机（DFA）。无论规则有多少条，系统只需扫描一次请求数据，即可找出所有匹配的规则及其位置。
  • 前缀后缀树（String Trees）： 所有常量字符串的前缀和后缀模式被组合成统一的高效树状数据结构，以加速查找。

这就是规则集规模不再构成性能瓶颈的原因。

扩展性不以性能为代价

EdgeLang 不是一座孤岛。它支持直接调用自定义 Lua 模块和代码，让你能复用现有业务逻辑；同时内置了丰富的预编译库，涵盖常见的安全防护、数据处理和网络操作功能。你可以编排复杂的、感知业务的安全策略，而不必交还编译器换来的性能。

不关规则也能控制 WAF 误报

面对 WAF 误报这个行业普遍难题，我们提供了多级敏感度调整机制，让运维团队根据当下场景灵活应对，而不是直接关闭规则：

  • 攻防演练 / 渗透测试期： 提升敏感度到严格模式，宁可多拦截也要确保安全。
  • 业务高峰期： 降低敏感度到平衡模式，减少对正常用户的影响。
  • 日常运营期： 使用标准模式，在安全性和可用性之间取得平衡。

通过实时调整敏感度等级，将误报对业务的影响降到最低。这不是完美的解决方案，但确实是目前最实用的应对策略。

如何在边缘部署 WAF：四个步骤

第一步：奠定全局安全基石

在为具体应用配置防护之前，先建立一套统一的全局 WAF 规则。这为您的所有服务提供了一个基础的安全水位，能高效拦截常见的、大范围的攻击。

如何设置全局 WAF 规则

第二步：为核心应用开启专属防护

全局规则建立后，为您最重要的应用开启 WAF 功能。只有开启后，您设置的规则（无论是全局还是应用专属）才会真正生效。开启应用的 WAF。

第三步：精准放行，避免业务干扰

开启 WAF 防护后，正常的业务请求有时可能被误拦。为了确保业务连续性，请设置白名单，精准地将可信请求排除在拦截规则之外。

如何设置应用的 WAF 白名单

第四步：编写自定义规则，获得完全的灵活性

对于复杂业务场景或高级安全需求，标准 WAF 规则可能不够灵活。通过 EdgeLang，您可以基于请求的任意参数（如 Header、Cookie、URL 等）编写动态、精细的 WAF 规则，实现高度定制的防护逻辑。

使用 Edgelang 定义 WAF 规则

按这几步走下来，您将获得一个从全局到局部、从通用到定制的完整防御体系。

CDN、WAF、API 网关合一：一体化架构的优势

传统架构把 WAF 当作夹在各个设备之间的独立边界防御工事。OpenResty Edge 则构建了一个集私有 CDN、WAF 与 API 网关于一体的融合式平台，每一层各司其职：

  • CDN——最外层： 将静态资源缓存在离用户最近的位置，并凭借分布式带宽在流量抵达任何后端之前吸收大规模 L3/L4 DDoS 洪水攻击。它是 WAF 的第一道防线。
  • WAF——检测层： 紧随 CDN 之后（或内嵌于 CDN 节点之中），对每一个请求进行威胁排查——SQL 注入、XSS、恶意 Cookie——无论请求指向哪个后端。
  • API 网关——业务层： 对请求做身份验证（OAuth/JWT），将其路由到正确的微服务，并按用户或 API 执行精细化的配额管理。

由于这三层都运行在同一个 Worker 进程内，这套架构带来两个实打实的收益：

  • 组件之间零网络跳转： 在分离式架构中，流量需要在 CDN、WAF、网关设备之间多次跳转，每次跳转都引入额外的网络 I/O 和延迟。在一体化模型中，缓存、安全检测和路由都在同一个 Worker 进程内完成——数据在各层之间不跨越任何网络边界，这对延迟敏感型业务尤为关键。
  • 只需运维一个平台： 管理多套异构系统意味着各自独立的配置、监控、升级和故障排查。统一的技术栈意味着一个平台即可覆盖边缘流量的全生命周期。

建立在这套架构之上，安全不再是外挂在交付链路上的外部约束：规则编译为原生代码，防护逻辑不会成为性能瓶颈；安全策略也可以感知它所保护的业务上下文。

FAQ：WAF 性能

WAF 会让服务器慢多少？

这取决于 WAF 如何执行规则。逐条解释规则的引擎会随规则数量和请求复杂度增加而性能骤降——在我们的基准测试中，随着 URI 参数从 1 个增加到 20 个，ModSecurity Nginx 版从约 1400 RPS 跌到约 150 RPS。而像 OpenResty Edge 这样对每个请求只扫描一次的编译型 WAF，在开启 208 条规则、100 个参数的情况下仍保持约 1500 RPS。

WAF 规则数量会拖慢请求吗？

对传统的顺序执行引擎来说，会——每条规则都是对请求数据的一次额外扫描。OpenResty Edge 消除了这种耦合：EdgeLang 编译器将所有正则规则合并为单一 DFA、所有常量字符串模式合并为一棵树结构，无论加载多少条规则，请求数据都只扫描一次。

OpenResty Edge 比 ModSecurity 快多少？

在相同硬件（1 个 CPU 核心、开启 208 条规则）下，最简单场景中 OpenResty Edge 保持约 5300 RPS，而 ModSecurity Nginx 版约 1400 RPS——3.7 倍。随着请求复杂度增加，差距扩大到 10 倍以上：URI 参数达到 20 个时 ModSecurity 接近 150 RPS，而 OpenResty Edge 在 100 个参数时仍有约 1500 RPS。

为什么要在边缘而不是源站运行 WAF？

边缘 WAF 在流量进入源站基础设施之前就完成检测，攻击在靠近其发起位置的地方被拦截，源站不必为恶意请求消耗任何资源。在 OpenResty Edge 的统一架构中，CDN 层还会先吸收大流量的 L3/L4 DDoS 攻击，且 WAF 检测与缓存、路由运行在同一个 Worker 进程内——安全层不引入额外的网络跳转。

如何在不关闭规则的前提下减少 WAF 误报？

OpenResty Edge 中有两个机制协同工作：多级敏感度（攻防演练期用严格模式、业务高峰期用平衡模式、日常运营用标准模式）让你实时调整拦截力度；应用级白名单则精准地将可信请求排除在拦截规则之外，同时对其余流量保持完整防护。

关于 OpenResty Edge

OpenResty Edge 是一款专为微服务和分布式流量架构设计的全能型网关软件，由我们自主研发。它集流量管理、私有 CDN 构建、API 网关、安全防护等功能于一体，帮助您轻松构建、管理和保护现代应用程序。OpenResty Edge 拥有业界领先的性能和可扩展性，能够满足高并发、高负载场景下的苛刻需求。它支持调度 K8s 等容器应用流量，并可管理海量域名，轻松满足大型网站和复杂应用的需求。

申请试用 OpenResty Edge

关于作者

章亦春是开源 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. 公司的博客网站 。也欢迎扫码关注我们的微信公众号：

我们的微信公众号

翻译

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