抓取日志里出现“同一时段一部分请求成功、一部分连不上”的情况时，很多人的第一反应是限流或防火墙拦截。但在排除 5xx、403 与 robots 规则之后，还有一类更隐蔽的原因：域名解析结果不稳定，或者同一个域名解析出多个 IP，其中只有一部分线路对搜索蜘蛛可达。这类问题不会在服务器访问日志里留下明显痕迹，因为请求根本没到达应用层。
一、先看清失败发生在哪一层
把失败请求按“有没有到达服务器”分成两类，能省掉大量无效排查。
- 连接层失败：表现为连接超时、连接被重置、TLS 握手失败，没有 HTTP 状态码。服务器访问日志里往往完全没有这条记录。
- 响应层失败：有明确状态码，比如 503、403、502。这类要看限流、WAF 与后端服务状态。
如果同一个 URL 在几分钟内被反复尝试，有时成功有时失败，且失败集中在连接阶段，那么优先怀疑线路与解析，而不是抓取配额。
二、解析层常见的几种情况
- 多 A 记录里有一条指向已下线的旧机房，或指向尚未放行的 IP，健康检查没有及时摘除。
- CNAME 链过长，中间某一跳解析耗时明显偏高，偶尔超时。
- 域名发布了 AAAA 记录，但服务器未监听 IPv6，蜘蛛走 IPv6 直接失败，而 IPv4 请求正常。
- TTL 设置过短，解析结果在短时间内频繁变化，抓取窗口内拿到的 IP 不一致。
- 权威 NS 只有一个，或 NS 与主站部署在同一台机器上，机房抖动时解析整体不可用。
- 智能解析按来源返回不同节点，而其中某个节点对特定区域或特定网络不友好。
三、按这个顺序排查
- 用多个公共解析器分别查询 A、AAAA、CNAME，对比结果是否一致，记录差异出现的频率。
- 对每个返回的 IP 逐一做连通性测试：端口是否可达、TLS 握手是否正常、返回头是否符合预期。
- 确认 AAAA 记录是否有对应的监听服务，没有明确支持就暂时不要发布。
- 查看 CNAME 链长度与每一跳的解析耗时，去掉不必要的中间层。
- 检查 TTL 设置与 NS 冗余，避免解析记录频繁变更或单点解析。
- 与 CDN 或负载均衡侧核对节点健康检查与自动摘除逻辑，确认故障 IP 是否被排除在调度之外。
四、修复与长期观察
修复的思路不是“把所有 IP 换一遍”，而是让调度结果稳定且可解释。
- 下线长期不可达的 IP，多 IP 场景必须配合健康检查自动摘除。
- TTL 保持适度，不要在短时间内反复调整，变更期间保留旧 IP 一段时间再回收。
- 把抓取日志按解析到的 IP 分组统计成功率，这样线路问题会以“某一 IP 成功率明显偏低”的形式暴露出来，而不是被整体平均值掩盖。
一个实用的区分方法：如果失败请求在服务器日志中完全查不到，优先查 DNS 与网络；如果日志里有记录但状态码异常，再去查限流、WAF 与后端服务。两类问题的处理顺序不要混在一起。
URL 发现和抓取路径的维护，最终都要落在“蜘蛛能不能稳定地连上并拿到内容”这件事上。解析层的抖动看起来琐碎，但它影响的是每一次握手的成功率，长期累积下来会明显影响新入口被发现的速度。把解析结果、健康检查与日志统计三件事固定成例行检查项，比事后逐条翻日志要省力得多。