蜘蛛来访的流程并不复杂：解析 DNS、建立连接、发出请求、等服务器返回第一个字节。前面几步通常在毫秒级完成，真正决定成败的是最后一步——服务器多久开始吐数据。如果这一步经常拖到几秒甚至超时，抓取就会中断，没抓到的地址下次是否还来，就不好说了。
先分清两个概念：响应时间与超时
响应时间常用的观察指标是 TTFB（首字节时间），它包含网络往返、服务器排队、程序处理、数据库查询等环节。超时则是客户端等不到结果就断开，蜘蛛通常有自己的等待上限，超过就记为失败并换下一个地址。
这两个指标经常互相掩盖：TTFB 平均看着还行，但少数页面要等十几秒，这些页面在日志里表现为超时或 5xx，数量不多，却集中在重要栏目上，影响就不小。所以看平均值之外，更要看慢请求的分布。
慢在哪：几种常见的响应拖沓来源
- 数据库慢查询：列表页、标签页在数据量大时没有走索引，一次查询扫全表。
- 模板里嵌套调用：一个页面里循环查多次数据库，或者调用多个内部接口。
- 外部接口同步等待：第三方接口变慢或挂掉，页面就跟着卡住。
- 缓存没有覆盖到：首页有缓存，栏目页和内页没有，蜘蛛偏偏抓的是后者。
- 后端连接数或进程数不足：并发一上来就排队，正常用户也跟着变慢。
- 大文件与附件直出：视频、压缩包和页面放在同一台机器上，带宽被占满。
把 5xx 和限流分清楚
服务器返回的错误码，蜘蛛的解读并不相同：
- 500 类：服务端出错了，属于异常，反复出现会影响对这个站点的判断。
- 503：暂时不可用，通常配合 Retry-After 说明多久之后再来，适合计划内维护。
- 429：请求太频繁，是限流信号，语义上比 5xx 温和，但也要控制触发频率。
- 200 加错误文案：最容易被忽略的一种，页面上写着"系统繁忙"，状态码却是 200，蜘蛛会当成正常内容收下。
维护期间，宁可返回明确的 503 加说明，也不要用 200 去糊一个错误页面。同时，限流尽量不要把蜘蛛和正常用户一起挡掉，可以对已验证的蜘蛛做适度放行，但这要结合自身日志来判断，别把放行开关交给请求头里随便写的名称。
给不同类型的内容做响应分层
- 静态页面和数据接口分开部署，至少不要争抢同一份连接资源。
- 对列表页、聚合页做结果缓存，缓存时间按更新频率设定，不必强求实时。
- 给耗时接口加超时上限和降级方案，接口超时就返回缺省内容，而不是让整个页面挂住。
- 把大文件迁到对象存储或独立域名，减轻主站带宽压力。
- 记录慢请求日志，把超过阈值的地址单独列出来，定期看一次。
一份可以照着做的巡检清单
- 用命令行工具抓几条典型地址，记录 TTFB、总耗时和状态码。
- 在蜘蛛日志里筛出超时和 5xx，按目录归并，看是否集中在某几个栏目。
- 检查数据库慢查询记录，确认列表页、搜索页是否存在全表扫描。
- 核对缓存命中率，重点看栏目页和内页。
- 确认维护页面返回的是 503 而不是 200。
- 观察带宽峰值时段，看是否与蜘蛛抓取高峰重合。
响应速度是抓取的基础条件，不是加分项。站点内容再好，如果服务器经常让蜘蛛等太久，后面的工作都会打折。
把响应时间、错误码和限流策略整理成一份可复查的记录，比偶尔手动测一次更有意义。长期看，稳定的响应表现会让抓取更顺畅，也让日常运维少一些临时的电话。