2026 年網頁防火牆（WAF）設定：Cloudflare WAF 防禦 DDoS
匹配路徑
/api/*
針對 API 端點
計數依據
IP 位址
免費用戶主要選項
門檻
10 秒內 50 次請求
依實際流量調整
動作
Block，持續 60 秒
過長會影響正常使用者
設定速率限制時，建議遵循三個原則：
登入與結帳頁要獨立設規則：這些端點的合理頻率遠低於一般頁面。
五、進階防禦組合：受管規則集、Bot 管理與 Turnstile
自訂規則寫得再好，也難以涵蓋所有已知的攻擊特徵。這時候就要靠 Cloudflare 的受管規則集與機器人管理。
5-1 受管規則集的取捨
進入 Security → WAF → Managed rules，你會看到幾個可用的規則集：
開啟受管規則集後，最容易遇到的問題是「誤判」。建議做法是：
先把整體模式設為 Log（僅記錄），觀察一週。
檢視 Security Events，找出被規則誤判的正常請求。
針對誤判的規則 ID，設定「Skip」或調整為較寬鬆的動作，而非整組關閉。
確認穩定後，才正式切換為 Block 模式。
很多站長一開啟 OWASP 規則集就發現網站後台不能用了，然後氣沖沖地把整組關掉——這是因噎廢食。正確做法是精準排除特定規則，保留其餘防護。
5-2 Bot 管理與 Turnstile 驗證
2026 年的網頁流量中，機器人佔比往往超過四成。Cloudflare 提供兩層工具：
Bot Fight Mode（免費版可用）：自動對已知的惡意機器人發出 JS 挑戰。開啟方式很簡單，在 Security → Bots 頁面打開開關即可。缺點是無法細部調整，且偶爾會影響合法的 API 呼叫。
Bot Management（付費方案）：提供 1 到 99 的機器人分數，你可以據此撰寫規則，例如：
(cf.bot_management.score lt 30 and http.request.uri.path contains "/api/")
動作設為 Managed Challenge。這樣既能擋掉自動化工具，又不會為難真人使用者。
Turnstile：這是 Cloudflare 推出的無干擾驗證服務，可以取代傳統的 reCAPTCHA。它不需要使用者點擊「我不是機器人」，而是在背景執行驗證。適合放在註冊頁、聯絡表單、評論區。重點是 Turnstile 有免費額度，對中小網站非常友善。使用方式是到 Cloudflare 儀表板建立一個 Turnstile widget，取得 Site Key 與 Secret Key，再整合到你的表單程式中。
六、監控、調校與誤判排除
規則上線不是結束，而是開始。接下來的工作是持續觀察與微調。
6-1 安全性事件分析流程
Cloudflare 的 Security Events 頁面會列出所有被規則處理過的請求。建議養成以下習慣：
每天花五分鐘看一次：特別注意被 Challenge 的請求中，是否有來自搜尋引擎或監控服務的 IP。
觀察趨勢而非單點：如果某天 Block 數量突然暴增十倍，先別急著慶祝，可能是你的某條規則太嚴格，也可能是攻擊開始了。
建立基準線：記錄正常日的請求數、被擋數、帶寬使用量，之後才有辦法判斷異常。
善用篩選：可以依規則 ID、動作、路徑、國家篩選，快速定位問題。
如果你使用 Business 以上的方案，可以開啟 Logpush 把 WAF 日誌匯出到 Google Cloud Storage、AWS S3 或 Splunk，進行更長期的分析與告警設定。
6-2 避免擋掉正常使用者與搜尋引擎
這是 WAF 設定最常踩的坑。以下是幾個實用技巧：
驗證 Googlebot 真偽：不要只用 User-Agent 判斷。Cloudflare 有內建的「Verified Bots」清單，可在規則中使用 cf.client.bot 欄位，或直接設定 Skip 規則。
保留 RSS 與社群預覽：Facebook、Twitter、LINE 的連結預覽抓取器常被誤擋。若你依賴社群分享，記得把它們加入允許清單。
注意付款閘道回呼：金流服務商的 webhook 通常來自固定 IP 段，務必加入白名單，否則會發生「客人付款了但訂單沒成立」的災難。
行動 App 與 API 客戶端：如果你的 App 走同一組 API，挑戰頁會讓 App 直接壞掉。建議 API 走獨立子網域，並改用 API Token 或 mTLS 驗證。
誤判處理要優雅：當正常使用者被擋時，Cloudflare 會顯示驗證頁。你可以在 Custom Pages 中自訂這個頁面，加入客服連結，減少客訴。
七、成本、效能與常見陷阱
最後談幾個實務上容易忽略的面向。
成本控制：Cloudflare 免費版沒有流量上限，但部分附加功能（如 Argo、進階 Bot 管理、Logpush）會依用量計費。速率限制規則若設定不當，可能導致大量正常使用者被擋，反而增加客服成本。建議每月檢視一次帳單與用量報表。
效能影響：WAF 規則的評估會增加幾毫秒的延遲，但相對於阻擋攻擊帶來的效益，這點延遲幾乎可以忽略。真正影響效能的是「快取策略」與「回源次數」。建議同時設定 Cache Rules，把靜態資源（圖片、CSS、JS）的 TTL 拉長，減少回源壓力。
常見陷阱一：只開 WAF 不關閉直連。如果你的主機 IP 曾經外洩（例如透過歷史 DNS 記錄查詢），攻擊者可以繞過 Cloudflare 直接打你的主機。建議設定防火牆只允許 Cloudflare 的 IP 段連入，或使用 Cloudflare Tunnel 完全隱藏來源。
常見陷阱二：規則越多越好。過度複雜的規則會增加維護困難與誤判機率。建議從五到十條核心規則開始，讓每一條都有明確目的，並定期清理不再需要的規則。
常見陷阱三：忽略行動版與 App 流量。很多站長只在電腦上測試規則，結果手機 App 使用者全部被擋。上線前務必用手機、平板、不同瀏覽器各測一輪。
常見陷阱四：沒有備援方案。Cloudflare 雖然穩定，但仍可能出現罕見的服務異常。建議保留一份「緊急切換流程」文件，記錄如何在必要時把 DNS 切回原始主機，並確認你的主機仍保有獨立防護能力。
八、常見問題 FAQ
Q1：免費版的 Cloudflare WAF 真的夠用嗎？
對大多數中小型網站來說，免費版搭配正確的自訂規則與 Free Managed Ruleset，已經能擋掉絕大多數的自動化攻擊。真正需要升級的時機是：你需要 OWASP 規則集、需要更多速率限制額度、或需要 Bot 分數來做精細判斷。
Q2：開啟 WAF 之後，Google 收錄會受影響嗎？
不會，前提是你沒有誤擋 Googlebot。建議在 Bot 管理中確認 Googlebot 為「Verified Bot」，並在自訂規則中不要對已知搜尋引擎套用挑戰。另外，避免長期開啟「I'm Under Attack」模式，因為那會影響爬蟲的抓取效率。
Q3：為什麼我設定了封鎖規則，攻擊還是打得進來？
三個常見原因：第一，來源 IP 沒有經過 Cloudflare（橘雲沒開或 DNS 被繞過）；第二，規則的評估順序不對，被前面的規則攔截或跳過；第三，攻擊使用的是合法請求格式，需要靠速率限制或 Bot 管理才能識別。建議從 Security Events 中查看實際的請求特徵，再對症下藥。
Q4：速率限制應該設多少才合理？
沒有標準答案，取決於你的網站類型。建議先開啟「僅記錄」模式運行一週，統計正常使用者的峰值，再把門檻設定在峰值的 3 到 5 倍。登入、註冊、結帳等敏感端點應另外設定更嚴格的限制。
Q5：Turnstile 和傳統驗證碼有什麼不同？
Turnstile 是一種「無感驗證」，多數情況下使用者不需要做任何操作就能通過。它透過瀏覽器指紋、行為訊號等判斷是否為真人，體驗遠優於要選圖片的傳統驗證碼，而且有免費額度。
Q6：我用了 Cloudflare 之後，網站變慢了怎麼辦？
通常是快取設定不當。檢查你的 Cache Rules 是否正確設定，靜態資源應長期快取，動態頁面則設定較短 TTL 或 Bypass。另外確認是否啟用了不必要的功能（例如 Rocket Loader 有時會與特定前端框架衝突）。
Q7：如果 Cloudflare 被攻擊或當機，我的網站會怎樣？
Cloudflare 的邊緣網路規模極大，全網癱瘓的機率極低。但個別節點或特定服務確實可能出現異常。建議定期備份 DNS 設定，並保留一份可直接切換回原始主機的操作手冊。
結語：防禦不是設定一次，而是持續的習慣
2026 年的網站防禦，已經從「買一台設備擺在機房」演變成「在雲端邊緣持續調校的一組策略」。Cloudflare WAF 提供了極低的進入門檻，但工具本身不會自動解決問題——真正決定防禦成效的，是你對自己網站流量特性的理解、對規則邏輯的掌握，以及持續觀察與調整的習慣。
如果你現在才剛開始，建議的行動順序是：先把網域接上 Cloudflare 並開啟橘雲；接著開啟 Free Managed Ruleset 與 Bot Fight Mode；然後設定一條登入頁的保護規則與一條 API 速率限制規則；最後養成每天查看 Security Events 的習慣。等你熟悉這些基本操作後，再逐步加入更細緻的自訂規則與 Turnstile 驗證。
記住一句話：最好的 WAF 規則，是既能擋住攻擊者、又不會打擾真實使用者的規則。而找到那個平衡點，靠的不是一次完美的設定，而是持續的觀察與微調。希望這篇教學能幫你在 2026 年建立起真正有效的網站防線。