近年來，許多網站站長都遇到同一個問題：網站明明沒有大型活動、廣告也沒有突然放大，但後台流量卻莫名暴增，CPU 與記憶體長時間維持高負載，甚至出現 502 Bad Gateway、資料庫延遲、網頁載入變慢等狀況。
這些流量看似熱鬧，卻不一定是真正的人類訪客。很多時候，它們來自 AI 爬蟲、惡意 Bot、自動化掃描器，或大量抓取資料的程式。
面對這類問題，很多人的第一反應是升級主機、加大 CPU、增加記憶體或提高頻寬。但如果問題的根源是「無效請求太多」，單純升級主機往往只是延後爆掉的時間，並沒有真正阻止爬蟲繼續消耗資源。
這時候，Cloudflare / CDN 的價值就不只是加速網站，而是在源站主機前面建立一層流量過濾、防護與緩衝機制。透過 CDN 快取、WAF 規則、Rate Limit、AI Crawler 管理與源站防火牆，可以把大量不必要的請求擋在主機外面，降低網站卡頓與流量爆炸的風險。
一、為什麼 AI 爬蟲不能只靠主機硬撐？
AI 爬蟲造成的壓力，和一般訪客不同。正常使用者通常會打開幾個頁面、閱讀內容、停留一段時間；但 AI 爬蟲可能在短時間內大量請求文章、分類、標籤、搜尋頁、API、圖片與各種動態路徑。
對主機來說，這些請求每一次都可能觸發 PHP、資料庫查詢、檔案讀取、圖片傳輸或後端運算。當爬蟲數量增加、頻率提高，網站就會開始出現明顯負載。
- 高併發請求： 短時間內大量連線，導致 Apache、Nginx、LiteSpeed 或 PHP-FPM 壓力升高。
- 深層頁面掃描： 爬取文章分頁、標籤、分類、搜尋結果，增加資料庫查詢壓力。
- 靜態資源消耗： 圖片、CSS、JS、字型與媒體檔案被大量下載，造成頻寬暴增。
- 動態頁面拖慢： 搜尋頁、會員頁、API 或後台路徑若被大量請求，容易造成網站反應變慢。
所以，AI 爬蟲問題的本質，不一定是主機太弱，而是主機正在處理太多沒有商業價值的流量。
如果沒有在流量進入源站前先過濾，伺服器就會被迫承擔所有請求，包含正常訪客、搜尋引擎、AI 爬蟲、惡意 Bot 與攻擊流量。
二、Cloudflare / CDN 是什麼？站在源站前面的流量守門員
沒有使用 CDN 時，所有訪客、爬蟲與攻擊流量都會直接連到你的源站主機。也就是說，不管對方是真人、搜尋引擎、AI 爬蟲還是惡意程式，主機都必須先接住請求，再決定要不要回應。
使用 Cloudflare 這類 CDN 後，網站流量會先經過 Cloudflare 節點，再由 Cloudflare 判斷是否放行、快取、挑戰、限制或封鎖。Cloudflare 官方也說明，透過反向代理，網站不需要直接暴露源站 IP，攻擊者也較難直接針對源站發動攻擊。:contentReference[oaicite:0]{index=0}
| 架構 | 流量路徑 |
|---|---|
| 未使用 Cloudflare | 訪客 / 爬蟲 / 攻擊者 → 源站主機 |
| 使用 Cloudflare | 訪客 / 爬蟲 / 攻擊者 → Cloudflare 節點 → 過濾 / 快取 / 挑戰 / 阻擋 → 源站主機 |
這也是為什麼 Cloudflare / CDN 對 AI 爬蟲防護很重要。它不是單純讓網站變快，而是先在主機前面多放一道檢查站。
- CDN 快取： 讓靜態資源由節點回應，減少源站請求。
- WAF 規則： 依照 User-Agent、IP、國家、ASN、路徑等條件過濾流量。
- Rate Limit： 限制短時間大量請求，避免高併發打爆主機。
- AI Crawler 管理： 分析並控管 AI 爬蟲如何存取網站內容。
- 源站 IP 保護： 避免攻擊者繞過 Cloudflare 直接打主機。
三、第一層防護：CDN 快取，先減少源站被打到的次數
CDN 的第一個價值不是封鎖，而是減壓。
當網站的圖片、CSS、JavaScript、字型、部分靜態頁面或不常變動的內容可以由 Cloudflare 節點回應時，請求就不需要每次都回到源站主機。這對於 AI 爬蟲大量抓取圖片、文章頁或靜態資源時特別有幫助。
| 適合快取的內容 | 不建議隨意快取的內容 |
|---|---|
| 圖片、CSS、JavaScript、字型檔案 | 會員中心、客戶後台、購物車 |
| 不常變動的文章頁、知識庫頁面 | 結帳頁、付款頁、訂單頁 |
| 公開下載檔、公開展示頁、靜態 HTML | API、搜尋頁、含個人資料的頁面 |
不過，CDN 快取不是萬能。如果 AI 爬蟲一直打動態頁、搜尋頁、API、會員路徑或後台路徑，這些請求仍然可能回到源站。這時候就需要搭配 WAF 與 Rate Limit。
四、第二層防護：WAF 規則，阻擋可疑 User-Agent 與異常路徑
WAF，也就是 Web Application Firewall，可以理解成網站前面的應用層防火牆。它可以根據請求特徵，決定要放行、封鎖、挑戰或記錄。Cloudflare WAF 支援 Custom rules、Rate limiting rules、Managed rules 與 Security Events 等功能。:contentReference[oaicite:1]{index=1}
面對 AI 爬蟲，WAF 可以用來判斷以下條件：
- User-Agent 是否包含已知 AI 爬蟲名稱。
- 是否大量請求 /search、/tag、/category、/wp-json 等高成本路徑。
- 是否短時間大量掃描頁面。
- 是否來自高風險國家、資料中心 IP 或特定 ASN。
- 是否缺乏正常瀏覽器特徵。
- 是否嘗試存取後台、API 或不該公開的路徑。
例如，若發現某些 User-Agent 明確標示為 AI Bot，且不會帶來搜尋流量或商業價值，可以先設定 Managed Challenge 或 Block。若某些 IP 段大量掃描搜尋頁，也可以針對該路徑提高挑戰等級。
不過，WAF 規則不建議一開始就過度嚴格。實務上比較穩定的方式，是先觀察 Log 與 Security Events，再逐步調整規則，避免誤傷正常使用者、搜尋引擎、支付平台或合作服務。
五、第三層防護：Rate Limit，限制短時間大量請求的 AI 爬蟲
AI 爬蟲最傷主機的地方，不一定是單次請求，而是短時間內的大量請求。
Rate Limit 的作用，就是限制同一個來源、同一類條件或同一種特徵，在固定時間內能發出多少請求。Cloudflare 的 Rate limiting rules 可以針對符合條件的請求設定速率限制，並在超過限制後執行指定動作，常用於保護登入端點、防止 API 被濫用，或限制單一客戶端在某段時間內的呼叫量。:contentReference[oaicite:2]{index=2}
在阻擋 AI 爬蟲時，Rate Limit 特別適合套用在這些位置：
- 搜尋頁，例如 /?s=、/search。
- 分類頁、標籤頁、文章列表分頁。
- WordPress /wp-json 或其他公開 API。
- 登入頁、註冊頁、留言頁。
- 高成本查詢頁與容易觸發資料庫查詢的頁面。
例如可以規劃以下方向：
- 同一 IP 在 10 秒內請求搜尋頁超過 20 次，啟用驗證挑戰。
- 同一 IP 在 1 分鐘內請求文章頁超過 120 次，暫時限制存取。
- 同一 IP 在短時間內大量打 API，回傳 429 Too Many Requests。
但 Rate Limit 不應該亂設太嚴。若門檻過低，可能會誤傷正常使用者、搜尋引擎、付款回調、API 串接或前端正常請求。建議先從高成本、低轉換價值的頁面開始設定，例如搜尋頁、標籤頁、API 與文章列表分頁。
六、第四層防護：AI Crawler 管理，針對 AI 爬蟲做專門控管
傳統 Bot 防護通常是針對惡意機器人、掃描器、撞庫攻擊、垃圾流量或 DDoS。但 AI 爬蟲的問題更微妙，因為它們不一定是在攻擊網站，而是在大量抓取內容。
Cloudflare 的 AI Crawl Control 就是針對這類情境設計的功能。根據 Cloudflare 官方文件，AI Crawl Control 可以用來管理 AI crawlers、分析 AI traffic、追蹤 robots.txt，以及控制 AI 爬蟲如何與網域互動。:contentReference[oaicite:3]{index=3}
使用 AI Crawl Control 可以做到：
- 查看哪些 AI 爬蟲正在抓取網站。
- 分析 AI traffic 對網站頁面的影響。
- 檢查 robots.txt 是否被遵守。
- 針對不同 AI crawler 採取不同動作。
- 決定哪些爬蟲允許、哪些限制、哪些封鎖。
Cloudflare 文件也提到，AI Crawl Control 可在 Crawlers 分頁針對每個 AI crawler 採取指定動作。:contentReference[oaicite:4]{index=4} 這代表網站主不需要把所有 AI 爬蟲一律封鎖，而是可以依照實際價值與風險做分類管理。
不是所有 AI 爬蟲都一定要封鎖。 有些可能帶來引用、搜尋、曝光或合作價值；有些則只會消耗資源、抓走內容，卻不帶回任何流量。重點是網站主要有能力看見它們、分辨它們，並對它們採取不同策略。
七、第五層防護：robots.txt 不是防火牆，但可以作為規則宣告
很多網站主會以為，只要在 robots.txt 寫上 Disallow，就能阻止 AI 爬蟲抓取網站。這是常見誤解。
robots.txt 本質上是規則宣告，而不是技術封鎖。Cloudflare 官方文件也明確說明，robots.txt compliance 是自願性的，它可以表達網站偏好，但不會在技術層面阻止爬蟲存取內容；若要強制阻擋，應使用 AI Crawl Control，也可以同時使用 robots.txt 表達偏好，再用 AI Crawl Control 執行封鎖。:contentReference[oaicite:5]{index=5}
| robots.txt 適合做的事 | robots.txt 不適合做的事 |
|---|---|
| 告訴合規爬蟲哪些路徑不希望被抓 | 阻止惡意爬蟲進站 |
| 管理搜尋引擎索引範圍 | 限制高併發請求 |
| 表達網站對 AI 抓取的偏好 | 防止偽裝 User-Agent 或直連源站 |
簡單來說，robots.txt 是告示牌，不是鐵門。真正的鐵門是 WAF、Rate Limit、AI Crawl Control、源站防火牆與正確的 CDN 架構。
八、第六層防護：隱藏源站 IP，避免爬蟲繞過 Cloudflare 直打主機
很多網站已經接上 Cloudflare，卻還是被打到主機滿載，原因可能是源站 IP 已經外洩。
如果攻擊者或爬蟲知道你的真實主機 IP，就可以繞過 Cloudflare，直接連到源站。這時候，不管你在 Cloudflare 上設定多少 WAF、Rate Limit 或 Bot 防護，都無法擋住直連源站的流量。
Cloudflare 官方建議，對於已代理的 DNS 記錄，應讓流量通過 Cloudflare，並在源站允許 Cloudflare IP；同時也應檢查 DNS-only 記錄，避免 TXT、SPF 等紀錄洩漏源站 IP。:contentReference[oaicite:6]{index=6} 另外，Cloudflare 也建議在源站防火牆阻擋非 Cloudflare IP 的流量，避免他人發現源站 IP 後繞過 Cloudflare 安全防護。:contentReference[oaicite:7]{index=7}
建議檢查以下項目：
- DNS 是否有開啟橘雲 Proxy。
- 是否有 DNS-only 記錄暴露真實 IP。
- 郵件、FTP、cPanel、DirectAdmin 是否與網站使用同一個暴露 IP。
- 歷史 DNS 紀錄是否曾公開源站 IP。
- 源站防火牆是否只允許 Cloudflare IP 連入 80 / 443。
Cloudflare 不是裝上去就一定安全。如果源站 IP 還裸露在外，等於前門有保全，後門卻沒有上鎖。
九、建議的 5 層 Cloudflare 防護配置
若要用 Cloudflare / CDN 協助阻擋 AI 爬蟲，建議不要只開一個功能，而是採用分層防護。
| 防護層級 | 主要功能 | 解決問題 |
|---|---|---|
| 第 1 層：DNS Proxy | 讓網站流量先通過 Cloudflare。 | 避免所有請求直接打到源站。 |
| 第 2 層：CDN 快取 | 靜態內容由 Cloudflare 節點回應。 | 降低源站頻寬與請求數。 |
| 第 3 層：WAF 規則 | 依 User-Agent、路徑、國家、ASN、IP 條件過濾。 | 阻擋可疑 Bot、異常路徑與高風險來源。 |
| 第 4 層：Rate Limit | 限制短時間大量請求。 | 避免高併發爬蟲打爆主機。 |
| 第 5 層：源站防火牆 | 只允許 Cloudflare IP 連入 Web 服務。 | 防止繞過 CDN 直打主機。 |
這五層不是互相取代，而是互相補強。CDN 負責減壓，WAF 負責過濾，Rate Limit 負責限制濫用，AI Crawler 管理負責辨識 AI 抓取行為，源站防火牆則負責防止繞路攻擊。
十、常見錯誤：為什麼用了 Cloudflare 還是卡？
很多網站已經使用 Cloudflare，但仍然會遇到網站變慢、CPU 滿載或流量爆炸，常見原因如下：
- DNS 沒有開啟橘雲 Proxy： 只有 DNS 解析，流量沒有真正經過 Cloudflare。
- 源站 IP 已經外洩： 爬蟲或攻擊者直接打 IP，不經過 Cloudflare。
- 沒有設定快取規則： 所有請求仍然回到源站處理。
- 沒有設定 Rate Limit： AI 爬蟲仍可短時間大量請求。
- WAF 規則太寬鬆： 可疑 Bot 沒有被挑戰或封鎖。
- 動態頁太多： 大量搜尋、API、會員頁請求無法單靠快取解決。
- 誤把 CDN 當成萬能： CDN 是第一道防線，不是完整資安與主機優化的全部。
Cloudflare 是防線，不是替代伺服器管理。真正穩定的架構，仍需要 CDN、WAF、Rate Limit、源站優化、主機防火牆與 Log 監控一起配合。
十一、什麼情況代表你該開始做 AI 爬蟲防護？
如果你的網站出現以下情況，就應該開始檢查是否有 AI 爬蟲或異常 Bot 流量：
- 流量突然增加，但訂單、詢問、轉換沒有同步成長。
- CPU、RAM、MySQL 長時間維持高負載。
- access log 出現大量相同 User-Agent 或規律請求。
- 搜尋頁、分類頁、標籤頁、文章分頁被大量請求。
- 圖片與靜態檔案流量明顯暴增。
- 網站開始出現 502、503、504 或資料庫連線不足。
- Cloudflare Analytics 顯示 Bot 或可疑流量比例升高。
這些現象不一定代表網站被攻擊，但代表網站正在承受不正常的資源消耗。若沒有及早處理，後續可能演變成主機過載、頻寬成本上升、SEO 受影響、廣告轉換率下降，甚至影響正常客戶瀏覽。
總結：Cloudflare 不是萬能，但它是 AI 爬蟲防禦的第一道重要防線
AI 爬蟲造成的問題，不只是流量變多，而是讓網站被迫處理大量沒有轉換價值、卻會消耗伺服器資源的請求。當這些流量直接打到源站，主機就會承受高併發、頻寬、資料庫與後端運算壓力。
Cloudflare / CDN 的核心價值，就是在源站前面建立一層緩衝與判斷機制。透過 CDN 快取減少回源、WAF 過濾可疑請求、Rate Limit 限制高頻存取、AI Crawl Control 管理 AI 爬蟲，以及源站防火牆防止繞過 CDN，網站才能真正降低 AI 爬蟲造成的卡頓與流量爆炸。
真正有效的防護，不是把所有流量都封鎖，而是把有價值的訪客留下，把無效消耗資源的流量擋在源站外面。
如果您的網站近期出現流量異常、後台變慢、CPU 滿載、頻寬暴增、502 / 503 錯誤，建議先從網站 Log、Cloudflare 流量分析、User-Agent、請求路徑與來源 IP 開始檢查，再依照實際狀況導入 CDN 快取、WAF 規則、Rate Limit 與源站防火牆。
網站防禦不是單一功能，而是一套分層架構。Cloudflare 是重要的第一道門，但真正穩定的網站，還需要正確的主機設定、資源配置、Log 分析與持續調整。
延伸閱讀
- AI 爬蟲卡頓原因解析： 為什麼 AI 爬蟲會讓網頁卡頓、流量爆炸？解析背後的技術真相
- AI 爬蟲防禦架構： 守住伺服器資源：阻斷惡意 AI 爬蟲的 4 階段防禦架構
