很多时候，蜘蛛“没来抓”并不是它不想来，而是来了、连上了、然后在中途被拖到放弃。抓取日志里留给你的信息通常只有一行：状态码缺失、耗时很长、或者干脆记成一个超时。想把问题解决掉，得先知道这段时间到底花在了哪一段上。
一次抓取由几段时间拼成
从蜘蛛的角度看，访问一个 URL 并不是一个动作，而是一串按顺序发生的步骤，每一步都可能成为瓶颈：
- DNS 解析：把域名换成 IP，解析服务不稳定或 TTL 太短，这一步就会反复消耗时间。
- 建立连接：TCP 三次握手，网络绕路、防护设备丢包都会让这一步变慢。
- TLS 握手：证书链过长、协议版本老旧、会话复用没开，都会多出几个来回。
- 等待首字节（TTFB）：服务器真正处理请求的时间，通常是最容易失控的一段。
- 传输正文：从第一个字节到最后一个字节，页面体积、压缩开关、连接是否复用都在这里起作用。
这五段加起来，才是蜘蛛感受到的“这个页面快不快”。只看总耗时，几乎没法判断该改哪里。
超时不是一个数值，而是几道关卡
连接超时
请求还没送到你的应用层，蜘蛛就在等待握手或等首字节时放弃了。表现通常是日志里没有状态码，或者只有一条连接失败的记录。这类问题多在网络链路、防火墙、CDN 回源这一段。
读取超时
连接已经建立，服务器也开始返回数据，但中间停顿太久，或者正文迟迟传不完。这种情况往往能在日志里看到一个状态码，同时耗时明显高于同站其它页面。它指向的是应用处理慢、数据库慢、或者响应体太大。
抓取日志中的“超时”只说明结果，不说明原因。同一条记录背后可能是 DNS 问题，也可能是某个慢查询，处理方向完全不同。
哪些情况会被记成抓取失败
- 返回 5xx：应用出错、上游超时、后端服务被重启。
- 连接被重置：防护策略、并发限制、或协议层不匹配。
- 429 或类似的限速响应：抓取频率触发了阈值。
- 空响应或截断的正文：传输中途断开，蜘蛛拿到一个不完整的页面。
- 4xx：严格说不是超时，但大量 404、403 同样会让蜘蛛在这条路径上白跑。
建议把这几种分开统计，而不是笼统算作“抓取异常”。分开之后，往往一眼就能看出是集中在某个目录、某个子域，还是全站普遍。
自查：把时间花在哪一段量出来
- 先从抓取日志里筛出耗时明显偏高的 URL，按目录归类，看是否有规律。
- 用命令行工具对同一批 URL 做多次请求，输出各阶段耗时，而不是只看总时间。
- 连续采样若干次，关注最慢的那几次，而不是平均值。蜘蛛撞上的往往就是最慢的那次。
- 分别对比：带缓存与不带缓存、静态页与动态页、首页与深层页。
- 如果耗时集中在首字节，往应用和数据库方向查；如果集中在传输，往体积、压缩和连接复用方向查。
- 换一台不同网络的机器再测一次，确认问题在服务端还是链路侧。
常见的拖慢点与处理方向
- 页面依赖未缓存的复杂查询，建议给高频被抓取的模板页加缓存层。
- 正文未压缩或压缩未生效，检查压缩是否覆盖了蜘蛛常抓的内容类型。
- 渲染依赖外部脚本，脚本超时导致整页等待，建议关键内容先服务端输出。
- CDN 回源超时设置短于源站正常响应时间，造成周期性失败。
- 连接复用未开启，每个请求都重新握手，累积起来很可观。
不需要一次把所有点都改完。先确定耗时集中在哪一段，再动那一段的配置，改完用同样的方式复测，看耗时曲线有没有变化。稳定而可预期的响应时间，比偶尔很快、偶尔超时要更有价值。