站点接入 CDN 或云防护之后，抓取相关的现象往往会变形：源站日志里看不到蜘蛛，边缘日志里能看到但内容对不上，或者同一时间段不同地区的抓取表现完全不同。想搞清楚问题，得先把一条请求经过的几层拆开看。
一条蜘蛛请求通常要经过哪几层
从蜘蛛发起请求到拿到 HTML，大致是：蜘蛛 → DNS 解析 → 边缘节点 → 缓存判断 →（未命中时）回源站 → 源站应用与数据库 → 原路返回。任何一层出问题，表现都可能被归结为“蜘蛛抓得不好”。
- 边缘节点：决定用哪份缓存、是否触发防护规则。
- 缓存层：决定返回缓存副本还是回源，以及缓存多久。
- 回源链路：决定源站看到的 IP、协议和超时预算。
- 源站：真正生成 HTML 的地方，也是抓取真正消耗资源的地方。
最容易被误判的三种情况
1. 返回的是缓存副本，内容已经变了
站在蜘蛛角度，它拿到的还是旧版本。如果缓存时间较长，新发布的内容可能迟迟不被看到。排查方式是固定一个刚更新的 URL，连续请求几次，对比返回内容与源站内容是否一致，并查看响应头里的缓存标识。
2. 缓存命中率剧烈波动，回源被打爆
大站常见：蜘蛛集中抓取的时段，缓存陆续过期，回源请求堆上来，源站开始变慢甚至超时，蜘蛛那边看到的就是超时或 5xx。这种问题往往不是“蜘蛛抓太狠”，而是缓存策略和回源容量没有给足余量。
3. 安全防护把正常抓取挡在外面
部分防护规则按请求特征拦截，可能把蜘蛛和普通爬虫一起拦住，返回 403 或挑战页面。此时蜘蛛拿到的是拦截页，自然不会继续发现 URL。
蜘蛛看到的 IP 与源站日志的差异
经过 CDN 后，源站日志里记录的往往是边缘节点 IP，而不是蜘蛛的真实 IP。这会影响两件事：一是判断不清抓取是不是真的来了，二是按 IP 做的限流策略可能误伤。通常需要在回源时透传真实 IP 头（如常见的转发头），并在源站应用里按该头取真实来源。
一个可执行的排查顺序
- 固定几个代表性 URL：首页、列表页、详情页、刚更新页各一个。
- 用不同地区或不同出口分别请求，观察返回内容和状态码是否一致。
- 查看响应头中的缓存、节点、回源相关字段，判断命中还是回源。
- 对照边缘日志和源站日志，看同一时间点两侧记录是否对得上。
- 确认蜘蛛的真实 IP 是否被透传，防护规则是否放行。
- 检查回源超时设置与源站慢请求，看看是否存在超时之后的级联问题。
抓取问题发生在源站时，排查相对直接；发生在中间层时，症状会分散在多个环节，先把链路固定下来比急着改配置更有效。
配置上的几点注意
- 动态页面与列表页尽量短缓存或不缓存，静态资源可以长缓存。
- URL 参数参与缓存键时，注意别让同一页面因参数差异生成多份缓存。
- 回源超时不要设得过短，也不要让超时后的重试把源站压垮。
- 放行策略按已验证的来源做，而不是只看 User-Agent 字符串。
- 发布新内容后，可主动刷新对应 URL 的缓存，缩短被看到的时间。
把中间层当成抓取路径的一部分来看待，很多“蜘蛛不抓了”“抓的是旧内容”“日志里没有蜘蛛”的问题，会更容易定位到具体环节。