很多人排查抓取问题，习惯从页面本身找原因：内容是不是太薄、内链是不是断了、Sitemap 是不是漏了 URL。但抓取动作的第一步并不在页面上，而在更靠前的位置——蜘蛛得先解析出你的域名指向哪台机器，再和那台机器完成一次加密握手，最后才谈得上发送请求、读取 HTML。这几步出了问题，源站访问日志里往往连一行记录都没有，于是结论就变成了「蜘蛛一直没来」。
为什么抓取失败有时连日志都没有
访问日志记录的是「已经到达服务器并被处理」的请求。如果蜘蛛在 DNS 解析阶段就失败了，或者 TLS 握手被拒绝、连接还没建立起来就被重置，这些请求不会写进日志。此时你看日志是干净的，看抓取统计却是零，两边对不上。排查这类问题时，只盯着源站日志会漏掉一大段链路，需要把 CDN、DNS 服务商、证书监控这些环节一起纳入视野。
第一道门：DNS 解析
蜘蛛拿到 URL 后，第一步是把域名换成 IP。这一步通常很快，但出问题的概率并不低，尤其是刚做过迁移的站点。
- TTL 设置过长：换 IP 之后，旧地址还会被各层递归解析器缓存一段时间。如果之前把 TTL 设成了 24 小时，切换期间的抓取可能会打到已经下线的机器上。
- CNAME 链太长：多个 CNAME 层层指向，解析过程变长，偶尔还会在中间某一环断掉。
- 泛解析与错误子域：泛解析把所有子域都指向同一个地址，某些解析器返回的结果可能不符合预期，也容易让错误子域被当成有效站点。
- 解析服务本身不稳定：权威服务器响应慢或间歇性超时，蜘蛛侧感受到的就是「这个域名时好时坏」。
自查方式很直接：用不同地区、不同运营商的公共解析服务去查同一个域名，看返回结果是否一致、响应是否稳定。如果只有部分地区解析异常，问题基本可以定位到 DNS 这一层。
第二道门：TLS 握手
解析出 IP 之后，现代站点大多要走 HTTPS。握手环节的常见问题有以下几类。
- 证书过期或域名不匹配：这是最干脆的一类失败。证书到期当天，抓取量可能直接归零，而且源站日志不会有任何记录。
- 中间证书缺失：浏览器有时会自行补链，但抓取程序未必有这个容错，握手可能直接中断。
- 只支持过旧的协议版本：部分老服务器只开了很陈旧的 TLS 版本，抓取端拒绝协商，连接无法建立。
- SNI 配置不完整：同一台机器上挂多个站点时，如果默认站点没有兜底证书，访问未匹配的域名会拿到错误的证书。
- CDN 回源证书问题：用户侧证书正常，但 CDN 回源到源站那一段证书有问题，抓取同样会在回源时失败。
建议把证书到期时间纳入例行监控，而不是等抓取量掉了才去查。很多抓取中断事件，追溯到最后就是一张过期证书。
第三道门：连接建立与复用
握完手，连接真正建立起来，接下来才是请求和响应。这一层的问题不像证书过期那么明显，但影响范围更广。
- Keep-Alive 时间过短：连接频繁断开重建，抓取端每次都要重新握手，整体吞吐会下降。
- 并发连接限制过严：防火墙或 WAF 对同一来源的并发连接做了很低的限制，抓取端拿不到足够的通道，只能排队等待。
- 握手阶段被限速或拒绝：有些防护策略在连接层面就拦截，看起来像是「服务器没响应」。
- 首字节时间过长：连接建立了，但服务器迟迟不返回第一个字节，抓取端等不到响应就超时断开。
- 源站与 CDN 的超时设置不一致：CDN 侧等待 60 秒，源站 30 秒就断开，结果两边都认为自己正常，抓取端只看到失败。
抓取被中断之后会发生什么
需要说明的是，单次连接失败并不会立刻导致站点被放弃。抓取系统通常会把 URL 放回队列，间隔一段时间后重试；如果连续多次失败，抓取频率会被调低，重试间隔逐步拉长。所以真正麻烦的不是偶发的失败，而是持续性的、覆盖整个域名或整个 IP 段的失败——它会让抓取节奏整体放缓。
一份可以照着走的排查顺序
- 从外部多个节点解析域名，确认返回结果一致且稳定。
- 检查证书的剩余有效期、证书链是否完整、是否覆盖所有使用的子域。
- 查看 CDN 的回源日志，确认失败发生在用户侧还是回源侧。
- 对比源站日志与 CDN 日志，找出「CDN 收到了但源站没有」的那部分请求。
- 用不同的 User-Agent 和来源 IP 做一次手动请求，看是否被连接层面的策略拦截。
- 确认 Keep-Alive、超时、并发限制这几项配置在源站与 CDN 之间是对齐的。
抓取链路的前半段属于基础设施问题，它不体现在页面质量上，却决定了蜘蛛有没有机会看到页面。把 DNS、证书、连接这三项纳入日常监控，比事后反复检查内容更省力。