蜘蛛抓取一個 URL 的時間可以粗略拆成三段：建立连接、等待首字节（TTFB）、讀取响應体。其中 TTFB 是最容易被忽略、又最容易悄悄變長的一段。它不像 5xx 那样顯眼，但当 TTFB 從 200ms 涨到 3s，抓取端感受到的就是队列等待變長、單次抓取窗口内能完成的 URL 變少、新入口的發現被整体推迟。下面這套顺序用于處理“抓取量没怎么掉，但入口推進明顯變慢”的情况。
先分清是排队問题還是响應問题
抓取變慢有两類来源：一類是站点响應本身變慢，另一類是抓取端主動降速。两者的處理方向完全不同，所以要先用日誌区分。看同一時間段的請求耗时分布，如果大部分請求的等待時間都長于平常，且服務器 CPU、内存没有打满，多半是响應侧的問题；如果只是抓取频次下降、單次响應仍然很快，則更可能是抓取速率被下調，需要回头核對站点稳定性记錄。
排查顺序建议
- 固定测量口径。選两三個有代表性的 URL（首頁、列表頁、詳情頁），在固定地域、固定工具下重复测量。不要拿昨天的平均值和今天的高峰資料對比，那只會得出错誤结论。
- 把網絡段和源站段分開。用带計时輸出的請求工具分別记錄连接時間、首字节時間、總耗时。若连接時間正常而首字节時間很長，基本可以排除线路問题，把精力放回應用本身。
- 確認是全局慢還是某類頁面慢。静態资源、纯静態頁面如果很快，只有带查询或带登入態的頁面慢，說明瓶颈在動態處理逻辑，而不在带宽或網絡。
- 看缓存命中與回源比例。回源率上升往往和 TTFB 上升同时出現。检查缓存規則是否被改動、缓存键是否因為參數或 Cookie 變得過于分散，導致原本可命中的請求全部落到源站。
- 看慢查询和外部依赖。資料库慢查询、缓存连接超时、第三方接口同步調用、寫日誌阻塞，都是常见的隐性耗时来源。逐個用耗时日誌確認，而不是凭感觉猜。
- 看並發與超时配置。如果上游超时時間设得比下游更長，慢請求會一直占着连接，後續請求排队等待，表現為整体 TTFB 抬升。检查连接池大小、超时值和並發上限是否相互匹配。
- 最後再回看抓取速率設定。抓取速率本身通常不是變慢的原因，但如果站点容量本身吃紧，過高的請求压力會反過来放大响應耗时，這时應從服務器容量入手，而不是長期压制抓取。
几個常见誤判
- 把响應慢直接当成“蜘蛛不来”，于是反复提交 Sitemap，實际問题仍在源站。
- 只测首頁。首頁往往有獨立缓存，無法代表列表頁和詳情頁的真實耗时。
- 只看平均耗时。平均值會把長尾掩盖掉，而抓取端對長尾尤其敏感，建议同时看分位值。
- 遇到慢就加带宽。若瓶颈在資料库或同步調用，加带宽基本無效。
判断标准可以简化成一句：如果同一批 URL 的“等待首字节”時間整体上移，而连接建立時間没變，就應優先排查源站處理鏈路，而不是抓取策略。
落地检查清單
- 建立固定的耗时观测点，覆盖首頁、列表頁、詳情頁三類模板。
- 记錄缓存命中率與回源率的變化，和 TTFB 曲线放在一起看。
- 為慢查询和外部調用設定耗时阈值告警，而不是只在出错时才關注。
- 核對连接池、超时值與並發上限，避免慢請求堆积成排队。
- 變更上线後复测同一批 URL，確認耗时回落到正常区間。
TTFB 属于那種“不报警但持續扣分”的指标。把它纳入日常巡检，比在抓取量下滑之後再回头翻日誌要省力得多。