抓取異常往往被归因到内容层：是不是頁面太薄，是不是内鏈不够。但排查到後面會發現，蜘蛛根本没走到頁面這一步。域名解析、邊缘节点、回源這几层只要有一层不稳，訪問日誌里呈現出来的就是超时、5xx，或者反复取到舊版本内容。對站点运营来说，這些配置平时不用天天動，但一旦要動，就必须知道風險在哪。
蜘蛛拿到一個頁面要经過几层
大致路径是：解析域名得到 IP，請求打到 CDN 邊缘节点，节点判断缓存是否命中，未命中則回源到源站取内容。任何一层出错，最终表現都可能是抓取失敗，但原因完全不同。区分清楚层級，才不會在错誤的地方反复改内容。
DNS 层容易忽略的几件事
TTL 與變更节奏
- TTL 设得過長，比如 24 小时，換 IP 之後蜘蛛仍可能按舊记錄訪問，出現一段時間的失敗。
- TTL 设得過短會增加解析压力，也可能让缓存频繁失效，通常 300 到 600 秒是比較常见的取值。
- 變更前後留出观察窗口，不要在流量高峰或内容集中更新时切換解析。
记錄本身的一致性
- 同一主机名下存在多條互相冲突的 A 记錄，或者 CNAME 鏈拉得很長。
- 配了 AAAA 记錄但服務器並未监听 IPv6，部分請求會走到一個不通的地址上。
- 主域名與 www 域名的解析目标不一致，導致两套入口的可用性不同。
NS 與多线路解析
只依赖單一 NS 服務商，一旦解析服務波動，整站入口都會受影响。分线路解析时也要注意，不要给某些线路返回了不可用的节点，尤其是搜尋引擎常用的出口线路。
CDN 回源常见的几個坑
回源 Host 與證书
回源 Host 填错，源站可能返回預設站点甚至 404，蜘蛛拿到的是一個完全無關的頁面。走 HTTPS 回源时，還需要 SNI 與源站證书匹配，否則握手阶段就断了，表面看是抓取超时。
缓存規則
- HTML 被缓存過久，内容更新後蜘蛛仍取到舊版本，索引跟着滞後。
- 缓存键忽略了影响内容呈現的參數，導致 A 地址返回了 B 地址的内容。
- 错誤頁被缓存並長期返回，原本临时的故障變成了持續的抓取失敗。
回源频次與放行
- 回源限速過嚴，或者源站 WAF 把回源請求判定為異常流量直接拦截。
- 源站没有放行 CDN 节点 IP 段，導致回源請求被拒。
- 多地节点回源表現不一致，某些地区取到的内容明顯更舊。
怎么判断問题出在哪一层
- 先看訪問日誌里的狀態碼分布和耗时分布，確認失敗是集中的還是零散的。
- 用多地解析查询工具對比，看不同地区拿到的解析结果是否一致。
- 直接带 Host 头請求源站 IP，對比源站响應與通過 CDN 訪問的响應是否一致。
- 查看 CDN 的缓存命中率與回源日誌，確認失敗發生在邊缘還是源站。
這一步的價值在于把問题范围缩小。如果源站直连正常、通過 CDN 異常，那大概率是缓存或回源配置；如果直连也失敗，才需要回头看源站本身。
變更时的操作建议
- 配置調整尽量小步走，先在小范围或單條线路上驗證。
- 更換解析目标时，舊记錄先保留一段時間，確認新地址稳定後再收回。
- 變更後的 24 到 72 小时内，重点盯蜘蛛的訪問狀態碼和抓取量變化。
- 把每次解析和缓存規則的變更记錄下来，出問题时能快速回溯到時間点。
解析和缓存属于看不见的入口。它們不出問题时没人會想起，一旦出問题，就是整段整段地把抓取挡在半路上。