不少站点在接入 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 与源站当成一条完整链路来看，比在某一层反复猜测更有效。