在抓取日志里，同一天同一个 URL，有时是 200，有时是 5xx，有时返回的 HTML 版本还不一样。这类“随机”现象，很多并不在页面本身，而在请求到达源站之前的那几层：DNS 解析、CDN 分发和回源链路。蜘蛛发出的请求与普通用户没有本质区别，它同样要先解析域名、落到某个节点，再由节点决定是否回源。
一次抓取要跨过几层
从蜘蛛到源站，大致经过：DNS 解析 → 边缘节点（如果有 CDN）→ 回源链路 → 源站应用。任何一层出现分化，蜘蛛拿到的结果就可能不一致。
- 解析层：同一域名在不同地区、不同运营商下解析到不同 IP。
- 节点层：边缘节点缓存命中与否，决定是否触发回源。
- 回源层：回源走内网还是公网，落到哪个源站机房。
- 源站层：应用与数据库的实际响应能力。
DNS 解析：蜘蛛看到的是哪个地址
如果域名做了智能解析或按线路分发，蜘蛛请求到的源站可能并不是你平时测试的那一台。常见现象是：你在本地反复访问都正常，蜘蛛却在日志里留下 502 或超时记录，因为它落在了一个负载不均、或者配置还没同步完的节点上。
需要留意的几件事：
- TTL 太短：解析频繁切换，蜘蛛可能把不同 IP 返回的内容当作同一站点的不同版本，抓取结果前后不一致。
- CNAME 链条太长：多级 CNAME 会增加解析耗时，也可能让部分抓取端解析失败。
- 解析记录不完整：只配了 A 记录没配 AAAA，或反过来，导致部分抓取端走了一条你没验证过的路径。
CDN 节点：缓存命中决定蜘蛛看到什么
CDN 让抓取路径多了一层不确定性。边缘节点命中缓存时，蜘蛛拿到的是缓存副本；回源时拿到的才是实时结果。如果缓存策略对 HTML 和接口采用了不同规则，就很容易出现“蜘蛛与用户看到不一样”的情况。
几个值得检查的点：
- 是否对动态页面设置了过长缓存，导致蜘蛛长时间抓到旧版本。
- 缓存键是否包含会造成分叉的参数，比如设备类型、地区、追踪参数。
- 节点回源失败时返回什么状态码，是明确的 5xx，还是伪装成 200 的错误页。
如果蜘蛛抓到的页面里出现“缓存过期”“节点异常”之类的字样，问题大概率不在内容层，而在分发层。
回源链路：稳定比快更重要
回源链路承担的是“节点缓存未命中就回源站取一次”的任务。它出问题时，表现往往不是整体打不开，而是间歇性的超时、连接重置或半截响应。这类不稳定对抓取的影响，比一次彻底宕机更麻烦：蜘蛛可能降低对站点的抓取频率，把有限的抓取预算挪向别处，等你恢复之后，也需要一段时间才会把节奏调回来。
常见的回源问题包括：源站只允许特定来源 IP、回源走公网时线路抖动、源站带宽被其他业务占满。这些值得单独拉一条监控来看，而不是等到抓取量下滑才回头排查。
排查顺序
- 先确认现象：从抓取日志里挑出失败率高的时间段和 URL 模式。
- 对照 DNS：在不同解析线路下查询域名，看是否指向不同 IP。
- 检查 CDN：对比节点响应的头部，确认缓存命中状态与缓存时间。
- 检查回源：在源站侧记录来源 IP 与回源域名，看失败请求从哪里进来。
- 做一致性对比：用固定的来源与 UA 反复取同一个 URL，观察内容是否波动。
可以顺手做的几件事
- 把解析 TTL 设在一个合理区间，避免频繁漂移。
- 让 CDN 回源失败时返回明确的状态码，不要把错误包装成 200。
- 为回源链路准备一个可观测入口，用来判断问题是否出在这一层。
- 保持各节点返回的 HTML 结构基本一致，减少蜘蛛对页面版本的困惑。
抓取路径上的问题，很多时候不是“蜘蛛不来”，而是它来的时候走了一条不稳定的路。把 DNS、CDN 与回源这三层理顺，往往比反复调整页面上的小标签更能稳定抓取结果。