蜘蛛的请求，先到 CDN，再到源站
排查抓取问题时，很多人的第一反应是打开源站日志。但如果站点前面挂了 CDN 或反向代理，蜘蛛的请求往往先落在边缘节点上——命中缓存就直接返回，根本不会走到源站。这时候源站日志里一片安静，很容易被误判成蜘蛛没来，方向从一开始就偏了。
一次抓取请求会经过哪几层
- DNS 解析：蜘蛛把域名解析到 CDN 提供的节点地址，而不是源站 IP。
- 边缘节点：判断该 URL 有没有可用的缓存副本，是否需要按 UA、Cookie 做区分。
- 回源：缓存未命中或已过期时，节点才向源站发起请求。
- 源站返回：源站的状态码和响应头会被节点记录，其中一部分会被缓存下来。
也就是说，蜘蛛看到的页面，有可能是几分钟前的，也可能是几天前的，取决于缓存策略怎么设。
缓存命中时，蜘蛛拿到的可能不是最新内容
旧版本 HTML 被缓存
HTML 文档如果被设了较长的缓存时间，页面更新之后，蜘蛛在缓存有效期内访问到的仍是旧版本。结果就是内容已经改了，抓取记录里却看不出任何变化。
错误状态码被缓存
更麻烦的是状态码。源站因为一次短暂故障返回 500 或 502，如果这类响应被节点缓存下来，蜘蛛在接下来一段时间里会反复拿到 5xx。反过来，页面在被删期间返回 404 并被缓存，即使后来恢复上架，蜘蛛仍可能继续拿到 404。这类问题在源站日志里往往看不到痕迹。
多节点版本不一致
不同地区的节点回源时间不同，同一个 URL 在不同节点上的版本可能不一样。蜘蛛从不同出口 IP 抓取时，看到的结果就会出现差异，表现成时好时坏、飘忽不定。
几个可以自查的信号
- 源站日志里缺少某段时间的蜘蛛记录，但 CDN 访问日志里有。
- 页面已经更新，蜘蛛抓取之后缓存里仍是老内容。
- 同一个 URL 的状态码在 200、404、5xx 之间来回跳。
- 不同地区抓取结果不一致，或者只有部分节点表现异常。
- 蜘蛛 UA 被 WAF 或人机校验拦下，返回的是验证页而不是正文。
把缓存策略和抓取策略对齐
- HTML 文档不要设过长的缓存时间，或改用协商缓存，让节点能及时向源站确认版本。
- 静态资源如 CSS、JS、图片可以长缓存并加上指纹，它们不参与 URL 发现。
- 源站返回 5xx 时，明确告诉 CDN 不要缓存这类响应。
- 希望蜘蛛看到与用户一致的内容时，注意 Vary 头、UA 白名单和缓存键的设计。
- 更新 URL、robots.txt、Sitemap 之后，把刷新流程走一遍，不要只改源站。
- 把 CDN 访问日志和源站日志按时间对齐来看，才能还原完整的抓取路径。
别让安全策略把蜘蛛当成攻击者
有些站点为了防采集，开了频率限制或 JS 挑战。处理不当会出现两种结果：一是蜘蛛直接拿到 403、429；二是返回 200，但正文是校验脚本，蜘蛛拿到的是空壳。后者更难发现，因为状态码看上去完全正常，和软 404 的表现很像。
缓存层的目标是让访问更快，不是让内容更难被发现。凡是会让蜘蛛拿到的版本与真实内容不一致的设置，都值得重新检查一遍。
做站点运营时，把抓取问题只当成源站问题，很容易漏掉中间那一层。养成同时看 CDN 日志、源站日志和缓存命中率的习惯，很多看似莫名其妙的现象，其实都能找到出处。