Cloudflare Web Application Firewall 可以在流量到達 WordPress 主機前檢查請求，配合託管規則、自訂規則和速率限制，減少常見漏洞掃描、暴力登入和惡意流量。防火牆不是「越嚴越好」；規則過廣會阻擋管理員、付款回傳或正常 API，因此應先觀察再逐步執行。
先確認網站流量真正經過代理
只有啟用 Cloudflare 代理的網站紀錄，HTTP/HTTPS 流量才會經過邊緣防火牆。檢查主網域和 www 的代理狀態、SSL 模式和來源主機。若來源 IP 仍公開並接受所有外部連線，攻擊者可能繞過 Cloudflare 直接存取主機。
理解託管規則與自訂規則
託管規則由平台維護，針對常見 Web 漏洞和已知攻擊模式；自訂規則則由站長按主機名稱、路徑、方法、IP、國家或其他請求欄位建立。先啟用適合網站的託管保護，再用自訂規則處理 WordPress 特定風險，避免重複和衝突。
先使用紀錄或挑戰觀察
新規則若直接 Block，可能在未發現前阻擋顧客。可先查看安全事件和規則命中，或在適合情況使用 Managed Challenge，讓平台按風險決定驗證。收集正常管理員、表單、付款和 API 流量後，再收緊條件。
保護 WordPress 登入頁
登入頁可加入速率限制、挑戰或來源條件，降低自動化密碼嘗試。不要只以改登入網址當成安全措施；仍要使用強密碼、雙重驗證和最低權限。若團隊使用固定辦公網絡，可考慮額外允許清單，但要準備 IP 改變時的後備入口。
小心處理 XML-RPC
不使用遠端發佈、Jetpack 或依賴 XML-RPC 的服務時，可考慮限制相關路徑；仍在使用則不能直接全面封鎖。先從安全事件確認請求來源和方法，再建立精確條件。錯誤規則可能令行動 App、同步或外部整合突然失效。
保護後台而不破壞必要請求
`wp-admin` 需要保護，但前台表單、AJAX、媒體和部分外掛也可能呼叫後台端點。不要用一條規則封鎖所有未登入請求。分清真正管理頁、`admin-ajax.php` 和 API 流量，並在測試環境驗證內容編輯、上載和結帳。
為敏感路徑建立速率限制
登入、重設密碼、搜尋、表單和昂貴 API 適合限制短時間重複請求。門檻要按正常使用量、共享網絡和行動電訊商 NAT 調整。過低會令同一公司或學校的多位訪客一起被限制；過高則無法有效減少資源消耗。
使用 Skip 例外要保持精確
付款供應商、監察服務或可信 API 可能需要跳過某些安全檢查。Cloudflare 自訂規則可用 Skip 略過指定功能，但條件應限制在必要主機、路徑、方法和可信身份，不要建立過廣的全站繞過。每個例外都記錄原因和到期檢查日期。
留意規則順序
自訂規則會按順序評估，部分動作執行後會停止後續處理。較精確的允許或例外條件通常應在廣泛阻擋前審慎安排，但仍要按實際規則引擎行為測試。修改順序後重新檢查付款、登入、Webhook 和管理操作。
不要單靠國家封鎖
若業務只服務特定地區，地理條件可減少無關流量，但 VPN、代理和雲端服務會令位置判斷不完全準確。付款回傳、搜尋爬蟲、員工出差和第三方 API 可能來自其他地區。地理規則應與路徑、風險和身份條件配合。
監察安全事件與誤判
定期查看命中規則、來源、路徑、動作和時間，找出持續攻擊與正常訪客誤判。保存變更紀錄，為重要規則建立清楚名稱和描述。若出現問題，先停用最近規則或改為觀察，不要一次關閉全部防護。
同時強化來源主機
WAF 不能取代 WordPress 更新、外掛管理、備份、惡意程式掃描和伺服器防火牆。來源主機應只開放必要服務，管理端使用雙重驗證，並限制可直接連線的來源。即使 Cloudflare 設定失誤，主機本身仍應有基本防護。
結語
WordPress WAF 的可靠流程是：確認代理、啟用合適託管規則、觀察流量，再為登入、API 和高成本路徑加入精確自訂規則。以測試、規則順序、有限例外和事件監察控制誤判，會比一次封鎖大量流量更安全。
