很多站长看抓取日志只关注状态码，但有一类抓取失败不会留下 200、404 或 5xx，而是请求开始后连接被中断，或者蜘蛛等待超时后自己离开。这类问题不解决，页面可能长期处于“抓过但没抓全”的状态。
先分清抓取失败的几种形态
- 响应超时：服务器在蜘蛛等待窗口内没有返回首字节或完整响应。
- 连接重置：TCP 连接被服务器、防火墙或中间设备强制断开。
- 传输中断：响应已经开始，但 body 没有传完。
- 连接被拒绝：并发已满、端口未监听或安全策略拦截。
这些情况在服务器日志里可能表现为 408、499、502 或 504，也可能只有一条没有响应码的请求记录。单看状态码分布，很容易漏掉它们。
服务器端能看到哪些线索
如果用的是 Nginx、Apache 或带访问日志的 CDN，可以重点看几个字段：请求总耗时、上游响应时间、发送字节数。若某个 URL 的发送字节数明显小于页面正常大小，说明传输中途断了；若日志里频繁出现 499，通常表示客户端在服务器响应前关闭了连接，蜘蛛超时离开时并不少见。
还可以看连接队列和并发数。服务器连接数打满时，新来的抓取请求可能连不上，或者排队到超时。此时日志里未必有对应 URL 的完整记录，但系统监控会显示连接数飙升。
常见的几个原因
后端处理太慢
动态查询、外部接口调用、同步写日志等操作，会把首字节时间拉长。蜘蛛的等待窗口有限，超过之后就会断开。给蜘蛛常抓的列表页和详情页加缓存、把非关键逻辑改成异步，通常比反复提交 URL 更有效。
keep-alive 与并发配置不匹配
连接复用本身是好事，但如果服务器、负载均衡或 CDN 的空闲超时不一致，连接可能在复用前被中间设备先关掉。蜘蛛再次使用这条连接时就会遇到重置。把各层的 keep-alive 和空闲超时调成一致，能减少这类偶发中断。
并发限制与安全策略
WAF 或防火墙可能把蜘蛛 IP 当成异常流量，触发限速、验证或直接拦截。合法蜘蛛的 UA 和 IP 可以做校验，但不建议整段封禁。CDN 回源超时、源站限速也需要单独确认。
响应体与传输方式
页面过大、未压缩、chunked 配置异常、gzip 与代理冲突，都可能导致传输中断。控制 HTML 体积，确保压缩正常，避免在传输过程中插入额外脚本或重定向。
排查顺序
- 确认抓取方 IP 与 UA，排除误判。
- 用 curl 带蜘蛛 UA 请求同一 URL，观察连接、首字节和总耗时。
- 对比访问日志中该 URL 的请求耗时与发送字节数。
- 检查 WAF、CDN、负载均衡的超时与限速日志。
- 在低峰和高峰各测一次，确认是否与并发相关。
可以落地的调整
- 给蜘蛛常抓的页面加缓存，减少后端压力。
- 统一各层 keep-alive 与空闲超时，避免连接被中间设备先断。
- 给合法蜘蛛设置合理的并发上限，而不是完全放开或一律拦截。
- 确保 gzip、chunked 与代理配置兼容，响应体能完整传输。
- 在抓取高峰期避免跑全站生成、大报表等重任务。
服务器稳定的目标不是永远不波动，而是蜘蛛每次来都能在可接受时间内拿到完整、一致的响应。
抓取中断往往不是单一原因，先从日志里的耗时和传输字节数入手，再结合并发与安全策略排查，通常比盲目调整 robots.txt 或反复提交 Sitemap 更有效。调整后观察一段时间，看回访是否更完整，再决定下一步。