蜘蛛抓取一个 URL 的时间可以粗略拆成三段：建立连接、等待首字节（TTFB）、读取响应体。其中 TTFB 是最容易被忽略、又最容易悄悄变长的一段。它不像 5xx 那样显眼，但当 TTFB 从 200ms 涨到 3s，抓取端感受到的就是队列等待变长、单次抓取窗口内能完成的 URL 变少、新入口的发现被整体推迟。下面这套顺序用于处理“抓取量没怎么掉，但入口推进明显变慢”的情况。
先分清是排队问题还是响应问题
抓取变慢有两类来源：一类是站点响应本身变慢，另一类是抓取端主动降速。两者的处理方向完全不同，所以要先用日志区分。看同一时间段的请求耗时分布，如果大部分请求的等待时间都长于平常，且服务器 CPU、内存没有打满，多半是响应侧的问题；如果只是抓取频次下降、单次响应仍然很快，则更可能是抓取速率被下调，需要回头核对站点稳定性记录。
排查顺序建议
- 固定测量口径。选两三个有代表性的 URL（首页、列表页、详情页），在固定地域、固定工具下重复测量。不要拿昨天的平均值和今天的高峰数据对比，那只会得出错误结论。
- 把网络段和源站段分开。用带计时输出的请求工具分别记录连接时间、首字节时间、总耗时。若连接时间正常而首字节时间很长，基本可以排除线路问题，把精力放回应用本身。
- 确认是全局慢还是某类页面慢。静态资源、纯静态页面如果很快，只有带查询或带登录态的页面慢，说明瓶颈在动态处理逻辑，而不在带宽或网络。
- 看缓存命中与回源比例。回源率上升往往和 TTFB 上升同时出现。检查缓存规则是否被改动、缓存键是否因为参数或 Cookie 变得过于分散，导致原本可命中的请求全部落到源站。
- 看慢查询和外部依赖。数据库慢查询、缓存连接超时、第三方接口同步调用、写日志阻塞，都是常见的隐性耗时来源。逐个用耗时日志确认，而不是凭感觉猜。
- 看并发与超时配置。如果上游超时时间设得比下游更长，慢请求会一直占着连接，后续请求排队等待，表现为整体 TTFB 抬升。检查连接池大小、超时值和并发上限是否相互匹配。
- 最后再回看抓取速率设置。抓取速率本身通常不是变慢的原因，但如果站点容量本身吃紧，过高的请求压力会反过来放大响应耗时，这时应从服务器容量入手，而不是长期压制抓取。
几个常见误判
- 把响应慢直接当成“蜘蛛不来”，于是反复提交 Sitemap，实际问题仍在源站。
- 只测首页。首页往往有独立缓存，无法代表列表页和详情页的真实耗时。
- 只看平均耗时。平均值会把长尾掩盖掉，而抓取端对长尾尤其敏感，建议同时看分位值。
- 遇到慢就加带宽。若瓶颈在数据库或同步调用，加带宽基本无效。
判断标准可以简化成一句：如果同一批 URL 的“等待首字节”时间整体上移，而连接建立时间没变，就应优先排查源站处理链路，而不是抓取策略。
落地检查清单
- 建立固定的耗时观测点，覆盖首页、列表页、详情页三类模板。
- 记录缓存命中率与回源率的变化，和 TTFB 曲线放在一起看。
- 为慢查询和外部调用设置耗时阈值告警，而不是只在出错时才关注。
- 核对连接池、超时值与并发上限，避免慢请求堆积成排队。
- 变更上线后复测同一批 URL，确认耗时回落到正常区间。
TTFB 属于那种“不报警但持续扣分”的指标。把它纳入日常巡检，比在抓取量下滑之后再回头翻日志要省力得多。