首頁 / 技術文章 / CDN 快取如何影響 AI 爬蟲觀測：邊緣與源站日誌的對帳方法
技術文章
CDN 快取如何影響 AI 爬蟲觀測：邊緣與源站日誌的對帳方法
有 CDN 時，應以邊緣請求為母體，依爬蟲與快取狀態拆分，再核對哪些請求抵達源站。兩層日誌的差距可能同時造成總量低估與組成偏移，不能用全站快取命中率直接換算。
源站少記的請求，可能集中在特定內容與爬蟲
這套對帳方法先區分兩個觀測目標：邊緣日誌用來盤點抵達 CDN 的存取嘗試，源站日誌用來核對實際回源的請求。若請求由邊緣快取直接回應，或在邊緣遭到阻擋，對帳時就不應期待源站一定有對應紀錄。源站沒有紀錄，本身不足以判定爬蟲沒有來過。
Cloudflare 對 AI 流量的描述提供了拆分觀測的理由：AI 機器人經常大量、並行發出請求，存取罕見或關聯鬆散的內容，也常依序完整掃描網站。這些行為特徵來自業者的觀察，不能直接當成每個網站、每種爬蟲的共同模式。
本站據此判斷，若人類請求集中在可重複利用快取的熱門頁面，而某個 AI 爬蟲持續讀取長尾內容，後者可能更容易穿透到源站。於是，源站記到的 AI 請求絕對量雖然較少，AI 占源站全部請求的比例卻可能較高。這是選擇性留下某些請求的觀測偏誤，實際方向與程度仍須逐站驗證。
先建立互斥分類，再逐項核對回源請求
建議先固定網域、時間區間、時區與爬蟲分類方式，並確認兩層資料的涵蓋範圍一致。對帳單位採每次請求，不要混用訪客數、頁面數與請求數。安全處置與快取狀態則分欄保存：challenge／block 在這裡代表處置結果，不是與 hit、miss 同類的快取狀態。
為了加總，先把在邊緣終止的請求歸入安全處置組，再替其餘請求分類。下表是建議的對帳模型，並非 CDN 產品的完整狀態規格；只有 miss 與 bypass 被列為預期回源的主要組別，其餘無法確認的狀態保留待查，避免硬塞進既有分類。
| 對帳分類 | 本文採用的分類條件 | 源站對帳預期 | 差距如何解讀 |
|---|---|---|---|
| hit（H） | 確認由邊緣快取直接完成回應 | 通常不需有對應回源紀錄 | 屬於源站統計未涵蓋的邊緣服務量 |
| miss（M） | 未命中快取，預期向源站取得內容 | 列入應核對的回源候選 | 未配對者繼續查請求路徑與記錄範圍 |
| bypass（B） | 略過快取，預期送往源站 | 列入應核對的回源候選 | 與 miss 分開，避免把設定效果誤當內容冷門 |
| challenge／block（C） | 確認在邊緣被挑戰或阻擋，該次請求未回源 | 不應要求有內容回源紀錄 | 代表存取嘗試，不能算成內容成功交付 |
| 待查（U） | 狀態缺漏，或無法由現有欄位判定路徑 | 暫不預設 | 保留對帳缺口，另查產品狀態與日誌設定 |
在上述互斥分類下，邊緣總請求 E 可記為 E = H + M + B + C + U。其中 M + B 是待核對的回源候選量，不宜直接宣布等於源站筆數。這個等式只是分類帳；它不保證每個候選請求都能在另一層找到完整紀錄。
- 先統一身分分類：兩層使用相同的爬蟲名稱與判定依據，將僅依 user-agent 分類、尚未驗證的請求另外標示。
- 優先以兩層都保存的請求 ID 配對；若沒有共同 ID，再以時間、路徑、方法與身分欄位輔助核對，並標記配對的不確定性。
- 檢查客戶端 IP 欄位的來源，確認源站紀錄的是原始客戶端還是 CDN；需要轉發資訊時，應核對其可信來源。
- 分別列出邊緣回源候選未配對、源站紀錄未配對的項目，再查時間範圍、欄位與記錄方式，不把全部殘差歸因於快取。
各爬蟲的快取命中率，要先交代分母
本文建議為每種爬蟲計算邊緣快取吸收率：H / (H + M + B)。這是以服務路徑為目的定義的各爬蟲快取命中率，刻意把 bypass 放進分母，用來評估快取實際吸收了多少已分類、未在邊緣被攔下的請求；它不應直接視為 CDN 後台同名指標的公式。
challenge／block 不納入這個分母，因為此處要衡量的是快取吸收效果，而非安全攔截效果。待查項目也先排除，但必須同時揭露其數量；分母為空時則不計算。若把攔截量混入未命中量，就可能把有效的封鎖誤讀成快取表現變差。
比較時應讓各爬蟲與人類流量使用相同公式，再依內容路徑拆分。依 Cloudflare 描述的行為推論，完整掃描與長尾讀取可能讓部分爬蟲的吸收率較低，但目前沒有足以套用到所有網站的固定差距。因此，全站命中率即使看似正常，也不能據此推定個別爬蟲的回源負擔沒有改變。
Vary 與快取鍵會改變日誌中的流量組成
Cloudflare 的 Cache 公告指出，自 2026 年 9 月 22 日起，所有方案的 Cache Rules 都支援 Vary；可正規化已知的協商標頭、將精確值傳到源站，或在變化難以預測時略過快取。這些選項讓快取設定也成為解釋兩層日誌差距時必須保存的背景資料。
可檢驗的假設是：若網站依 Accept 提供不同內容，或以 user-agent 區分快取鍵，請求能否共用快取就可能改變；區分得越細，也可能越難重複命中。若將某類原本可命中的請求改為略過快取，對帳分類便可能從 hit 轉向 bypass。此時源站爬蟲紀錄增加，未必代表邊緣收到更多爬取嘗試。
因此，比較設定變更前後時，應一起保留快取規則、協商欄位與內容版本的差異。提供 Markdown 的網站，可搭配內容協商與 CDN 快取的驗收方法，檢查內容區分是否符合預期；不能只為了提高命中率，就忽略不同回應是否適合共用快取。
robots.txt 要分開看爬蟲端與 CDN 端快取
RFC 9309 是 IETF 於 2022 年 9 月發布的 Standards Track 文件，內容包含 Robots Exclusion Protocol 的錯誤處理與快取說明。因此，分析 robots.txt 讀取紀錄時，不能預設爬蟲每次存取內容前都會重新向源站取得規則。
這裡應拆開兩種可能：爬蟲若仍使用自身快取的規則，當次內容存取未必伴隨新的 robots.txt 請求；若它重新請求 robots.txt，而 CDN 又直接以快取回應，源站仍可能沒有新增紀錄。兩層快取疊加後，源站抓取頻率就不適合拿來直接衡量規則查閱頻率。
由此只能得出有限的判斷：源站沒記到 robots.txt，不能證明爬蟲未遵守規則；記到一次，也不足以證明後續都遵守。若要評估規則更新後的行為，建議比對邊緣交付的規則版本與後續內容請求。本篇不指定爬蟲快取時長，也不推定個別業者採用相同策略。
容量、封鎖與 AEO 觀測，需要不同的判讀重點
容量規劃應優先核對實際回源的部分，再搭配資源消耗資料；請求數適合作為對帳起點，不宜直接代替成本估算。封鎖評估則應回到邊緣處置結果：源站請求減少，可能來自快取吸收，也可能來自攔截，兩者對存取政策的意義不同。
AEO／GEO 觀測應追到目標頁面的回應結果。hit 可以支持該次請求由快取處理的判讀，challenge／block 則不能算成內容交付；即使確認內容已交付，也不應進一步推定它被用於答案或獲得引用。這段證據界線可搭配AI 搜尋取得網頁的分階段檢查理解。
若要把爬取量用於授權或收費談判，本站建議先約定計價事件：存取嘗試、成功交付與實際回源，不能混成同一個數字。爬蟲歸屬也應有獨立證據，可參考爬蟲身分驗證與流量分類的區別；尚未驗證的分類，不宜直接當成特定業者的使用量。
判讀重點是差距的來源，不是把數字調成一致
兩層日誌不必呈現相同總量，但差距應盡可能有可追查的去向。較有用的監測結果，是每種爬蟲的快取吸收率、略過快取量、邊緣攔截量與未配對項目。當源站 AI 占比上升時，先確認是存取增加、內容分布改變，還是快取規則改動，再決定是否擴容、調整政策或重新估算授權價值。
常見問題
能用源站請求數除以全站未命中率，推算 AI 爬蟲總量嗎？
不建議。這種換算假設爬蟲與全站流量具有相同的快取表現，也忽略 bypass 與邊緣攔截。應以邊緣請求為母體，逐一爬蟲拆分狀態，再核對回源紀錄。
各爬蟲的快取命中率應如何計算？
本文建議以 H／（H＋M＋B）衡量邊緣快取吸收率，分別代表 hit、miss 與 bypass。挑戰／阻擋及待查項目另外列出，分母為空時不計算。這是本文的分析定義，與 CDN 報表比較前須先確認分母一致。
源站沒有 robots.txt 紀錄，是否表示爬蟲沒遵守規則？
不能據此判定。爬蟲可能使用自身快取的規則，也可能重新請求後由 CDN 快取回應。規則取得紀錄與後續內容存取行為應分開檢查。
CDN 記到 AI 爬蟲請求，能當成 AI 搜尋收錄或引用證據嗎？
不能直接當成收錄或引用證據。應先區分請求是否被攔截、是否成功交付內容；即使已交付，也不宜推定內容後續被採用或引用。