抓取量下滑的时候，很多人的第一反应是“蜘蛛不来了”。但实际排查下来，更常见的情况是蜘蛛照常来访，只是每次都没能把页面完整拿走。这两种情况在抓取报表里看不出区别，在服务器日志里却写得很清楚。
把日志里的失败分成几类
服务器日志能记录的信息有限，但只要抓住时间、请求行、状态码、响应时间和返回字节数这几列，大部分问题都能定位。下面这几类失败出现频率最高。
连接超时与响应超时
蜘蛛发起了请求，服务器迟迟没有回应，最终连接被中断。日志里可能留下一个极长的响应时间，也可能什么都没记下来。这类情况通常指向服务器负载、后端接口阻塞或者数据库慢查询，而不是页面本身的问题。
值得注意的是，超时是有成本的。蜘蛛在一个地址上等待越久，单位时间内能抓的页面就越少。哪怕只影响一部分 URL，整体抓取节奏也会被拖慢。
连接被重置或提前断开
日志里能看到请求进来了，但响应没有写完。可能是应用进程被重启、连接池耗尽、反向代理超时，也可能是页面体积太大导致传输中断。这类失败不像 5xx 那样直白，容易被忽略。
5xx 与 4xx 的含义不同
- 5xx 表示服务器这一侧出了问题，蜘蛛通常会稍后重试，短期不必惊慌，但持续出现就要查。
- 4xx 中的 404 是内容层面的结果；403、401 则往往是权限或防护规则挡住了。本该公开的页面返回 403，需要检查 WAF、CDN 或防盗链配置。
- 429 属于主动限速，说明限速策略生效了，但也要确认阈值没有卡得太紧。
状态码正常但内容异常
状态码是 200，返回内容却只有几百字节，或者比正常页面小很多，这通常意味着返回的是错误页、空模板或者被拦截后的提示页。这类“假成功”不会进 5xx 统计，需要单独筛出来看。
DNS 与 TLS 握手失败
请求根本没到应用层，日志里自然什么都没有。这类情况要从解析记录、证书有效期、协议版本入手。证书过期或者配置了蜘蛛不支持的加密套件，表现就是抓取突然中断，而服务器日志一切正常。
按什么顺序排查
- 先看日志里蜘蛛的请求量有没有明显变化，确认是“没来”还是“来了但失败”。
- 按状态码分组统计，找出占比最高的那一类。
- 再按 URL 分组，看失败是集中在某个目录、某类模板，还是全站随机分布。
- 对照服务器监控，看失败时间点是否和负载高峰、发布、重启重合。
- 最后用命令行工具模拟一次请求，对比响应头和耗时是否与日志一致。
排查时尽量按时间线比对：蜘蛛的失败记录、服务器监控曲线、发布记录，三者对齐之后往往一眼就能看出因果。
几件平时就该做的事
- 给抓取留出余量，不要让服务器在高峰期接近满载。
- 页面响应时间设一条内部告警线，超过就查，而不是等抓取量掉下来才回头看。
- 证书、解析记录这类到期型资源，提前安排续期提醒。
- 体积过大的页面适当拆分，减少单次传输中断的概率。
抓取失败大多不是单一原因，而是几个小问题叠加在一起。把日志里能看到的失败类型分开统计，比盯着一个总量数字要有用得多。