很多人排查抓取問题，习惯從頁面本身找原因：内容是不是太薄、内鏈是不是断了、Sitemap 是不是漏了 URL。但抓取動作的第一步並不在頁面上，而在更靠前的位置——蜘蛛得先解析出你的域名指向哪台机器，再和那台机器完成一次加密握手，最後才谈得上發送請求、讀取 HTML。這几步出了問题，源站訪問日誌里往往连一行记錄都没有，于是结论就變成了「蜘蛛一直没来」。
為什么抓取失敗有时连日誌都没有
訪問日誌记錄的是「已经到達服務器並被處理」的請求。如果蜘蛛在 DNS 解析阶段就失敗了，或者 TLS 握手被拒绝、连接還没建立起来就被重置，這些請求不會寫進日誌。此时你看日誌是干净的，看抓取統計却是零，两邊對不上。排查這類問题时，只盯着源站日誌會漏掉一大段鏈路，需要把 CDN、DNS 服務商、證书监控這些环节一起纳入视野。
第一道门：DNS 解析
蜘蛛拿到 URL 後，第一步是把域名換成 IP。這一步通常很快，但出問题的概率並不低，尤其是刚做過迁移的站点。
- TTL 設定過長：換 IP 之後，舊地址還會被各层递归解析器缓存一段時間。如果之前把 TTL 设成了 24 小时，切換期間的抓取可能會打到已经下线的机器上。
- CNAME 鏈太長：多個 CNAME 层层指向，解析過程變長，偶尔還會在中間某一环断掉。
- 泛解析與错誤子域：泛解析把所有子域都指向同一個地址，某些解析器返回的结果可能不符合预期，也容易让错誤子域被当成有效站点。
- 解析服務本身不稳定：權威服務器响應慢或間歇性超时，蜘蛛侧感受到的就是「這個域名时好时坏」。
自查方式很直接：用不同地区、不同运营商的公共解析服務去查同一個域名，看返回结果是否一致、响應是否稳定。如果只有部分地区解析異常，問题基本可以定位到 DNS 這一层。
第二道门：TLS 握手
解析出 IP 之後，現代站点大多要走 HTTPS。握手环节的常见問题有以下几類。
- 證书過期或域名不匹配：這是最干脆的一類失敗。證书到期当天，抓取量可能直接归零，而且源站日誌不會有任何记錄。
- 中間證书缺失：浏览器有时會自行补鏈，但抓取程序未必有這個容错，握手可能直接中断。
- 只支持過舊的协议版本：部分老服務器只開了很陈舊的 TLS 版本，抓取端拒绝协商，连接無法建立。
- SNI 配置不完整：同一台机器上挂多個站点时，如果預設站点没有兜底證书，訪問未匹配的域名會拿到错誤的證书。
- CDN 回源證书問题：用戶侧證书正常，但 CDN 回源到源站那一段證书有問题，抓取同样會在回源时失敗。
建议把證书到期時間纳入例行监控，而不是等抓取量掉了才去查。很多抓取中断事件，追溯到最後就是一張過期證书。
第三道门：连接建立與复用
握完手，连接真正建立起来，接下来才是請求和响應。這一层的問题不像證书過期那么明顯，但影响范围更广。
- Keep-Alive 時間過短：连接频繁断開重建，抓取端每次都要重新握手，整体吞吐會下降。
- 並發连接限制過嚴：防火墙或 WAF 對同一来源的並發连接做了很低的限制，抓取端拿不到足够的通道，只能排队等待。
- 握手阶段被限速或拒绝：有些防護策略在连接层面就拦截，看起来像是「服務器没响應」。
- 首字节時間過長：连接建立了，但服務器迟迟不返回第一個字节，抓取端等不到响應就超时断開。
- 源站與 CDN 的超时設定不一致：CDN 侧等待 60 秒，源站 30 秒就断開，结果两邊都認為自己正常，抓取端只看到失敗。
抓取被中断之後會發生什么
需要說明的是，單次连接失敗並不會立刻導致站点被放弃。抓取系統通常會把 URL 放回队列，間隔一段時間後重试；如果连續多次失敗，抓取频率會被調低，重试間隔逐步拉長。所以真正麻烦的不是偶發的失敗，而是持續性的、覆盖整個域名或整個 IP 段的失敗——它會让抓取节奏整体放缓。
一份可以照着走的排查顺序
- 從外部多個节点解析域名，確認返回结果一致且稳定。
- 检查證书的剩余有效期、證书鏈是否完整、是否覆盖所有使用的子域。
- 查看 CDN 的回源日誌，確認失敗發生在用戶侧還是回源侧。
- 對比源站日誌與 CDN 日誌，找出「CDN 收到了但源站没有」的那部分請求。
- 用不同的 User-Agent 和来源 IP 做一次手動請求，看是否被连接层面的策略拦截。
- 確認 Keep-Alive、超时、並發限制這几項配置在源站與 CDN 之間是對齐的。
抓取鏈路的前半段属于基础设施問题，它不体現在頁面质量上，却决定了蜘蛛有没有机會看到頁面。把 DNS、證书、连接這三項纳入日常监控，比事後反复检查内容更省力。