很多站点排查抓取問题，习惯先看蜘蛛来了几次，却忽略了每次請求本身是否顺利。對搜尋蜘蛛来说，一次抓取耗时太長，和直接返回错誤在结果上差別不大：URL 没被抓完，連結没被解析，下一轮還可能被降频。理解超时與重试的机制，比單纯催抓取更有用。
一、一次抓取請求里，時間花在哪
蜘蛛發起一次請求，大致會经歷 DNS 解析、建立连接、TLS 握手、發送請求、等待首字节（TTFB）、下载内容、解析 HTML 與提取連結。前面几步通常只占几十毫秒，真正的差异往往出現在等待响應和下载阶段。如果 TTFB 長期在一秒以上，蜘蛛在單位時間内能抓的頁面數就會明顯下降。
二、超时不是單一數字
爬虫一般會設定多层時間预算：连接超时、响應超时、整体請求超时，有的還會限制單次下载体积。任何一层触發，這次抓取就算失敗。
- 连接层超时：DNS 解析慢、防火墙丢包、IP 不可達，通常發生在網絡或机房层面。
- 响應层超时：請求已到達服務器，但後端迟迟不返回，常见于資料库慢查询、接口串行調用。
- 下载层中断：响應头已返回，但内容传輸中途断掉，蜘蛛拿到的是不完整 HTML，連結自然提不全。
三、超时之後，蜘蛛會做什么
失敗不等于立刻放弃。多數情况下蜘蛛會安排重试，但重试是有代價的：同一個 URL 反复失敗，會消耗本该分给其他頁面的抓取額度。
如果某段時間内某類 URL 的失敗率明顯上升，蜘蛛更常见的反應不是加大力度，而是降低整体抓取频率，等站点稳定後再恢复。恢复通常是渐進的，很难在一两天内回到原来的节奏。
四、把超时變成可观测的資料
光有訪問日誌里的狀態碼不够，因為超时往往表現為客戶端主動断開，服務端可能只留下一行没有明确结果的记錄。建议至少补充几類信息：
- 請求耗时，按 URL 分组統計 P50、P95、P99，而不是只看平均值；
- 是否發生重试，以及重试間隔有多長；
- 响應体积分布，找出異常大的頁面；
- 同时段的並發數，判断是單頁慢還是整体被压垮。
把這些資料和抓取日誌按 URL 對齐，才能判断蜘蛛不来是發現渠道的問题，還是来了但每次都失敗。
五、拖慢响應的常见原因
- 列表頁一次性查询過多資料，缺少分頁或缓存；
- 頁面依赖多個上游接口，只能串行等待；
- 未命中缓存的動態渲染，每次都重新生成 HTML；
- 同一台服務器同时承担抓取流量和用戶流量，缺少隔离；
- 带宽或出口受限，内容传輸被拖慢。
六、可以落地的几件事
- 把响應時間目标定在可测量的范围内，例如核心頁面 P95 控制在几百毫秒級，並持續观察，而不是只做一次性優化。
- 给抓取流量做缓存或静態化，减少對資料库的直接压力。
- 對大頁面做拆分，避免單次传輸時間過長導致中断。
- 在服務器层面對異常高的並發做限速，避免蜘蛛瞬間放大請求把站点打满。
- Sitemap 與内鏈保持稳定可達，让蜘蛛在恢复抓取时不必重新摸索路径。
抓取問题的排查顺序，通常是先確認能不能稳定拿到完整 HTML，再谈 URL 發現和内鏈结构。响應超时看似只是性能問题，實际上它直接决定了蜘蛛愿不愿意繼續沿着你设計的路径往下走。