蜘蛛抓取一个 URL，本质上是一次普通的 HTTP 请求：建立连接、发送请求、等待响应、接收内容。它和你用浏览器打开页面的区别在于，它没有耐心，也不会因为页面“看起来快好了”就多等一会儿。超过自己设定的阈值，它会断开、记一笔，然后转身去抓别的地址。所以服务器响应的快慢，直接决定了蜘蛛一次访问能带回多少东西。
超时可能发生在哪几个阶段
很多人把“抓取超时”理解成一个笼统的概念，其实它至少分布在五个环节：
- DNS 解析：域名解析慢或解析结果不稳定，连接还没开始就卡住了。
- TCP 连接：连接队列满、防火墙丢包，握手要反复重试。
- TLS 握手：证书链不完整、协议版本过旧、跳转过多，都会额外增加往返次数。
- 首字节时间（TTFB）：请求已经发出，后端还在算，这是最常见的一段。
- 内容传输：首字节很快，但 HTML 主体几十上百 KB 且带宽被占满，读完仍然超时。
这几段的排查方式完全不同。只看“抓取失败”这一个数字，很容易把后端慢当成带宽问题，或者反过来。
为什么首字节时间最值得盯
TTFB 是后端真正处理请求所用的时间。它包含路由匹配、数据库查询、模板渲染，以及任何同步调用的外部接口。一个页面如果 TTFB 长期在 1 秒以上，蜘蛛每次访问都要付出更高成本；在抓取额度固定的情况下，它能跑的 URL 数量就会下降。
更麻烦的是，TTFB 往往是“波动”的，而不是稳定地慢。平均值看起来还行，但高峰期偶尔飙到几秒，蜘蛛遇到的恰恰是这些坏样本。
对蜘蛛来说，一个页面的成本不只是字节数，还包括等待时间。等得越久，它能覆盖的 URL 越少。
慢页面在日志里通常长什么样
- 同一批 URL 的抓取间隔逐渐拉长，从每天一次变成几天一次。
- 响应码里出现较多 5xx，或者请求被中断、没有留下完整状态码。
- 蜘蛛只抓列表页和少数入口页，深层页面几乎不再出现。
- 抓取集中在低峰时段，和你自己的访问高峰错开。
这些现象不一定意味着惩罚，更常见的解释是资源层面的自然结果：慢和失败让它把机会挪到了别处。
常见拖慢首字节的原因
1. 未缓存的动态查询
列表页、搜索结果页、标签页每次请求都重新查库，且查询没走索引。这类页面往往还是内链最密集的地方，一旦变慢，影响面比想象中大。
2. 同步调用外部服务
页面上有评论、推荐、汇率、天气之类的第三方接口，且是同步渲染。第三方抖动一次，你的 TTFB 就跟着抖一次。
3. 所有请求走同一条通道
图片、附件、导出文件和大 HTML 挤在一起。一个几百 MB 的下载请求占满连接，后面的请求只能排队。
4. 服务器本身接近上限
CPU、内存、连接数或带宽长期在 80% 以上，说明没有余量。抓取高峰与用户高峰重叠时，双方都会变慢。
可以落地的处理方式
- 给关键路径设缓存：栏目页、文章页这类内容相对稳定，尽量走静态化或短周期缓存，把数据库压力让出来。
- 外部调用改成异步或超时降级：给第三方请求设一个很短的超时，取不到就渲染占位内容，不要拖住整个页面。
- 分开资源通道：静态资源、大文件下载和 HTML 使用不同的服务或限速策略，避免互相挤占。
- 关注分位数而不是均值：看 95 分位和 99 分位的 TTFB，比看平均值更接近蜘蛛的真实体验。
- 控制页面体积：首字节再快，正文过大同样会让传输阶段超时，尤其在带宽较差的环境下。
和 URL 发现的关系
慢不只是“少抓几个页面”的问题。当你把重要 URL 放在一条又慢又深的路径上——比如要经过多层筛选、分页和跳转才能到达——蜘蛛可能在走到它之前，就已经用完了本轮的时间和请求数。把重要内容放在响应稳定的入口附近，比事后补救更有效。
Sitemap 能提供一份直接的 URL 清单，但它只解决“知道有哪些地址”；服务器能不能稳定、快速地回应，才决定这些地址会不会被真正抓完。