平时看抓取日志，注意力容易被状态码吸引：404 多了、500 多了，一眼就能看见。但真正让 URL 迟迟不被抓取的，往往是那些没有留下完整状态码的请求——连接建好又断了，响应头回来了正文没回来，握手阶段就超时了。这些记录看起来含糊，却直接决定了这次抓取算不算数。
一次抓取请求要走过几段路
把一次抓取拆开，大致会经过：DNS 解析、TCP 建连、TLS 握手（HTTPS）、发送请求、等待响应头、接收响应体、连接复用或关闭。任何一段出问题，结果都可能不是干净的 200 或 5xx，而是日志里一行难以归类的记录。
三类常见的“没抓完”
1. 连接被重置
日志里表现为请求刚发出就中断，或者连接建立后被立即切断。常见原因包括：服务器或中间设备主动断开空闲连接、并发数触发了防护策略、后端进程崩溃重启、长连接被中间层静默关闭。这类失败通常不会带状态码，或只留下一个极短的访问时间。
2. 响应传到一半断掉
响应头正常返回，甚至状态码是 200，但正文没有传完。此时蜘蛛拿到的是残缺内容：可能缺正文、可能 HTML 结构不闭合、可能链接列表只解析出一部分。对 URL 发现来说，这比直接失败更麻烦，因为部分链接会凭空消失，而站点侧却以为这一页已经被抓过了。
3. 握手与首字节慢
TLS 握手超时、首字节迟迟不到，通常出现在服务器负载高、回源链路长、证书链配置异常的场景。蜘蛛有等待上限，超过就放弃，并把这次记录为超时。偶发一次影响不大，但如果某个目录长期如此，抓取频率会明显降低。
抓取失败分两种：一种是明确告诉蜘蛛“不行”，另一种是让蜘蛛在等待中耗尽耐心。后者更难排查，也更伤 URL 发现。
蜘蛛遇到失败之后会怎么做
- 重试：对连接类失败，通常会在后续排期里再试，但重试次数和间隔不公开，且会受整体抓取压力影响。
- 退避：如果同一主机反复失败，抓取节奏会放缓，表现为该目录的抓取量整体下降，而不是某一页反复重试。
- 减少复用：连接不稳定时，蜘蛛可能更倾向于重新建连，这反过来又增加服务器负担，形成循环。
需要说明的是，这些行为都是推测性描述，不同搜索引擎、不同时间点的策略并不一致，不必按固定规律去推算。
服务器端优先排查什么
- 看抓取日志里的“短请求”：响应时间极短又没状态码的记录，往往就是被重置的那批，按 IP 段和路径聚一下，看是否集中在某个目录或某台后端。
- 检查超时配置是否过短：应用层、反向代理、负载均衡各有超时，任何一层比上游短，都可能造成半截响应。
- 确认长连接与并发策略：连接复用被中间设备提前关闭，是连接重置的常见来源，需要跟运维确认空闲超时和并发上限。
- 观察发布与重启窗口：每次都伴随抓取失败小高峰的时间点，通常对应部署、重启或缓存刷新。
- 对比正常与异常路径的耗时：同一个站点里，某些栏目页明显慢于其他页面，说明瓶颈在数据或模板层，不在网络层。
别把失败当成“蜘蛛不来了”
抓取量下降时，容易先怀疑内容质量或权重变化，但如果日志里连接类失败在同步上升，那更像是通道问题。建议把“抓取成功”单独定义成一次完整拿到响应体，而不是只要有一条访问记录就算数。按这个口径统计，往往会发现真实抓取量比想象中低。
站点运营上能做的，是让每一次抓取都尽量完整：稳定的后端、合理的超时、不随意打断的长连接，再加上对失败记录的定期查看。蜘蛛会不会来、来多少，无法保证；但把请求完整送出去，是站点自己可以控制的那部分。