入口页能不能被顺利抓取，很多时候不取决于链接写得好不好，而取决于服务器在蜘蛛敲门的那几秒有没有及时应答。响应超时是蜘蛛池运营里最容易被忽略、也最难靠多挂几个域名绕过去的环节。
超时在蜘蛛眼里是一次失败的抓取
爬虫发起请求后会等待服务器返回响应。如果在设定的时间内没有拿到完整结果，这次抓取通常会被判定为失败或中断。它和返回 5xx 的效果接近：蜘蛛没有拿到链接，也没有拿到内容，但这次抓取已经消耗掉了。
公开文档里提到的等待上限一般在几十秒量级，不同搜索引擎、不同抓取类型并不一致。这个数字只适合当作底线参考，不适合当作目标。蜘蛛的抓取频率是动态调整的，长期贴着上限跑的响应速度，会让它降低对整站的抓取热情。
慢在哪里：把一次请求拆开看
- DNS 解析：解析慢或解析结果不稳定，请求还没到服务器就已经耗掉一部分时间。
- TLS 握手：证书链不完整、不支持会话复用，会多出一到两次往返。
- 首字节时间（TTFB）：后端查询、同步调用外部接口、数据库慢查询通常都堆在这里。
- 传输与页面体积：体积过大的 HTML 或阻塞渲染的外链脚本，会拉长整体耗时。
很多入口页把耗时花在看不见的地方：每次请求都同步拉一次统计脚本、RSS 或第三方 API，这些调用一抖动，整页就跟着卡住。
频繁超时之后会发生什么
单次超时影响有限，持续的慢响应会叠加成几个后果：
- 抓取预算被消耗在无效请求上，真正需要发现的 URL 被推后处理。
- 爬虫的并发与频率被自动调低，而恢复往往比下降慢得多。
- 超时与 5xx 混在一起时，容易被判读成服务器故障，进而影响对整批域名的信任。
- 入口页的价值被低估——链接明明挂着，却长期查不到抓取记录。
不要把蜘蛛还会再来当成兜底策略。超时是复利式的损耗，一次两次看不出问题，长期就会体现在 URL 的发现速度上。
怎么排查
看平均值意义不大，重点看高分位数。
- 读取访问日志中的请求耗时字段（如 $request_time 与 upstream_response_time），按入口页、按时段分组，观察 p95 与 p99。
- 用 curl 的耗时分解参数，把 DNS、连接、TLS、首字节、总时长分开看，定位瓶颈落在哪一段。
- 把蜘蛛 UA 的请求单独筛出来，确认变慢的是否恰好集中在爬虫高发时段。
- 检查是否有限流、WAF 或防爬中间件在特定条件下延迟了响应。
可以做的优化
- 入口页尽量静态化或走缓存，避免每次请求都回源到动态逻辑。
- 把统计、推荐、外部 API 等非必要调用改成异步或延迟加载，不要阻塞主响应。
- 开启 HTTP keep-alive 与会话复用，减少重复握手开销。
- DNS 交给稳定的解析服务，TTL 不要设得过短。
- 给入口页设置独立的监控阈值，把响应时间和可用性放在同一级别看待。
入口页是蜘蛛进入目标页的必经通道，它的响应速度实际上决定了整条抓取路径是否通畅。与其反复增加入口页数量，不如先把已有的入口页做得稳定、快速、可预期。