抓取不止是一个 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、换证书前后各做一次，避免因为一次配置变更让抓取悄悄掉下来。