Cloudflare Rate Limiting Rules 可針對符合條件的請求計算速率，超出門檻後執行挑戰或封鎖。它適合降低 WordPress 登入暴力破解、API 濫用、搜尋抓取和高成本操作，但門檻設得過低也會阻擋共享網絡、行動用戶及正常整合。
先定義要保護的資源
列出 `wp-login.php`、XML-RPC、REST API、搜尋、表單、匯出、結帳或自訂高成本端點。每類請求的正常速率不同，不要用一條全站規則處理所有流量。
從實際流量找基準
在 Security Analytics 查看平日、高峰和攻擊時段，按路徑、來源及方法篩選。門檻應高於正常峰值並低於濫用模式，不能只抄其他網站的數字。
設定精確 Matching Expression
限制規則到正確主機、URI Path 和必要 HTTP Method。避免使用過廣的包含條件誤中圖片、管理 AJAX 或其他子路徑，建立後先以事件記錄驗證命中範圍。
選擇 Counting Characteristics
常見按來源 IP 計數，但多人共用公司、學校、電訊商 NAT 時會共用額度。較高方案可加入 Cookie、Header、API Key 或其他特徵，應選能代表真正客戶的組合。
設定 Period 與請求數
短時間門檻適合抑制密集爆發，較長期間可限制持續抓取。以端點成本和顧客操作節奏決定，並保留登入失誤、重新整理和付款回呼的合理空間。
選擇緩解動作
Managed Challenge 可讓部分真人繼續，Block 則更直接但誤判代價較高。新規則可先採較溫和措施或有限範圍測試，再依 Security Events 調整。
設定 Mitigation Timeout
逾時太短會讓機械流量立即重試，太長則令誤判用戶難以恢復。按攻擊持續時間和業務敏感度選擇，並準備客服辨識及臨時解除方法。
保護 WordPress 登入
只計算真正登入提交比所有登入頁瀏覽更精準，但可用欄位取決於方案。確認密碼管理器、雙重驗證、SSO、行動應用程式及管理員固定網絡仍可正常登入。
小心 XML-RPC 與 API
不要在未盤點前全面封鎖，因為行動程式、Jetpack、Webhook 或外部工具可能使用相關端點。依路徑、方法和已知整合分開規則，為可信服務保留受控例外。
避免阻擋付款與 Webhook
付款平台可能在短時間重試回呼，來源亦未必固定。對結帳和 Webhook 使用專用條件、簽署驗證和監察，不要把一般登入門檻直接套用到金流端點。
了解計數並非全網單一
Cloudflare 計數器按特徵組合及資料中心範圍運作，亦可能有偵測延遲，因此不能當成精確配額或財務控制。來源伺服器仍要有權限、驗證和資源保護。
檢查 Workers 子請求
同一 Zone 的 Workers 子請求在部分設定下可能另外計數，令規則比預期早觸發。若網站經 Workers 代理，從事件和欄位辨認子請求並按官方方法排除。
配合 WAF 與 Bot 防護
Rate Limiting 只處理速率，不判斷所有攻擊內容。配合 Managed Rules、自訂 WAF、Turnstile、強密碼和 2FA，並了解各安全功能的執行順序。
監察 SEO 與正常機械人
過廣規則可能影響已驗證搜尋機械人和網站索引。排除不需要限制的靜態及公開內容，觀察抓取錯誤、搜尋流量和已驗證 Bot 命中。
建立調整與回復流程
記錄規則目的、基準流量、門檻、動作、例外及負責人。每次改動後檢查 Security Events、來源負載和顧客報告；發生誤判時能快速停用或回復上一版本。
參考資料
[Cloudflare 官方：Rate Limiting Rules](https://developers.cloudflare.com/waf/rate-limiting-rules/)
[Cloudflare 官方：Find Appropriate Rate Limit](https://developers.cloudflare.com/waf/rate-limiting-rules/find-rate-limit/)
