WAF 是什麼？網頁應用程式防火牆的原理與用途

WAF 是 Web Application Firewall 的縮寫，中文稱為「網頁應用程式防火牆」。它會檢查送往網站的 HTTP／HTTPS 請求，依規則辨識可疑內容，協助阻擋部分攻擊，讓正常訪客繼續使用網站。

例如，你經營一間網路商店，客人每天會搜尋商品、登入、填表單。這些動作都會向網站傳送資料；攻擊者也可能利用同樣的入口，把有害指令混進去。防護的工作，就是在網站處理這些資料前，先做檢查。

接下來會從一筆請求如何進入網站開始，說明它能防什麼、和 CDN 有何不同，以及導入時怎麼避免誤擋。最後再談 SEO／GEO：網站需要保護，也需要讓真正的搜尋爬蟲讀到公開內容。

---

WAF 如何在請求進入網站前把關？

你可以把它想成商店入口的檢查人員：客人提出需求，先檢查是否符合規則，再交給店內處理。實際上，它檢查的是網路請求，並不會像人一樣理解客人想買什麼。

以商品搜尋為例，訪客送出關鍵字後，請求會先經過防護，再送到真正運作網站的伺服器。規則判斷可以繼續時，網站才處理搜尋並回傳結果；遇到符合阻擋條件的請求，就在前面攔下。

Cloudflare 的定義把這類防護放在應用層，也就是常說的第七層。對網站經營者來說，重點是它能針對「網站收到什麼要求」檢查，不只是看連線來自哪裡。

---

WAF 檢查的是什麼？

一筆請求除了網址，還包含訪問方法、附帶資訊與提交資料。依產品及規則配置，檢查項目可能包括以下內容：

• 網址路徑：訪客要看公開文章，還是嘗試進入登入頁？
• 查詢參數：商品搜尋或篩選時，網址附帶了哪些資料？
• 請求標頭：包含瀏覽器或程式宣告的身分等資訊。
• 請求本文：表單、登入或其他提交動作傳送的資料。

AWS 的請求檢查文件也列出這些項目。但產品對本文大小、格式與檢查範圍會有上限，不能假設所有傳入資料都能完整檢查。

HTTPS 雖然把傳輸內容加密，仍然可以搭配這類防護。前提是服務部署在能處理解密後請求的位置；如果它只能看到加密連線，就不能直接檢查裡面的表單內容。

---

放行、阻擋、觀察與驗證有何不同？

規則命中後，不一定立刻封鎖。AWS WAF 的基本動作包括放行、阻擋、計數，以及 CAPTCHA 或挑戰檢查；實際可用功能依服務而定。

「放行」讓請求繼續；「阻擋」拒絕它；「計數」先留下命中紀錄，觀察這條規則會影響哪些流量。這很適合用來測試新規則，避免還沒看清楚正常使用方式就開始攔截。

「挑戰」則可能要求瀏覽器完成檢查，或讓訪客通過驗證。你看過的「正在確認您是否為真人」就屬於這類情境；挑戰頁會中斷原本的存取流程，某些自動化程式也可能無法通過。

---

WAF 能防哪些威脅？哪些還要靠網站本身？

這層檢查適合處理藏在網站請求裡的攻擊特徵。常見產品會提供維護好的規則，也允許管理者針對網站用途設定條件；但規則看得見的範圍，和網站真正存在的漏洞，並不完全相同。

---

SQL 注入與跨站腳本：防止輸入被當成指令

SQL 注入是攻擊者把資料庫指令混入網站輸入，企圖讓網站執行原本不應該做的查詢。就像商品搜尋原本只需要商品名稱，攻擊者卻想讓搜尋欄變成改動或讀取資料庫的入口。

跨站腳本攻擊（XSS）則是把惡意腳本帶進網頁，讓其他訪客的瀏覽器執行。表單、留言等輸入若處理不當，就可能成為入口；網站本身仍要正確處理輸入與輸出，避免把不可信的內容當成程式。

WAF 可以根據請求中的特徵，降低這類攻擊到達網站的機會。Cloudflare 的受管理規則也以持續維護的攻擊特徵提供保護，但不代表每個漏洞都能被辨識或攔住。

---

大量登入與機器人：要配合額外規則

如果有人短時間不停嘗試帳號密碼，可以透過限速、機器人辨識或專門的登入保護降低風險。這些能力是否存在、用什麼條件觸發，都要看產品與設定，不能只因啟用了防火牆就認為帳號已經安全。

例如，網站可以針對登入入口的異常頻率做處理，但真正的會員也可能忘記密碼、連續重試。條件設得太粗，就會一起擋住正常的人；只看單一 IP，也可能把共用網路的訪客混在一起。

