站点管理人員常遇到這样的情况：日誌里看不到蜘蛛的請求，或者請求来了却没抓走頁面，于是第一反應是改 robots、改内鏈、加 Sitemap。但抓取一個 URL 本身是分段完成的，在蜘蛛讀到 HTML 之前，它已经走了好几步。先把失敗落在哪一层找出来，比盲目改站点更省事。
一次抓取要经過的几個阶段
1. 域名解析
蜘蛛先要把 URL 里的域名解析成 IP。這一步的常见問题包括：權威 DNS 响應慢、解析结果不稳定（不同节点拿到不同 IP）、CNAME 鏈路過長。表現往往是抓取时断时續，而不是彻底抓不到。如果站点用了多线路解析或智能 DNS，需要確認所有线路都能正常响應。
2. 建立连接與 TLS 握手
解析到 IP 之後要完成 TCP 连接，HTTPS 站点還要做 TLS 握手。證书過期、證书鏈不完整、只支持老舊的加密套件，都可能让握手直接失敗。這類問题在浏览器里容易被缓存掩盖，而蜘蛛每次都是新连接，反而更容易撞上。
3. 發送請求，等待首字节
請求發出去之後，服務器什么时候返回第一個字节（TTFB）很關键。如果頁面是動態生成的，資料库慢、接口阻塞、缓存未命中，都會把 TTFB 拉長。蜘蛛在连接上等待的時間是有限的，超时之後它拿不到任何内容，只會记一次失敗。
4. 讀取响應头
响應头决定蜘蛛接下来怎么處理這個地址：狀態碼是 200 還是 301、有没有 noindex、内容類型是不是 text/html。很多抓取異常並不是打不開，而是打開後被告知「不要這個版本」。
5. 讀取正文
拿到正文才算真的抓完。正文被中途截断、压缩方式不支持、编碼声明和實际编碼不一致，都會让蜘蛛拿到残缺内容。頁面体积過大时，也可能只取到前面一部分。
怎么判断卡在哪一层
- 服務器日誌里连连接记錄都没有：大概率在解析或網絡可達性這一层。
- 有连接但没有完整的請求行：多半卡在握手阶段，或连接被中途關閉。
- 有請求行、長時間没有响應狀態：重点看後端處理時間和超时設定。
- 有狀態碼但内容為空：检查响應头、压缩方式與輸出逻辑。
几個容易被忽略的细节
- 多节点环境：负载均衡後面的机器配置不一致，就會出現「有时能抓、有时不能抓」。
- 错誤頁面本身也慢：如果 404、500 頁面還要跑完整套框架，失敗請求同样消耗资源。
- 拦截设备在中間：WAF 或防護策略可能让连接在握手後就被切断，日誌里看起来像客戶端主動断開。
- IPv6 與 IPv4：只配好一邊，另一邊解析出来却连不上，會造成間歇性失敗。
抓取失敗是一個结果，不是原因。把 DNS、连接、TLS、首字节、正文這几個阶段分開看，能很快缩小范围。
可以按顺序做的小检查
- 用蜘蛛的 UA 從外部节点實际請求一次，確認完整鏈路是否正常。
- 對比带缓存和不带缓存的响應時間，看慢在哪一段。
- 检查證书有效期與證书鏈，尤其是 CDN 回源的那一段。
- 確認错誤頁面和重定向不會拖慢服務器，也不要引發額外的重试風暴。
- 观察一段時間内的失敗分布，是個別 IP、個別目錄，還是全站范围。
把這些分层看清楚之後，再回头調整内鏈、Sitemap 或者抓取频次，思路會清晰很多。蜘蛛能不能稳定抓到内容，取决于整條鏈路，而不只是頁面本身寫得好不好。