为什么状态码正常，抓取量还是会掉
排查抓取问题时，很多人只盯状态码：200 就认为没问题，5xx 才去查服务器。但蜘蛛在拿到状态码之前，还要先完成 DNS 解析、建立 TCP 连接、完成 TLS 握手。这几步任何一环抖动，日志里可能什么都不显示，站长的感受却是「蜘蛛来得少了」。把抓取稳定性当成一条完整链路来看，比单看某一层更容易找到原因。
DNS：最先被忽略的一环
DNS 解析是所有抓取的起点。蜘蛛需要先解析域名，才能发起连接。常见问题包括：
- 权威 DNS 响应慢或不稳定：解析超时后，这次请求就结束了，不会留下任何 HTTP 状态码。
- 解析结果不一致：多地节点返回不同 IP，其中某个 IP 不可用，抓取就会时好时坏。
- TTL 设置过短：频繁回源解析，放大了 DNS 层的抖动。
- CNAME 链条过长：多级跳转让解析时间成倍增加，使用多个第三方服务时尤其明显。
建议固定几个时间点，用不同地区的解析工具测一下解析耗时和返回结果，确认没有明显差异。
TLS 握手与证书的细节
HTTPS 站点在解析之后还要完成 TLS 握手。证书过期、证书链不完整、不支持蜘蛛常用的 TLS 版本、SNI 配置缺失，都会让连接直接失败。这类失败通常不会出现在服务器访问日志里，排查时容易漏掉。
可以做几件事：确认证书链完整（中间证书别缺），检查到期时间并设置提醒，确认 HTTP 与 HTTPS 都能正常返回内容，跳转层级尽量控制在两级以内。跳转本身不是问题，但连续多次跳转叠加握手开销，会明显拖慢每次抓取。
连接复用与 HTTP/2 的影响
同一批抓取里，蜘蛛往往希望复用连接，减少重复握手。如果 keep-alive 时间设置得过短、单 IP 并发连接数限制得很严，或者 HTTP/2 配置异常，每次请求都要重新建连，单位时间能抓到的 URL 数量就会下降。表现出来像是「抓取频次变低」，实际原因却在连接层。
响应阶段：慢和坏要分开处理
连接建立之后才轮到响应，这里有两个不同的信号：
- 慢：首字节时间（TTFB）偏长，蜘蛛需要等待。偶尔慢通常问题不大，持续慢会让它降低对这个目录的访问频率。
- 坏：5xx、连接重置、超时中断。这类信号更明确，蜘蛛一般会记录失败，隔一段时间再试；如果连续失败，可能减少该目录的抓取量。
需要注意的是，慢页面和错误页面在日志里的呈现方式不同：慢通常表现为请求耗时长，坏则表现为状态码或连接中断。分开统计，才能判断是该加缓存还是该查程序。
一份简单的稳定性巡检清单
- 多地区测试 DNS 解析耗时，确认返回结果一致。
- 检查证书链是否完整、是否临近到期。
- 确认 HTTP 与 HTTPS 都能正常响应，跳转层级尽量少于两级。
- 查看访问日志中请求耗时的分布，找出慢 URL 集中出现的目录。
- 统计 5xx 与连接中断的比例，确认是否集中在某台机器或某个接口。
- 对比服务器日志与抓取工具里的抓取量变化，看波动是否与发布、压测、扩容的时间点吻合。
限流与故障要区别对待
429 和 503 有时是主动限流的信号，有时是真实过载。如果站点确实扛不住，用 robots.txt 的 crawl-delay 或服务端限流策略，比让蜘蛛不断撞上错误更稳妥。反过来，如果只是个别机器配置问题，优先修机器，而不是一刀切地限制全站。
抓取稳定性是一条从上到下的链路：解析、握手、连接、响应。哪一层出问题，表现都可能是「蜘蛛变少了」，但处理方式完全不同。先把链路分段观测，再决定改哪里。