聊抓取时，注意力通常放在内容、連結和 Sitemap 上。但蜘蛛真正拿到一個 URL 之前，還有一段看不见的路要走：域名解析、建立连接、加密握手。這一段走不通，頁面再干净也不會被讀到。
DNS 解析：抓取鏈路的第一道门槛
蜘蛛拿到 URL 後先要把它換成 IP 地址。這一步的耗时和稳定性，取决于域名解析服務本身，而不是你的服務器。
- TTL 設定：TTL 太短，解析记錄频繁變動，抓取端的缓存命中率低，每次都要重新問一遍；TTL 太長，迁移 IP 後舊地址還會被繼續用上一段時間。
- CNAME 层級：為了接入 CDN 或第三方服務，不少人叠了三四层 CNAME。每多一层就多一次查询，解析失敗的窗口也更大。
- 解析一致性：不同地区、不同解析节点返回的 IP 可能不同。如果其中某個节点返回了已经下线的 IP，抓取就會表現為間歇性失敗，而不是全站挂掉。
连接與握手：還没發請求就已经花了時間
解析完成後是 TCP 三次握手，HTTPS 站点還要再加一轮 TLS 握手。這两步都發生在服務器真正處理請求之前。
- TLS 版本：TLS 1.3 完成握手通常比 TLS 1.2 少一個往返，在高频抓取的场景下，累积起来是可见的差距。
- 證书鏈：中間證书缺失时，部分客戶端需要額外去取，握手時間被拉長，個別情况下直接失敗。
- 吊销狀態检查：配置不当會让握手多一次外部請求，而這個請求本身也可能超时。
- 协议選擇：HTTP/2 可以在同一连接上复用多個請求，對密集抓取更友好；但如果服務端配置不稳，反而容易出現连接被重置。
首字节之前的時間，都算在抓取成本里
很多站長只盯着服務器执行脚本的耗时，實际蜘蛛感知到的等待是從解析域名那一刻開始的。解析、握手、排队、處理、返回，任何一段變慢，抓取节奏都會跟着變。抓取频率的高低，不只看内容质量，也看這條鏈路稳不稳。
连接层的開销為什么會拖慢整体抓取量
蜘蛛和浏览器不同，它同时挂着大量待抓 URL。如果每個连接都要重新解析、重新握手，抓取端的连接池就被這些“准备工作”占住了。表現就是：日誌里抓取條數下降，但服務器负载看起来並不高。
抓取變慢时，先分清是“内容處理慢”還是“连接建立慢”，两者的排查方向完全不同。
可以顺着做的检查
- 用命令行工具拆解耗时，看解析、连接、握手各阶段分別占了多少。如果域名解析阶段就很高，問题不在服務器。
- 检查 CNAME 鏈有几层，能合並的合並，別為了省事一层层往上套。
- 核對證书鏈是否完整。浏览器能訪問，不代表所有客戶端都能顺利握手。
- 確認服務器在连接层没有做限制，例如防火墙對同一来源的並發连接做了裁剪。
- 看日誌里失敗請求的分布：如果集中在某個時間段或某類解析结果上，多半指向解析或網絡鏈路，而不是頁面本身。
小结
URL 發現、内鏈和 Sitemap 解决的是“蜘蛛知不知道该来”，DNS、连接和握手解决的是“蜘蛛来了能不能顺畅拿到”。後者平时不出問题就不顯眼，一旦出問题，前面的優化都會被抵消。把這條鏈路纳入日常巡检，比事後追查要省事得多。