不少站点在接入 CDN 之後，抓取日誌會出現一種让人摸不着头脑的現象：同一批 URL，今天返回正常，明天變成 403 或 404；不同抓取来源拿到的内容還不一致。源站代碼没動，配置也没改，問题往往出在 CDN 的回源與缓存規則上。搜尋蜘蛛的訪問路径比普通用戶更長，要经過节点調度、缓存判断、回源請求這几层，任何一层出問题，最终都會表現為抓取不稳定。
為什么 CDN 會让抓取表現忽好忽坏
普通用戶訪問时，命中缓存就結束了；而抓取行為常常是在短時間内對大量 URL 發起請求，缓存命中率低、回源比例高。這时 CDN 的缓存規則、回源並發上限、源站限流策略會被同时放大，平时看不出来的配置問题就會集中暴露出来。
四類高频成因
回源 Host 與證书绑定不一致
如果回源 Host 寫成了非主域名，或者源站只绑定了带 www 的證书，回源請求就可能被源站判為無效域名，返回 404 或證书错誤。抓取端看到的是一批 URL 集体失效，而用戶因為命中了邊缘缓存，感知並不明顯。這類問题最容易造成“日誌里全是错誤、頁面却能正常打開”的错觉。
缓存規則對爬虫 UA 做了区別對待
有些配置會為特定 UA 設定不缓存或强制回源，本意是保證内容實时，结果却是抓取請求全部压在源站上。一旦源站响應變慢，抓取端就開始超时重试，抓取量随之波動。比較稳妥的做法，是让爬虫與普通用戶的缓存策略保持接近，避免人為制造回源尖峰。
节点缓存不一致與回源超时
CDN 节点數量多，缓存刷新並非瞬时完成。若回源超时阈值設定過短，部分节点在源站稍慢时就會返回 5xx，抓取端记錄到的失敗會集中在某些时段或某些地区。排查时不要只看總体成功率，要按节点、按时段拆分来看。
源站限流與回源並發叠加
源站出于保護設定了 IP 級或连接級限流，而 CDN 回源 IP 相對集中，抓取高峰时容易被整段限流。表現是短時間内大量 429 或 503，過後又自動恢复，让人誤以為是偶發故障。
建议的排查顺序
- 先在 CDN 日誌中按狀態碼分组，確認異常集中在回源环节還是邊缘环节。
- 挑几條失敗 URL，用相同 Host 和 UA 直接請求源站，驗證源站本身是否正常。
- 對比回源 Host、證书绑定與源站监听配置是否一致。
- 检查缓存規則中是否存在针對爬虫 UA 的特殊分支。
- 查看源站限流日誌，確認是否有回源 IP 被批量拦截。
- 最後再調整回源超时與重试參數，避免用放大重试的方式掩盖真實問题。
日誌對照與驗證方法
- CDN 侧關注狀態碼分布、缓存命中率與回源耗时。
- 源站侧關注真實請求量、限流次數與连接排队情况。
- 两邊日誌按時間戳對齐，观察異常是否同步出現。
- 調整配置後至少观察一個完整的抓取周期，不要只看当天資料。
長期维護习惯
- 回源策略尽量固定，避免频繁切換 Host 或證书。
- 爬虫與普通用戶的缓存規則保持一致，减少回源尖峰。
- 為抓取相關指标單獨設定告警，而不是混在整体可用性里。
- 配置變更留记錄，出問题时能快速對照時間点回溯。
抓取波動很少由單一原因造成。把 CDN 與源站当成一條完整鏈路来看，比在某一层反复猜测更有效。