抓取日誌里出現成片的失敗记錄时，很多人的第一反應是内容质量、robots 規則或者内鏈结构。但有一類失敗發生在頁面内容之前——蜘蛛還没拿到任何 HTML，连接就已经断掉了。這類問题從頁面层面怎么查都查不出来，只能從域名解析、證书和服務器响應時間這三层入手。
DNS：解析不到，後面全是空谈
蜘蛛訪問的第一步是把域名解析成 IP。如果解析环节出了問题，後面的抓取、渲染、解析連結都不會發生，日誌里往往连一條請求记錄都没有，只看到抓取失敗或超时。
- 不同地区、不同递归解析器返回的 IP 不一致，部分线路指向已经下线的舊服務器。
- CNAME 指向的 CDN 或托管域名已经失效，但主域名的 NS 记錄没有同步更新。
- 權威 NS 變更後 TTL 設定過長，舊记錄還在各地缓存中生效。
- 只配置了 IPv4，而蜘蛛優先尝试 IPv6，连接直接失敗。
核對方法並不复杂：用几個公共 DNS 分別查询同一域名，比較返回的 A 记錄和 AAAA 记錄是否一致；再把服務器訪問日誌按時間拉出来，看這個時間段内是否真的存在来自搜尋蜘蛛的請求。如果 DNS 正常但日誌里一條都没有，問题可能出在更前面的鏈路上。
TLS 與證书鏈：浏览器能過，蜘蛛未必
證书鏈不完整是個容易被忽略的点。桌面浏览器遇到缺失的中間證书时，往往能自行补全，所以人工打開頁面一切正常，但抓取程序不會做這種补全，握手就會失敗。
- 中間證书没有随站点證书一起下發，部分客戶端無法构建完整信任鏈。
- 證书覆盖的域名與蜘蛛實际訪問的域名不匹配，例如只簽了裸域却訪問了 www。
- 證书已過期或即將過期，自動化监控没触發告警。
- 服務器只接受較新的 TLS 版本或加密套件，老版本抓取程序無法协商。
- SNI 未正确配置，同一 IP 上多個站点之間互相串了證书。
判断方法：用命令行工具模拟一次完整握手，观察是否提示證书鏈不完整或無法驗證。人工浏览器訪問成功，不代表抓取程序也能成功。
首字节時間：慢到超时，也算失敗
還有一種情况是连接建立了，證书也没問题，但服務器迟迟不返回第一個字节。抓取程序通常有等待上限，超過就记為超时或失敗，蜘蛛會带着這一頁空手离開。
- 頁面完全動態生成，每次都走一遍資料库慢查询。
- 模板中同步調用了第三方接口，對方响應慢會拖住整個頁面。
- 图片或附件在請求时實时压缩、裁剪，占用大量處理時間。
- 缓存层配置不当，命中率低，回源請求集中压在資料库上。
- 日誌寫入、統計上报等操作放在請求主流程里，随流量增長逐渐拖慢响應。
排查时不要只看平均值，重点看 P95 和 P99 响應時間，再對照抓取日誌里失敗记錄集中的時間段。如果失敗集中在某個时段，而那個时段服務器响應時間明顯拉長，方向就比較明确了。
防火墙、WAF 與訪問策略
如果服務器日誌里能看到請求，但狀態碼是 403、406 或者 429，那問题就在應用层之前的安全策略上。
- 安全组或防火墙是否屏蔽了搜尋蜘蛛常用的 IP 段。
- WAF 是否因為频率、UA 特征或請求參數把正常抓取判成了異常流量。
- 站点是否設定了地域限制，導致部分来源的抓取請求被拒绝。
- 是否有基于 UA 的黑白名單規則，規則本身寫错方向。
把搜尋蜘蛛的 UA 加進白名單只是第一步，更稳妥的做法是结合反向解析確認来源。否則任何程序都可以伪装成蜘蛛，白名單反而成了漏洞。
建议的排查顺序
- 先確認 DNS 解析在多地是否一致、是否可用。
- 再模拟一次完整 TLS 握手，看證书鏈和协议版本。
- 然後测量首字节時間，结合服務器监控定位耗时环节。
- 最後检查防火墙與 WAF 規則，確認請求有没有被拦在應用之外。
- 每一步都用服務器日誌與抓取日誌交叉對照，避免凭印象下结论。
站点的可用性是抓取的前提。内容再好、内鏈再清晰，蜘蛛连不上或者等不到响應，這一頁對它来说就是不存在的。把這几层網絡與响應問题先排干净，後面讨论抓取路径和 URL 發現才有意义。