多數人以為，只要在 Cloudflare 後台建一條 WAF 自訂規則，把動作設成 Skip，就能讓網站監控工具、SEO 稽核工具跳過機器人防護的攔截。其實這條路只有付費的 Super Bot Fight Mode 走得通，免費版的 Bot Fight Mode 從架構上就不吃這一套規則。
不少中小型網站開了 Bot Fight Mode 之後，隔天發現網站監控服務回報連線異常，Google Search Console 也開始出現爬蟲存取受阻的提示，甚至自己付費訂閱的 SEO 稽核工具連續好幾天抓不到資料。回頭到 Security 分類底下想建一條允許規則放行，設定介面看起來明明存在，儲存也順利完成，實際測試卻發現那些工具照樣被擋。問題不是規則寫錯，是這兩套防護原本就不在同一個地方運作。
Bot Fight Mode 是 Cloudflare 內建在免費方案裡的機器人偵測產品，專門攔截已知機器人特徵的流量；WAF 自訂規則則是另一套讓使用者自己寫表達式、決定動作的規則引擎，兩者雖然都掛在 Security 選單底下，實際上分屬兩套完全不同的評估機制。搞懂這個底層差異，才知道自己的網站該從免費版硬著頭皮取捨，還是該升級到 Super Bot Fight Mode 換取設定例外的空間，也才不會把時間耗在一條永遠生效不了的規則上。
Bot Fight Mode 與 WAF 自訂規則，管的是不同防護引擎
Cloudflare 把機器人防護拆成三個產品，分屬不同訂閱層級。免費方案就內建的是 Bot Fight Mode，需要 Pro、Business 或 Enterprise 訂閱才能用的是 Super Bot Fight Mode，只對 Enterprise 客戶開放、控制粒度更細的則是 Bot Management for Enterprise。三者名字相近，實際能調整的項目卻不一樣，愈往企業端走，可設定的分類、動作與例外規則就愈多。
WAF 自訂規則是完全不同的另一套東西。使用者自己寫一段表達式，描述想比對的流量特徵，像 User Agent、來源 IP、國別、路徑等等，再指定命中之後要執行的動作，例如封鎖或放行。它不是專為機器人設計的產品，而是一套通用的規則引擎，什麼樣的流量條件都能寫進去。
這類攔截判斷並不是無的放矢。Cloudflare 在 2026 年的全球威脅形勢報告裡指出，過去三個月，所有登入嘗試中已經有 94% 目前來自機器人，其中 63% 涉及在其他地方就已經外洩過的憑證。換句話說，一個網站的登入頁面，九成以上打進來的流量早就不是真人，擋不擋機器人已經不是「要不要」的問題，而是「用哪一套方式擋」的問題。
多數網站其實兩者都會用到。Bot Fight Mode 負責擋掉那些特徵明確、已經被 Cloudflare 資料庫記錄過的已知機器人，不需要自己動手設定；WAF 自訂規則則處理「自己判斷該擋」的特定流量，例如把特定國家的請求擋在外面，或針對某條容易被掃描的路徑加一層防護。兩套機制平行運作，理論上互不干涉，但正是這個「平行」，埋下了後面 Skip 救不了 Bot Fight Mode 這個問題的根源，它們根本不共用同一套評估流程，一邊的動作自然影響不到另一邊。
免費方案內建的 Bot Fight Mode 開關和攔截邏輯
Bot Fight Mode 開啟的路徑不難找。登入 Cloudflare Dashboard，選定要保護的網域，進入 Security 底下的 Settings 頁面，用 Bot traffic 這個篩選條件就能找到 Bot Fight Mode 的開關，點下去立即生效，不需要額外訂閱或加購。
它的偵測邏輯，是拿現有請求的特徵去比對一份已知機器人模式的清單，只要流量符合那份清單裡記錄的行為特徵，就會被判定為機器人，收到一個運算量很吃重的挑戰，要求發送端的裝置執行高強度的運算才能通過驗證。對一般瀏覽器來說，這個運算幾乎感覺不到延遲，但對很多寫死邏輯、沒有能力執行複雜運算的自動化腳本，這道關卡就直接卡死通行。
Cloudflare 官方文件也提醒一個實務眉角，Bot Fight Mode 沒有例外設定，開啟後可能連帶把 API 或行動應用程式送出的合法流量一併判定為挑戰對象。免費版沒有分類設定，一旦開啟就是整批適用同一套判斷邏輯，付費版才會把這套邏輯拆成好幾個可以分別調整的分類。如果一個網站本來就仰賴大量第三方自動化工具運作，包括監控探針、爬蟲、串接的 API，開啟之後最好回頭到 Security 底下的 Analytics，切到 Events 分頁查看，被這項功能攔下的請求會在 Service 欄位標示為 Bot Fight Mode，藉此觀察一段時間的流量趨勢，及早抓出被誤判的合法工具，免得之後要排查某個工具為什麼突然失靈，反而多花更多時間。
Super Bot Fight Mode 的六個分級開關
Super Bot Fight Mode 是 Bot Fight Mode 的付費升級版，需要 Pro、Business 或 Enterprise 其中一種訂閱才能使用。它跟免費版最大的差異，不在偵測技術本身，而在於把免費版一刀切的判斷邏輯拆成六個可以個別設定回應方式的分類，設定頁面上每一項旁邊都有一個編輯圖示，可以單獨決定這一類流量要被擋下、被質詢，還是直接放行。
六個分類分別是確定自動化的流量、疑似自動化的流量、已驗證機器人、靜態資源保護、JavaScript 偵測，以及針對 WordPress 網站調整過的最佳化選項。這六項合起來，等於把免費版一律用同一套邏輯判斷、一律用同一種方式處理的做法打開，讓管理者可以照自己網站的實際狀況分別拿捏。
流量分級三檔，確定自動化、疑似自動化與已驗證機器人
前三個分類，處理的是風險程度不同的流量該怎麼分別對待。確定自動化的流量，是 Cloudflare 判定信心度最高的一批，通常可以直接設定成封鎖或質詢等級較高的動作；疑似自動化的流量則帶著一定的不確定性，行為特徵接近機器人，但沒有到確定的程度，這種情況下給予強度較輕的挑戰，比直接封鎖更不容易誤傷正常使用者。
已驗證機器人這一檔的角色正好相反，是 Cloudflare 自己維護、已經確認身分的合法自動化服務，Googlebot、Bingbot 這類搜尋引擎爬蟲都在其中。這一檔的設定邏輯應該反過來朝放行調整，因為擋掉它們的代價，是網站在搜尋引擎那端的收錄與排名跟著受影響。Cloudflare 官方文件確認這三個欄位存在於設定頁面，但沒有公開每一項的預設回應方式；實際操作時，依風險分級調整是合理的做法，確定自動化的可以設得嚴格一點，已驗證機器人建議設為允許，疑似自動化的流量則留一點緩衝空間，不必一開始就用最重的動作。
靜態資源保護和 WordPress 最佳化兩個加值開關
除了流量分級，Super Bot Fight Mode 還多出兩個進階選項。靜態資源保護把偵測範圍延伸到圖片、CSS、JavaScript 這類靜態檔案，免費版通常只顧得到動態頁面請求，靜態資源常常被自動化工具當成偷跑的路徑，這個開關等於把防護的網撒得更廣。
Optimize for WordPress 則是針對 WordPress 網站的特性做過調整的選項，原理上是照 WordPress 常見的攻擊模式，例如集中掃描 wp-login.php 這類固定路徑，去調整判斷邏輯。Cloudflare 官方文件只確認這兩個項目存在於設定頁面，沒有進一步公開判斷細節，例如靜態資源保護具體涵蓋哪些副檔名、WordPress 最佳化實際調整了哪些規則參數。用 WordPress 架站的話，這兩個開關值得留意，但不必期待它能解決所有 WordPress 特有的安全問題，它終究只是機器人偵測的一個調整項，不是完整的安全方案。
WAF 自訂規則由表達式與動作組成
WAF 自訂規則的建立路徑同樣在 Security 分類底下，進入 Security rules 頁面，點選 Create rule，選擇 Custom rules 類型，就會進入設定表單。
表單裡有三個核心欄位。Rule name 是規則名稱，方便日後管理；「When incoming requests match」這個區段用 Cloudflare 自己的 Rules 語言寫表達式，可以比對 User Agent、來源 IP、國別、路徑等各種 HTTP 屬性，決定符合什麼條件的流量要被這條規則抓到；「Then take action」則決定命中之後要做什麼。免費方案最多可以建立 5 條自訂規則，而且不支援 Log 動作與正規表達式功能，這對免費方案的使用者來說是實際的限制，規則數量有限，寫法也只能用 Cloudflare 提供的欄位比對，不能用正規表達式做更精細的字串比對。
規則的執行順序也有固定邏輯。所有自訂規則都在 http_request_firewall_custom 這個評估階段裡執行，由上到下依序比對。一旦命中 Block、Managed Challenge 這種終止型動作，評估就會停在那裡，不再往下比對後面的規則，這個由上而下、命中就停的順序，正是後面談允許清單一定要放在最前面的原因。
五種動作的差異，封鎖、質詢、略過、允許與記錄
WAF 自訂規則可以選擇的動作有五種，Block（封鎖）、Managed Challenge（受管挑戰）、Skip（略過）、Allow（允許）、Log（記錄）。前兩種很直覺，Block 直接擋下請求，通常回傳 403 這類錯誤；Managed Challenge 則丟出一道由 Cloudflare 決定挑戰強度的驗證關卡，讓使用者或裝置證明自己不是機器人。Block 動作在 Pro 以上方案還能自訂回應內容，可以指定回應格式（HTML、Text、JSON 或 XML）、狀態碼（400 到 499 之間，預設是 403），以及回應內文，內容上限是 2 KB。
真正容易被誤解的是 Skip。多數人第一次看到 Skip，直覺會當成放行，但它實際的意思是跳過接下來指定的安全檢查，可以設定跳過剩下所有的自訂規則，也可以只跳過特定的評估階段，像速率限制、Super Bot Fight Mode 或受管理規則，或者只跳過某個特定的舊版安全產品。Allow 才是單純的放行動作；Log 只把命中記錄寫進 Security Events，不影響流量本身是否通過，而且只有 Enterprise 方案支援這個動作。搞懂 Skip 是跳過檢查、不是允許放行這個差異，直接決定了它對 Bot Fight Mode 有沒有作用。
WAF 的 Skip 動作救不了 Bot Fight Mode
這是整套設定裡最容易讓人誤解的地方。Cloudflare 官方文件白紙黑字寫著，無法透過 WAF 自訂規則或 Page Rules 來繞過或略過 Bot Fight Mode。不是介面藏得深，也不是設定寫錯，而是架構上原本就不通。
原因要回到前面提過的評估機制。WAF 自訂規則、速率限制、受管理規則，以及付費版的 Super Bot Fight Mode，全部都跑在 Cloudflare 的 Ruleset Engine 上，依序經過 ddos_l7（HTTP DDoS 防護）、http_request_firewall_custom（自訂規則）、http_ratelimit（速率限制）、http_request_firewall_managed（受管理規則）、http_request_sbfm（Super Bot Fight Mode）這幾個階段。Bot Fight Mode 完全不在這套系統裡，Cloudflare 官方文件明確指出，它不使用 Ruleset Engine，運作在這整個階段系統之外。Skip、Bypass、Allow 這些動作本來就是設計來操控 Ruleset Engine 裡的評估流程，一套獨立在外面運作的產品，自然不會因為這些動作而受影響。
這個差異也解釋了為什麼 Super Bot Fight Mode 反而可以被略過。因為它運行在 http_request_sbfm 這個階段，屬於 Ruleset Engine 的一部分，WAF 自訂規則的 Skip 動作可以指定跳過這個階段，等於在付費版底下確實能針對特定流量開出例外。Cloudflare 官方文件對 Skip 選項的說明也直接寫出這個結論——目前無法略過 Bot Fight Mode，只能略過 Super Bot Fight Mode。這句話把整個問題的答案講白了，免費版與付費版在能不能設例外這件事上，不是差在設定介面好不好用，而是差在整個防護機制運作的位置完全不同。
也因為自訂規則的評估順序是先跑完 http_request_firewall_custom 才輪到後面的階段，即使一條 Skip 規則寫得再精準，它能攔截的也只有排在自己之後、同樣跑在 Ruleset Engine 上的環節。Bot Fight Mode 獨立在整條隊伍之外，不管規則放在多前面都碰不到它。
Googlebot 與 SEO 工具，可能被誤判成攻擊流量
不先建好允許清單就直接開啟防護，常見的後果不是網站被攻擊擋下來，而是自己人先被誤傷。Cloudflare 判斷一個請求是不是正常瀏覽器，依據之一是看它有沒有帶齊 User-Agent、Accept、Accept-Language 這類一般瀏覽器都會附上的標頭。問題是，不少自動化工具原本就不會帶齊這些標頭，包括市面上常見的 SEO 稽核工具、網站監控服務定期送出的探測請求，它們的設計目的本來就是快速、輕量地發送請求，而不是模擬一個完整的瀏覽器環境。同一套用來抓機器人的邏輯，套用到這些合法工具身上，一樣會判定它們看起來像機器人。
Cloudflare 確實維護一份已驗證機器人名單，把它信任的自動化服務登記在案，Googlebot、Bingbot 這類搜尋引擎爬蟲，以及部分監控類服務都在名單之內，只要被收錄進這份名單，理論上就不會被 Bot Fight Mode 或 Super Bot Fight Mode 誤傷。但這份名單並不包含所有市面上的自動化工具，沒被收錄進去的第三方 SEO 工具、自己架設的監控探針，並不享有這層保護，一樣會被判定成需要攔截的對象。
Cloudflare 的已驗證機器人分類裡，明確存在 Search Engine Optimization 與 Monitoring & Analytics 這兩個獨立分類，等於官方本身也承認，SEO 工具與監控服務是需要另外處理的合法自動化流量，而不是把所有非瀏覽器流量一律當成威脅。這也是為什麼先建允許清單、再開防護會被列為建議的操作順序，順序顛倒過來，往往是先發現自己的監控告警亂跳、SEO 報表抓不到資料，才回頭意識到問題出在哪裡。
用驗證機器人分類建立允許清單，放在封鎖規則最前面
開防護之前一定要先做的具體操作，核心原則是允許規則要排在最前面，而且動作要用 Skip，不能只是單純的 Allow，順序錯了，後面的封鎖或挑戰規則還是會先攔下合法工具。
Cloudflare 官方使用案例文件給出的標準做法，是建立一條自訂規則，表達式輸入 (cf.client.bot)，用來比對這個請求是不是 Cloudflare 已驗證的機器人；動作選擇 Skip，勾選「All remaining custom rules」，代表命中之後跳過剩下的所有自訂規則；接著在 Place at 選單裡選擇 First，確保這條規則排在任何封鎖規則之前執行。這個排在最前面的設定，正是前面提到的評估順序在實務上的應用，由上而下比對，先放行的規則先生效，後面的封鎖規則就沒有機會攔到已經被判定合法的流量。
如果只想放行特定用途的機器人，而不是全部驗證通過的類別都一併放行，可以改用 cf.verified_bot_category 這個欄位，只鎖定特定分類。例如只想讓 SEO 工具與監控服務通過，其他分類仍然照常檢查，表達式就可以寫成只列出 Search Engine Optimization 與 Monitoring & Analytics 這兩個分類的形式，而不是放行所有已驗證機器人分類。這種寫法比一律放行更保守，也更貼近多數網站實際需要的例外範圍，不是所有機器人流量都該放行，只是某幾類真正在幫網站做事的自動化服務不該被誤傷。
允許規則建好之後，才輪到建立針對其他機器人的封鎖或挑戰規則，最後回到 Security Events 檢視實際攔截情況、按需要調整。
IP 清單比對，Ahrefs 等工具公布的固定位址
已驗證機器人名單終究是有限的清單，不是每一套市面上流通的工具都被收錄在內。遇到這種情況，退而求其次的做法是改用該工具官方自己公布的固定 IP 位址清單，把這些 IP 寫進 WAF 自訂規則的比對條件裡，一樣可以達到放行的效果。
這個做法的前提，是那套工具本身有公開維護一份固定 IP 清單可供查詢，像 Ahrefs 這類國際性的 SEO 工具，官方會定期公布自己抓取用的 IP 位址範圍，可以把這份清單整段貼進 WAF 自訂規則的 IP 來源比對欄位，建立一條專門放行這些 IP 的規則。這個方法比比對 User Agent 更可靠一些，因為 User Agent 字串很容易被偽造，固定 IP 清單則是由工具官方自己維護、相對穩定的資訊；缺點是工具日後若更換或擴充 IP 範圍，規則需要跟著手動更新，不像已驗證機器人分類由 Cloudflare 自動維護，不需要自己盯著清單有沒有異動。
沒有 Super Bot Fight Mode，只剩兩個選擇
前面幾節建立的技術事實，拼起來會導出一個對免費方案不太好聽的結論。Bot Fight Mode 不跑在 Ruleset Engine 上，任何 WAF 自訂規則的 Skip、Bypass、Allow 對它都沒有作用。如果免費方案的網站真的遇到特定工具持續被 Bot Fight Mode 擋下，而且已驗證機器人分類、WAF 自訂規則的 IP 白名單這些方法都試過還是擋不掉，能真正解決問題的路實際上只剩兩條。
這裡有一個容易被忽略、但範圍很窄的例外。WAF 底下還留著一項比自訂規則更早期的獨立工具「IP Access Rules」，針對單一 IP 或 IP 段建一條動作為 Allow 的規則，符合的來源之後會跳過包含 Bot Fight Mode 在內的多數安全檢查——這跟前面講的 WAF 自訂規則 Skip 是兩套不同機制，Skip 碰不到 Bot Fight Mode，IP Access Rules 的 Allow 可以。但它只能一條一條鎖定固定不變的 IP，沒有已驗證機器人分類那種整批分類放行的彈性，只適合處理少數幾個 IP 固定的工具，解決不了大範圍、IP 常變動的自動化流量被誤擋的問題。
排除這個小範圍的例外，第一條路，是整站關閉 Bot Fight Mode，放棄這一層機器人防護。這聽起來像是退讓，但需要說清楚的是，關掉它不代表網站毫無保護，Cloudflare 基礎的 DDoS 防護、受管理規則等其他安全層，運作邏輯跟 Bot Fight Mode 的開關完全獨立，不會因為關掉這一項就一起失效。第二條路，是升級到 Pro 以上的方案，換取 Super Bot Fight Mode，才能真正對特定流量設下例外。
該怎麼在這兩條路之間取捨，判斷依據回到兩件事，這個網站有多需要防機器人，以及被擋掉的流量是不是牽涉到關鍵的商業運作。舉例來說，監控服務被誤判擋下，影響的是網站健康狀態的即時判斷能力，這種代價通常比放任機器人流量更值得正視。這不是一句建議升級就能一概而論的事，而是要衡量網站實際承受的風險與被誤傷的代價，再決定要不要多花這筆訂閱費用。
上線後的兩項驗證，安全事件記錄和模擬測試
規則設定完成，不代表工作就此結束。前面幾節建的允許清單、封鎖規則，實際生效狀況需要驗證，才知道有沒有誤擋合法流量，也才知道原本想放行的工具是不是真的順利通過。
第一項驗證是查看 Security Events，也就是安全事件記錄。這裡會列出實際被攔截或挑戰的請求，可以看到每一筆請求命中的是哪一條規則、執行了什麼動作。用這個記錄反過來檢查，原本設定應該放行的流量，有沒有出現在被攔截的清單裡。如果某個工具的請求還是出現在攔截記錄裡，通常代表允許規則的表達式寫得不夠精準，或者順序沒有真的排在封鎖規則之前，需要回頭調整。
第二項驗證是主動模擬測試。用 curl 搭配 -A 這個參數，可以在指令列裡帶入特定工具的 User Agent 字串，模擬那套工具實際發出請求時的樣子，直接測試允許規則是不是真的生效，不必等工具下一次自然的抓取週期才知道結果。如果特別擔心 Googlebot 的抓取狀態受到影響，也可以到 Google Search Console 的網址檢查工具，確認抓取狀態是不是維持正常，收錄與索引沒有跟著受影響。
把整套流程拉回來看，從一開始在 Bot analysis 檢視流量，到開啟防護、建允許規則並確保排在最前面、再建封鎖規則，最後回到 Security Events 檢視調整，是一套完整的循環，不是設定一次就結束的動作。
網站的自動化流量會隨著時間變化，新的工具、新的監控服務可能陸續加進來，這個驗證步驟值得養成定期回頭檢查的習慣。
回頭看整件事，Bot Fight Mode 與 WAF 自訂規則之所以會讓人摸不著頭緒，不是設定沒做對，而是兩套機制本來就不在同一套系統裡運作，搞懂這個底層差異，才不會把時間花在一條永遠生效不了的規則上。免費方案能做的取捨有限，但透過已驗證機器人分類與 IP 清單比對，還是能在合理範圍內先保護好真正在用的工具；真的碰到免費版的天花板，升級到 Super Bot Fight Mode 換取例外設定的空間，也是一個站得住腳的選擇。機器人流量只會愈來愈多，把這套防護與允許清單的邏輯先搞清楚，之後不管網站規模怎麼變化，都能照著同一套思路調整設定。