在同一套 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. 公司的部落格網站 。也歡迎掃碼關注我們的微信公眾號：

我們的微信公眾號

翻譯

我們提供了英文版原文和中譯版（本文）。我們也歡迎讀者提供其他語言的翻譯版本，只要是全文翻譯不帶省略，我們都將會考慮採用，非常感謝！