使用 WAF 後，更新、備份與權限管理仍然要做。外掛漏洞需要修補，重要帳號需要適當驗證，資料也需要能復原的備份。防護規則只能補上一層檢查，無法替網站完成這些工作。

它也未必知道某個已登入帳號正在做的動作是否符合你的業務規則。像是會員能否查看別人的訂單，還要靠網站正確檢查權限，不能只交給外部流量規則判斷。

---

WAF、一般防火牆、CDN 與 DDoS 防護差在哪？

這幾個名詞常出現在同一套網站服務裡，但解決的問題不同。判斷時可以先看它負責哪件事，再看服務方案實際包含哪些能力。

這裡說的是主要分工。現代防火牆可能包含應用檢查，CDN 服務也可能同時提供安全功能；DDoS 防護則可能涵蓋不同網路層次。因此，功能可以互補，也可能在產品裡重疊。

差異可參考 Cloudflare 的防火牆、CDN與DDoS說明。不要只看到方案寫著「加速」或「防護」，就推定每一項都已啟用。

另外，Cloudflare R2主要用來儲存檔案，和檢查網站請求又是不同工作。使用同一個供應商的儲存、加速與安全服務，仍要逐項確認各自負責的範圍。

---

---

WAF 有哪些部署方式？

常見方式有雲端服務、裝在主機上的軟體，以及部署在網路中的設備。對網站經營者來說，先確認誰負責維護、流量從哪裡經過，比記住產品名稱更有用。

---

雲端代理：先確認流量有經過防護

雲端方式通常把服務放在訪客與網站主機之間，讓請求先經過檢查，再轉送給網站。部分服務透過網域的 DNS 設定導流，另一些則整合到雲端的內容交付或負載平衡服務。

這種方式由供應商維護部分基礎設施，但網站擁有者仍要決定保護哪些入口、套用哪些規則，以及發生誤擋時如何處理。購買了服務，和網站流量真的有受到保護，是兩件要確認的事。

如果攻擊者還能直接連到網站的原始主機，就可能繞過前面的檢查。導入時要請維運人員確認原始主機的存取限制，也要看子網域、API 等入口有沒有納入，而不只檢查首頁。

---

主機軟體與網路設備：誰來維護更重要

主機式 WAF 由軟體在伺服器或應用環境中執行，通常需要有人處理更新、規則及主機資源。網路設備式則放在企業自己的網路環境中，設備管理與部署也需要維運能力。

Cloudflare 對部署方式的比較也指出，主機式會使用本機資源，設備式需要維護實體設備。這不代表某一種一定比較好，而是責任與整合方式不同。

如果你的網站交給架站公司或主機商管理，可以先問三個問題：

• 目前有哪些網域、頁面與資料提交入口受到保護？
• 誰負責規則更新，誰能查看事件紀錄？
• 正常會員、表單或付款流程被擋時，要提供什麼資料、找誰處理？

得到具體答案後，才容易判斷是否需要新增服務。若已經有同類防護，先整理現況，也能避免兩套規則互相干擾，卻沒有人知道是哪一層攔住請求。

---

導入 WAF 時，如何避免正常功能被擋？

防護規則會依特徵判斷，但「看起來可疑」不一定代表攻擊。正常的表單內容、會員操作或系統串接，也可能命中規則。這種把正常請求攔住的情況，稱為誤擋。

---

先列正常流程，再用觀察模式測試

導入前，先列出網站重要的正常流程，例如閱讀文章、搜尋商品、登入、提交表單、上傳檔案及結帳。網站若有付款通知或其他服務的自動連線，也要一起納入測試。

AWS 建議先測試與調整規則，再以正式流量的 Count 模式觀察，確認影響後才啟用。其他服務若有類似的只記錄模式，也可以先觀察新規則會攔到什麼。

測試時除了看頁面能不能打開，也要完成真正的動作：表單送出後有收到，會員能登入，訂單能建立，付款結果能回到系統。只有首頁能看，不足以證明網站功能正常。

---

發生誤擋時，用事件紀錄找到規則

先記下發生時間、網址、當時做了什麼，以及錯誤畫面上的請求識別碼；有些服務會稱為 request ID 或 Ray ID。再請管理者對照安全事件，找出命中的規則與處理動作。

接著確認是哪一層造成：可能是受管理規則，也可能是限速、機器人政策、網站外掛或主機限制。沒有對上事件紀錄前，不要只因看到 403 錯誤就認定一定是 WAF。

找到原因後，針對正常請求調整，例如限制例外的網址、方法、已驗證來源，以及需要略過的特定規則。公開文章、登入頁與結帳入口的用途不同，不應共用一個過於寬鬆的例外。

以 Cloudflare 的 Skip 動作為例，可以略過指定安全檢查，但不能略過所有產品；Bot Fight Mode 就不在可略過範圍。調整後仍要確認真正命中的那一層已改善。

