蜘蛛来抓一个 URL，结果没抓成。这件事在日志里往往只留下一行状态码，或者干脆什么都没有。但失败的原因差别很大，蜘蛛后续的处理方式也不一样。搞清楚自己遇到的是哪一类失败，比笼统地说“蜘蛛不来了”更有用。
先分清：是没连上，还是连上了没拿全
- 连接阶段失败：DNS 解析不到、TCP 连不上、TLS 握手失败。这类失败蜘蛛连 HTTP 请求都没发出去。
- 请求阶段失败：连上了，请求也发出去了，但服务器返回 5xx、429，或者长时间不响应。
- 响应阶段失败：状态码看着正常，但响应体被截断、中途超时断开。
这三类的排查方向完全不同。第一种基本是域名解析、防火墙、证书的问题；第二种是服务器和应用的问题；第三种往往是网络链路或服务端输出被提前掐断。
DNS 与连接失败：蜘蛛根本没进门
如果日志里连一条记录都没有，先别急着怀疑蜘蛛偷懒，很可能是它压根没连上。常见原因包括：分线路解析把某些地区的解析结果指到了不可用的 IP；CDN 或 WAF 把蜘蛛的 IP 段拦在了前面；防火墙对陌生来源直接丢包，连 TCP 连接都建不起来。
排查时可以先用第三方工具从不同地区解析域名，确认返回的 IP 是否都在正常工作。如果用了 CDN，注意看回源是否稳定，以及是否有针对爬虫 UA 的拦截规则被误开。
证书与 TLS：一个很容易被忽略的坎
证书过期、证书链不完整、只支持过旧的 TLS 版本，都会让蜘蛛在握手阶段直接失败。浏览器有时会宽容处理，比如让你手动点“继续访问”，但蜘蛛不会。证书一旦出问题，整站抓取都可能停摆，而不是只影响一个页面。
这类问题的特点是“全站性”。如果某天抓取量突然掉到接近零，而服务器配置本身没动过，证书到期是很值得第一时间检查的项。
超时与首字节：慢到一定程度就等于失败
蜘蛛对每个请求都有自己的等待上限。服务器如果一直不返回首字节，蜘蛛会在超时后放弃，而这次放弃通常不会留下一个漂亮的状态码。表现就是：页面在浏览器里能打开，但日志里的抓取记录稀疏。
常见诱因是数据库慢查询、页面里同步调用了外部接口，或者某些动态参数页面触发了全表扫描。可以留意日志里响应时间明显偏长的那些 URL，是否集中在某几个模板或参数上。
5xx 与 429：告诉蜘蛛稍后再来
- 500、502、503 通常被理解为临时故障，蜘蛛会降低频率并在之后重试。短时间内大量 5xx 会明显拖慢整站抓取节奏。
- 429 是明确的“太快了”，一般配合 Retry-After 使用效果更好。
- 如果某个目录长期返回 5xx，蜘蛛可能在一段时间内减少对该目录的访问，恢复后需要时间重建。
蜘蛛会重试，但不是无限次
抓取失败后，蜘蛛通常会做有限次数的重试，间隔逐步拉长。也就是说，一次短暂的抖动影响有限，但如果你的服务器在蜘蛛常来的时段长期不稳定，它会把“这个站不太可靠”的判断落到抓取节奏上——来得更少、更慢。
另外，重试本身也占资源。同样的抓取能力被用在重试上，真正能拿到的新内容就更少。
一个可操作的排查顺序
- 先看日志里有没有记录。没有记录，往 DNS、网络、WAF 方向查。
- 有记录但状态码异常，按 5xx、429、超时分类统计，看集中在哪些 URL 和时段。
- 检查证书有效期与 TLS 配置，尤其是抓取量突然整体下滑时。
- 看响应时间分布，找出慢页面，判断是模板问题还是数据问题。
- 确认限速策略是否过严，把正常抓取也一起挡住了。
抓取失败不是一个二元状态，而是一段过程。哪一步断的，决定了你该修哪里。
把这些分层看清楚之后，“蜘蛛不来”就不再是一句笼统的抱怨，而是可以逐项验证的问题。