很多站点在接入 CDN 之後，服務器日誌里蜘蛛的訪問记錄會明顯變少。有人以為是抓取下降了，其實只是請求被 CDN 节点接走了，没有回到源站。搞清楚蜘蛛的請求落在哪一层，是排查抓取異常的第一步。

一次蜘蛛請求會经過哪些环节

從蜘蛛發出請求到你的源站程序處理，中間通常要穿過 DNS 解析、CDN 邊缘节点、WAF 或防火墙、负载均衡，最後才到源站。任何一层做了拦截、缓存或改寫，蜘蛛拿到的内容都可能和你本地看到的不一样。

缓存命中时，蜘蛛拿到的是什么

CDN 命中缓存时，源站根本不會收到這次請求，日誌自然也不會有记錄。這本身不是坏事，响應更快對蜘蛛是好事。但要注意两点：

• 缓存的是舊版本 HTML，頁面已经改過，蜘蛛拿到的還是昨天的内容。
• 缓存的是错誤响應，比如把一次 5xx 或跳轉頁面缓存住了，後續蜘蛛持續拿到同样的结果。

检查缓存規則

静態资源長缓存問题不大，HTML 文档的缓存時間建议短一些，改版或批量更新後主動刷新缓存。對返回 4xx、5xx 的响應，一般不要長期缓存。

按 UA 给蜘蛛單獨放行，值不值得

有的配置會按 User-Agent 区分，给蜘蛛走一條特殊鏈路，比如绕過缓存直接回源。這样做的代價是：蜘蛛看到的頁面和普通用戶不一样，一旦两套逻辑不一致，排查成本會高出很多。UA 可以被伪造，單纯按 UA 放行也不等于安全。更稳妥的做法是让蜘蛛走和普通用戶相同的鏈路，只對明顯的異常流量做限速。

日誌该在哪一层看

如果只看源站日誌，會漏掉所有被 CDN 和 WAF 拦下的請求。判断抓取情况时，建议把 CDN 訪問日誌和源站日誌對照着看，重点確認：

• 蜘蛛 IP 是否真的是搜尋引擎的，可用反向解析或官方 IP 段比對。
• 返回的狀態碼分布，是不是有大量 403、429、5xx。
• 被拦截的請求里，有没有正常的内容頁被誤伤。

CDN 侧通常會提供實时日誌或日誌下载，注意日誌有延迟，別拿几分钟前的資料下结论。

日常配置的几條建议

1. 確認 CDN 没有對 HTML 文档設定過長缓存，改版後记得刷新。
2. 確認 WAF 規則不會因為路径里的參數或特殊字符誤拦内容頁。
3. 如果用了 IP 白名單或驗證，先核對官方公布的蜘蛛 IP 段，並定期更新。
4. 限速策略要区分開，別把正常的抓取請求和異常爬虫用同一條規則處理。
5. 迁移 CDN 或調整回源配置後，抽查几類頁面的實际响應。

怎么自己驗證一遍

最简單的办法是用蜘蛛的 UA 請求一個頁面，看返回的 HTML 和狀態碼：

curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" -I https://example.com/some-page

先看狀態碼和响應头，再去掉 UA 參數請求同一個地址，對比两者是否一致。同时观察源站日誌里有没有這條請求，就能判断請求停在了哪一层。

蜘蛛拿不到内容，原因常常不在頁面本身，而在請求到達源站之前的某一环。先把鏈路查清，再谈内容優化，顺序才不會反。

CDN 只是整條鏈路里的一段，但它是最容易被忽略的一段。定期把邊缘日誌和源站日誌對一遍，很多"抓取變少"的疑問都能自己解释清楚。