WAF 阻擋正常訪客或搜尋引擎檢索器時，排查順序是：先確認擋下請求的是 WAF 還是主機，再從 WAF 記錄找出對應的請求與觸發規則，判斷是誤判還是真的攻擊，再只針對那條規則、那個網址或參數建立排除，而不是整個關閉 WAF。被擋的若是 Googlebot，要先用反向 DNS 或 Google 公布的 IP 清單確認是真的 Google 檢索器再放行。Google 對 4xx 與 5xx 回應的處理不同，網址持續被擋，可能無法建立索引，已收錄的網址也可能被移除。
先確認擋下請求的是 WAF 還是主機
接到「網站打不開」「表單送不出去」的回報時，先別急著改規則，把現象記下來：發生時間、完整網址、操作步驟、訪客的 IP 與裝置，以及畫面上的訊息與狀態碼。接著比對兩邊的紀錄：
- WAF 記錄有這筆請求且動作是阻擋，主機存取紀錄卻沒有：請求在抵達主機前就被擋下。
- 主機紀錄有請求並回應錯誤：問題在網站程式或主機設定，不在 WAF。
- 只有特定網路或地區的訪客被擋：檢查地理位置、IP 信譽或頻率限制這類規則。
- 只有特定操作被擋，例如後台儲存文章、上傳檔案、送出含特殊字元的表單：優先檢查比對請求內容的規則。
狀態碼可以縮小範圍。依 MDN 的定義，403 表示伺服器理解請求但拒絕處理，重新驗證身分也沒有差別；429 表示用戶端在一段時間內送出過多請求，這種要求用戶端放慢的機制常稱為頻率限制。各家 WAF 回應的狀態碼與阻擋頁不一定相同，判斷時以 WAF 記錄為準。
從 WAF 記錄找出觸發的規則
- 篩選請求：依回報時間前後、網址路徑與用戶端 IP 找出那筆紀錄。
- 記下規則資訊：規則編號、所屬群組、比對到的位置（網址、參數、標頭或 Cookie）與比對到的值。
- 找出累加分數的規則：OWASP CRS 採用異常計分，每條比對到的規則會累加分數，總分達到門檻才阻擋。記錄裡執行阻擋的可能是判斷總分的規則，要往前找出是哪幾條規則貢獻了分數。
- 重現一次：在測試環境或偵測模式下重做相同操作，確認同樣的規則再次觸發。以 Azure 為例，偵測模式只監視並記錄符合規則的請求，不會封鎖。
WAF 的定位與部署位置可參考WAF 防火牆是什麼。
判斷是誤判還是真的攻擊
OWASP CRS 把正常請求錯誤觸發規則的情況稱為誤判。可以用下表當判斷起點：
| 觀察面向 | 傾向誤判 | 傾向真的攻擊 |
|---|---|---|
| 來源 | 已登入的員工、會員，或已驗證的檢索器 | 不明來源，或假冒檢索器名稱 |
| 行為 | 正常流程中的單一請求，能穩定重現 | 短時間內大量嘗試不同網址或參數 |
| 內容 | 後台編輯器送出的 HTML、合法的特殊字元 | 和頁面功能無關的指令或腳本片段 |
| 網址 | 網站實際存在的頁面與表單 | 不存在的管理路徑、設定檔或備份檔名稱 |
判斷為真的攻擊時不要建立排除，改為確認被嘗試的元件是否已更新；無法判斷時，先把紀錄交給網站開發或主機管理人員一起確認，再決定是否調整。
建立規則排除：範圍越小越好
CRS 文件說明誤判要靠撰寫規則排除處理，並強烈不建議直接修改規則檔；為了解決誤擋而整個移除 WAF，是不必要地犧牲安全。排除的範圍由小到大大致是：
- 特定網址的特定參數不套用某條規則，例如只讓後台文章內容欄位略過造成誤判的規則。
- 特定網址停用某條規則，適合整個頁面的請求格式都會觸發時使用。
- 允許特定來源，只適用於固定 IP 的辦公室或已驗證的檢索器，不要用來放行整個地區或大範圍網段。
- 調整整體靈敏度：CRS 以偏執等級控制規則的積極程度，等級越高越容易誤判；調低等級會影響全站，其他做法都不適用時再考慮。
以 Azure 為例，官方說明調整 WAF 可能涉及建立規則排除以降低誤判，調整後要改回預防模式。每筆排除記下原因、日期與負責人，功能下線或改版後回頭檢視，不再需要的就移除。
Googlebot 被擋：先驗證身分再放行
使用者代理字串可以被假冒，不能看到 Googlebot 字樣就放行。Google 搜尋中心提供兩種驗證方式：
- 手動驗證：對存取紀錄中的 IP 執行反向 DNS 查詢，確認網域是 googlebot.com、google.com 或 googleusercontent.com；再對查到的主機名稱執行正向 DNS 查詢，確認結果和原本的 IP 相同。
- 自動比對：把存取的 IP 和 Google 公布的 IP 位址清單比對。
確認是 Google 的檢索器後，再依驗證結果建立放行規則，上線後抽查存取紀錄，確認 Googlebot 拿到正常頁面，而不是驗證頁或錯誤頁。如果是主機負載過重才用頻率限制擋檢索，Google 說明緊急降低檢索頻率時可以回傳 500、503 或 429，但不應超過一到兩天，否則可能影響網站在 Google 產品中的顯示方式。
被擋對收錄的影響與 Search Console 檢查
Google 依狀態碼決定怎麼處理被擋的網址：429 與 5xx 會讓 Google 的檢索器暫時放慢檢索，已建立索引的網址會先保留，但錯誤持續時最終會被移除；429 以外的 4xx，例如 403，Google 不會為這些網址建立索引，已收錄的網址會從索引中移除，官方也提醒不要用 401 或 403 限制檢索頻率。在 Search Console 可以這樣確認：
- 網址檢查：對被擋的網址按「測試線上網址」，看 Google 能否取得頁面。
- 網頁索引報表：查看是否出現「因拒絕存取（403）而遭到封鎖」「網址因其他 4xx 問題而遭到封鎖」或「伺服器錯誤（5xx）」。官方說明 Googlebot 不會提供憑證，伺服器不應對它傳回 403。
- 檢索統計資料報告：依回應類型查看 Google 收到的回應比例，並看主機狀態中的 robots.txt 擷取、DNS 解析與伺服器連線能力。
放行規則調整後，先用網址檢查重新測試，再觀察報表中的錯誤是否減少。報表的基本用法可參考Google Search Console 功能與企業用法。
調整後的驗證與日常預防
- 回歸測試：重做訪客回報的操作，並測試登入、表單、上傳與結帳等主要入口，確認其他地方仍受保護。
- 定期檢視記錄：以 Azure 為例，官方建議定期檢視 WAF 記錄，用來減少誤判並了解網站是否成為攻擊目標。
- 改版後重新檢查：OWASP 提醒客製規則要隨網站修改持續維護，新增表單、外掛或更換規則集版本後，原本的排除可能不再適用。
- 新規則先觀察：新增規則時先用偵測模式觀察，確認不會擋到正常使用者再切換阻擋。
常見問題
WAF 一直誤擋，可以先關掉嗎？
不建議。CRS 文件形容整個移除 WAF 是為了方便而不必要地犧牲安全，應以規則排除處理誤判。改成偵測模式同樣代表暫時沒有防護，只適合短期觀察。
把 Googlebot 的使用者代理加入白名單就好嗎？
不夠。使用者代理字串可以被假冒，放行前要用反向與正向 DNS 查詢，或比對 Google 公布的 IP 清單，確認請求確實來自 Google 的檢索器。
robots.txt 和 WAF 封鎖有什麼不同？
robots.txt 是給檢索器的指示，Google 說明它無法強制檢索器遵守；WAF 則直接拒絕請求，被擋的網址會回應錯誤狀態碼，影響 Google 是否為網址建立索引。
只有部分訪客被擋，可能是什麼原因？
常見方向包括地理位置規則、IP 信譽名單與頻率限制。多人共用同一個對外 IP 時，也可能一起觸發頻率限制，可從記錄的來源 IP 確認。
調整規則後，Search Console 多久會更新？
報表要等 Google 重新檢索後才會反映，沒有固定時間。可以先用網址檢查的線上測試確認 Google 已能取得頁面，再持續觀察網頁索引報表與檢索統計資料報告。
本文由京采數位科技整理。我們自 2005 年起提供官網設計、系統開發與 Google SEO 服務，實際案例可見成果與案例。
想直接討論你自己的網站狀況，或需要一份初步的搜尋機會評估？
相關主題
下一步
如果懷疑網站有誤擋，先整理被回報的時間、網址與操作，並確認 WAF 與主機記錄由誰管理。京采的技術 SEO 與網站健檢服務可以協助檢查 Search Console 的檢索與索引狀態，對照主機與 WAF 記錄找出被擋的網址，調整檢索器的驗證放行與規則排除設定，並在調整後測試表單與後台功能。想討論網站現況，歡迎與我們聯繫。
