抓取日誌里出現“同一时段一部分請求成功、一部分连不上”的情况时，很多人的第一反應是限流或防火墙拦截。但在排除 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 發現和抓取路径的维護，最终都要落在“蜘蛛能不能稳定地连上並拿到内容”這件事上。解析层的抖動看起来琐碎，但它影响的是每一次握手的成功率，長期累积下来會明顯影响新入口被發現的速度。把解析结果、健康检查與日誌統計三件事固定成例行检查項，比事後逐條翻日誌要省力得多。