抓取不止是一個 GET 請求
排查抓取問题时，很多人习惯先看服務器日誌里的狀態碼。但狀態碼只能說明請求到達之後發生了什么。蜘蛛在發出請求之前，還要先完成域名解析、建立连接、完成 TLS 握手。這几步平时很快，一旦出問题，日誌里可能连一條记錄都没有，表現只是蜘蛛来得少，或者某些 URL 一直不抓。
一次抓取請求的先後顺序
把一次抓取拆開，大致是下面几段：
- DNS 解析：把域名換成 IP 地址，可能還要走 CNAME 鏈。
- TCP 连接：和 IP 的 80 或 443 端口建立连接。
- TLS 握手：HTTPS 站点需要协商协议版本、校驗證书。
- 發送 HTTP 請求並等待响應：這一步才會在日誌里留下狀態碼。
前面的环节越慢，能用在真正抓取上的時間就越少。對蜘蛛来说，抓取是有节奏的，一次請求拖太久，往往會减少對同一站点的訪問次數。
DNS 解析：容易忽略的第一道门
域名解析是所有抓取的起点，但它经常被当成基础设施的問题，不在日常检查范围内。實际排查时，可以關注這几項：
- 检查是否配置了 A 與 AAAA 记錄，两者是否都指向可用的地址。
- 查看 CNAME 鏈有多長，鏈路過長會增加解析時間。
- 注意 TTL 設定，改解析後多久生效會影响蜘蛛看到的新地址。
- 用 dig 或 nslookup 多次查询，观察解析耗时是否稳定。
如果權威 DNS 响應慢或者偶尔失敗，蜘蛛可能拿到解析失敗的结果，這次抓取就結束了。定期從外部網絡查询自己的域名，比只看本机缓存更接近真實情况。
TLS 握手：證书問题會直接拦下蜘蛛
HTTPS 站点常见的問题包括證书鏈不完整、證书過期、只支持較舊的 TLS 版本、SNI 配置不正确。這些情况在浏览器里可能被容错處理，但蜘蛛不一定有同样的容忍度。
- 證书鏈是否完整，中間證书有没有漏配。
- 證书覆盖的域名是否包括實际訪問的域名和 www 版本。
- 服務器支持的 TLS 版本與加密套件是否過舊。
- 是否存在證书與域名不匹配的情况。
可以用 openssl s_client -connect 域名:443 -servername 域名 查看握手過程和證书鏈。如果握手阶段就失敗，後面所有抓取優化都無從谈起。
连接复用與 HTTP/2：蜘蛛也會省连接
蜘蛛抓取同一站点时，通常會复用已有连接，而不是每個 URL 都重新握手。支持 HTTP/2 的服務器可以在一個连接上並行處理多個請求，這對抓取效率有帮助。反過来，如果服務器频繁断開连接、强制每個請求都重新握手，整体抓取节奏會變慢。
CDN 和反向代理在這里也起作用。邊缘节点是否支持長连接、回源是否稳定、回源超时設定是否合理，都會影响蜘蛛拿到的响應時間。如果回源经常超时，邊缘节点返回 5xx，蜘蛛看到的就是抓取失敗。
IPv6 與双栈：別让 AAAA 记錄成為障碍
如果域名同时有 A 和 AAAA 记錄，蜘蛛可能優先尝试 IPv6。如果 IPv6 地址不可達或响應很慢，抓取會先失敗一次再回退，無形中增加了延迟。可以分別測試只有 IPv4 和 IPv6 时的訪問情况，確認两條路都通畅。
排查顺序建议
- 先確認域名解析是否稳定，A 與 AAAA 记錄是否都可用。
- 用 curl -w 观察各阶段耗时，包括 DNS、连接、TLS 和首字节時間。
- 检查證书鏈、有效期和协议版本，確認 HTTPS 握手没有問题。
- 查看服務器和 CDN 日誌，区分是连接阶段失敗還是响應阶段失敗。
- 確認连接复用與回源配置，避免每個請求都重新建立连接。
抓取失敗不一定是内容或内鏈的問题，有时候只是蜘蛛没能顺利走到你的服務器门口。把網絡环节也纳入排查，才能看清問题出在哪一段。
網絡层的检查通常是一次性的：解析稳定、證书正确、连接可用之後，就可以把注意力放回内鏈、Sitemap 和内容更新上。但它值得在改版、換 CDN、換證书前後各做一次，避免因為一次配置變更让抓取悄悄掉下来。