在抓取日誌里，同一天同一個 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 與回源這三层理顺，往往比反复調整頁面上的小标簽更能稳定抓取结果。