做抓取排查时，多數人第一反應是看 URL 能不能打開、Sitemap 有没有提交。但蜘蛛的每一次抓取，在真正拿到 HTML 之前還有一段很長的路：解析域名、建立 TCP 连接、完成 TLS 握手、發出請求、等待服務器返回第一個字节。這段路走得不顺，表現往往不是抓取失敗，而是抓取量慢慢往下掉，很难被察觉。
一次抓取請求的完整鏈路
把蜘蛛当成一個普通的 HTTP 客戶端，它的單次請求大致经過下面几步：
- DNS 解析：把域名換成 IP，涉及本地缓存、递归解析器和權威服務器。
- TCP 连接：三次握手，跨地域时這一步的耗时就很明顯。
- TLS 握手：證书校驗、密钥协商，HTTPS 站点必走。
- 發送請求並等待首字节：也就是常说的 TTFB，服務器真正開始處理的時間。
- 传輸正文：HTML 越大、带宽越紧，這一步越慢。
蜘蛛通常會复用连接，在一個连接上连續抓多個頁面。但如果站点分布在多個 IP、使用多個子域，或者连接被中途断開，上面這套流程就得重走一遍。
DNS 解析：第一道容易被忽略的延迟
DNS 出問题的常见表現是：同一條 URL，你本地打開很快，蜘蛛却经常超时。原因可能是權威服務器响應慢、递归解析器在部分地区解析失敗，或者返回的 IP 里混進了已经下线的节点。
- 域名的 NS 是否有多地冗余，單点故障會直接掐断抓取。
- TTL 设得過短，解析器频繁回源，高峰期容易丢包。
- 解析结果是否稳定，多机房返回的 IP 是否都真實可用。
這些检查用 dig 或在线多地点解析工具几分钟就能做，但很多站点從来没做過。
TLS 握手：證书鏈與协议细节
HTTPS 站点在 DNS 之後還有一轮開销。證书鏈不完整时，部分客戶端需要額外回源补證书，時間會被拉長；服務器没開啟會话复用，蜘蛛每次新连接都要重新协商；OCSP 校驗如果走的是外部地址且响應慢，也會拖後腿。
- 確認證书鏈完整，中間證书已部署。
- 尽量啟用 TLS 1.3 與會话票據，减少重复握手。
- 開啟 OCSP Stapling，避免客戶端自己去查吊销狀態。
首字节時間：服務器真正干活的部分
TTFB 高，通常不是網絡問题，而是服務器端的問题：資料库慢查询、缓存未命中後穿透到後端、頁面渲染依赖同步調用外部接口，都會让蜘蛛在连接上干等。抓取量在流量高峰期下滑，很多时候就是 TTFB 被业務請求挤上去了。
可以按抓取来源單獨統計响應時間，看看蜘蛛請求的 P95 是否明顯高于普通用戶。
连接复用與並發限制
長连接和 HTTP/2 能让蜘蛛在同一连接上连續取多個资源，减少握手開销。反過来，如果服務器因為防護策略把同一 IP 的並發压得很低，或者频繁主動断開连接，蜘蛛就會反复重连，單位時間能拿到的頁面數量自然下降。
- 检查 WAF 或限流規則是否把蜘蛛的並發压到极低。
- 確認 keep-alive 超时不要太短。
- 避免在抓取高峰期做全站發布、重啟等操作。
自查顺序
- 用带計时輸出的 curl 請求几個代表性 URL，拆出 DNS、连接、TLS、TTFB 各段耗时。
- 換几個不同地域的节点重复一次，確認不是單点問题。
- 在服務器訪問日誌里篩選蜘蛛的 UA，統計响應時間和 5xx 比例。
- 對照抓取量曲线，看波動是否和服務器指标同步。
连接阶段的故障很少以抓取错誤的形式报出来，它更像一種慢性损耗：蜘蛛来得了，但拿得慢，于是来得越来越少。
小结
抓取不是從 HTML 開始的，而是從 DNS 開始的。把解析、握手、首字节這几段拆開看，很多抓取量無缘無故下滑的問题就有了解释。這類優化不需要改動頁面内容，收益却直接体現在蜘蛛單位時間能覆盖的 URL 數量上。