讨论蜘蛛抓取时，大家习惯盯着响應碼、頁面大小和抓取频次，這些都属于請求發出之後的环节。但在蜘蛛真正把 HTTP 請求發到你的服務器之前，還有几毫秒到几百毫秒的路要走：解析域名、建立 TCP 连接、完成 TLS 握手。這几步出問题，服務端日誌里往往连一條记錄都不會留下。
一次抓取在時間轴上的几個阶段
- DNS 解析：把域名換成 IP，可能要经過本地缓存、递归解析器、權威服務器。
- TCP 连接：三次握手，跨地域时往返時間會叠加。
- TLS 握手：證书校驗、密钥协商，通常需要一到两個往返。
- 發送請求並等待首字节：這部分才是服務端日誌能看到的開始。
- 传輸响應体：頁面越大、压缩越差，耗时越明顯。
抓取端對超时的判断通常從第一步就開始計时。也就是说，如果 DNS 或 TLS 阶段就慢，請求可能還没到你的應用层就已经被放弃了。
DNS 是最容易出問题的一环
域名解析的耗时和稳定性，直接影响蜘蛛能不能走到你的服務器。几個常见的坑：
- CNAME 鏈太長：一层套一层，每一层都要額外查询，解析時間被放大。
- 權威 DNS 响應慢或不稳定：解析器要重试，甚至拿到超时结果。
- 多條 A 记錄里有不可用 IP：轮询到坏 IP 时表現為连接超时，但問题不在服務器本身。
- 配了 AAAA 记錄却没有可用的 IPv6 服務：支持 IPv6 的抓取端會先尝试走這條路。
如果近期做過改 IP、換 CDN 或迁移机房，可以先把 TTL 調低，切換完成後再調回。TTL 设得過短會让解析請求變多，设得過長則切換时舊 IP 會被缓存較久，两者各有權衡。
TLS 握手與證书：失敗常常不留日誌
證书過期、證书鏈不完整、只支持老舊协议，這些問题的共同点是连接根本建立不起来。抓取端拿到的是握手失敗，而不是 404 或 500，所以服務端訪問日誌里看不到任何痕迹。
- 检查證书有效期與自動續期是否真的在执行。
- 確認中間證书已下發，而不是只發站点證书。
- 尽量支持 TLS 1.2 與 1.3，避免只留一種老协议。
- 使用 CDN 时，注意源站與邊缘节点两侧的證书都要有效。
排查抓取異常时，如果日誌里“什么都没有”，先別急着怀疑 robots.txt，先去测一下握手是否成功。
连接复用與 HTTP/2 带来的差异
抓取端通常不會為每個 URL 單獨建一條连接。開啟 keep-alive 和 HTTP/2 多路复用之後，同一個连接上可以连續請求多個 URL，握手成本被摊薄。反過来，如果服務器频繁主動断開连接，或者把並發连接數压得很低，抓取效率會明顯下降。
需要注意的是，复用是按连接来算的。同一 IP 上的多個站点如果共用一個连接池，某個站点响應特別慢，也可能拖累同连接上的其他請求。
怎么观测這几段耗时
- 用 dig 或類似工具反复查询，看解析耗时和返回的 IP 是否稳定。
- 用 curl -w 打印各阶段耗时，例如 DNS、连接、TLS、首字节。
- 用 openssl s_client 检查證书鏈和协商到的协议版本。
- 在 Web 服務器日誌中区分請求總耗时與應用處理耗时，判断慢在哪一段。
- 從不同網絡位置測試，避免只從本地看到“一切正常”。
這些調整能改變什么，不能改變什么
把 DNS、TLS 和连接這几层做稳，能减少连接失敗、超时與重试，让抓取過程更顺畅，也让服務端日誌更干净、更容易分析。它属于基础设施层面的工作，不會直接决定某個 URL 是否被收錄，更不涉及排名。真正影响收錄的，仍然是内容本身、站点结构是否清晰，以及站点能否長期稳定訪問。
如果近期观察到蜘蛛来訪量下降，而日誌里又找不到對應的失敗請求，不妨先從這几毫秒開始查起。