最後重做原本失敗的動作，確認正常流程恢復，也確認其他必要防護仍在。保留原規則與修改紀錄；如果新設定反而造成問題，就能回復原本配置，而不是一路擴大放行。

---

---

WAF 與 SEO／GEO 的關聯：公開內容要能被正常讀取

這層防護和 SEO、GEO的交集，主要在網站存取。搜尋爬蟲被誤擋，就讀不到公開內容；把存取障礙排除，也不等於排名或 AI 引用一定提高。

---

先看回應內容，再看狀態碼

不要只確認網頁回傳 200「成功」。如果爬蟲收到的是驗證畫面、登入頁或空白頁，仍然沒有取得文章。Google 也說明，200 不保證收錄；要一起檢查回應裡的正文。

403 表示拒絕存取，Google 不會把這類回應內容拿來收錄；429 則表示請求過多，會讓 Google 暫時放慢抓取。若異常持續，可能進一步影響索引，不能把兩者都當成無關緊要的防護訊息。

排查時，用 Search Console 的網址檢查功能查看公開頁取得的 HTML，並對照防護事件。robots.txt 即使允許爬蟲，也不會覆蓋前面的阻擋規則；允許抓取與真的送出正文，需要分別確認。

---

區分搜尋、訓練與使用者發起的抓取

AI 相關程式用途不同，不能全部當成同一種訪客。OpenAI 的爬蟲說明區分以下三種角色：

• OAI-SearchBot：用於 ChatGPT 搜尋，讓網站有機會出現在搜尋回答。
• GPTBot：抓取的內容可能用於模型訓練，偏好可與搜尋分開管理。
• ChatGPT-User：用於部分使用者發起的頁面存取，不是自動搜尋爬蟲。

Google 的 Google-Extended也不是控制 Google 搜尋或 AI Overviews 的開關。它管理的是部分 Gemini 模型訓練與內容使用偏好。

Google AI 搜尋功能仍以搜尋抓取、收錄與摘要顯示資格為基礎，並不需要特殊 AI 檔案。能被抓取與有資格出現，只是基本條件，並不保證 AI 採用內容。

設定例外前，要先驗證來源。只把 User-Agent 改成 Googlebot，無法證明真是 Google；管理者應依官方 IP 清單或正反向 DNS 查核方法核對。其他爬蟲也應使用各自官方提供的識別方式。

Cloudflare 的AI 機器人政策可區分搜尋、代理與訓練行為；已驗證身分的程式，也可能受用途政策限制。只對想開放的公開內容與必要檢查精準調整，再確認能取得正文，保留登入及交易入口的保護。

---

結語：防護要有效，正常存取也要保留

WAF 的價值，在於替網站請求增加一道可調整的檢查。理解它之後，你就能向主機商或維運人員問清楚：哪些入口受到保護、誰維護規則，以及正常操作被擋時怎麼找到原因。

導入時，先確認流量確實經過防護，再觀察、測試與調整。對公開內容保留正常抓取，對登入與交易維持適合的限制；同時做好網站更新、帳號權限與備份，才是完整的網站維護。

重點整理

WAF 是什麼？一般網站也用得到嗎？

WAF 是網頁應用程式防火牆，會檢查送往網站的 HTTP／HTTPS 請求，依規則處理可疑內容。公開網站、會員網站及網路商店都可能有需要；是否新增服務，應先確認主機商已提供的防護、網站入口與維護人力。

WAF 和 CDN 是同一種服務嗎？

兩者主要功能不同。WAF 檢查網站請求，CDN 透過分散節點與快取交付內容。有些供應商把兩種功能整合在同一套服務裡，因此應查看實際方案及啟用設定，不能只因使用 CDN 就認定已具備應用層防護。

使用 WAF 後，還需要更新 WordPress 嗎？

需要。WAF 只能協助降低部分攻擊到達網站的機會，無法保證攔住所有漏洞，也不能替網站檢查每個帳號的業務權限。WordPress 核心、佈景主題與外掛仍要維護，重要帳號和可復原的備份也不能省略。

WAF 擋住正常表單，應該直接關掉嗎？

先記下時間、網址、操作與請求識別碼，請管理者對照安全事件，確認是哪個產品及規則攔截。找到原因後，針對正常的路徑、方法與已驗證來源調整必要規則，重測表單及其他功能；不宜為了一個誤擋就全面關閉防護。

開啟 WAF 會提升 SEO 排名或 AI 引用嗎？

沒有這種保證。WAF 設定的影響主要在存取：Googlebot 或搜尋用途的 AI 爬蟲被誤擋，可能無法讀到公開正文。修正誤擋可以排除抓取障礙，但收錄、排名與 AI 是否採用內容，還有其他條件。