很多站点排查抓取问题，习惯先看蜘蛛来了几次，却忽略了每次请求本身是否顺利。对搜索蜘蛛来说，一次抓取耗时太长，和直接返回错误在结果上差别不大：URL 没被抓完，链接没被解析，下一轮还可能被降频。理解超时与重试的机制，比单纯催抓取更有用。
一、一次抓取请求里，时间花在哪
蜘蛛发起一次请求，大致会经历 DNS 解析、建立连接、TLS 握手、发送请求、等待首字节（TTFB）、下载内容、解析 HTML 与提取链接。前面几步通常只占几十毫秒，真正的差异往往出现在等待响应和下载阶段。如果 TTFB 长期在一秒以上，蜘蛛在单位时间内能抓的页面数就会明显下降。
二、超时不是单一数字
爬虫一般会设置多层时间预算：连接超时、响应超时、整体请求超时，有的还会限制单次下载体积。任何一层触发，这次抓取就算失败。
- 连接层超时：DNS 解析慢、防火墙丢包、IP 不可达，通常发生在网络或机房层面。
- 响应层超时：请求已到达服务器，但后端迟迟不返回，常见于数据库慢查询、接口串行调用。
- 下载层中断：响应头已返回，但内容传输中途断掉，蜘蛛拿到的是不完整 HTML，链接自然提不全。
三、超时之后，蜘蛛会做什么
失败不等于立刻放弃。多数情况下蜘蛛会安排重试，但重试是有代价的：同一个 URL 反复失败，会消耗本该分给其他页面的抓取额度。
如果某段时间内某类 URL 的失败率明显上升，蜘蛛更常见的反应不是加大力度，而是降低整体抓取频率，等站点稳定后再恢复。恢复通常是渐进的，很难在一两天内回到原来的节奏。
四、把超时变成可观测的数据
光有访问日志里的状态码不够，因为超时往往表现为客户端主动断开，服务端可能只留下一行没有明确结果的记录。建议至少补充几类信息：
- 请求耗时，按 URL 分组统计 P50、P95、P99，而不是只看平均值；
- 是否发生重试，以及重试间隔有多长；
- 响应体积分布，找出异常大的页面；
- 同时段的并发数，判断是单页慢还是整体被压垮。
把这些数据和抓取日志按 URL 对齐，才能判断蜘蛛不来是发现渠道的问题，还是来了但每次都失败。
五、拖慢响应的常见原因
- 列表页一次性查询过多数据，缺少分页或缓存；
- 页面依赖多个上游接口，只能串行等待；
- 未命中缓存的动态渲染，每次都重新生成 HTML；
- 同一台服务器同时承担抓取流量和用户流量，缺少隔离；
- 带宽或出口受限，内容传输被拖慢。
六、可以落地的几件事
- 把响应时间目标定在可测量的范围内，例如核心页面 P95 控制在几百毫秒级，并持续观察，而不是只做一次性优化。
- 给抓取流量做缓存或静态化，减少对数据库的直接压力。
- 对大页面做拆分，避免单次传输时间过长导致中断。
- 在服务器层面对异常高的并发做限速，避免蜘蛛瞬间放大请求把站点打满。
- Sitemap 与内链保持稳定可达，让蜘蛛在恢复抓取时不必重新摸索路径。
抓取问题的排查顺序，通常是先确认能不能稳定拿到完整 HTML，再谈 URL 发现和内链结构。响应超时看似只是性能问题，实际上它直接决定了蜘蛛愿不愿意继续沿着你设计的路径往下走。