聊蜘蛛抓取，多数人先看页面层：内链、Sitemap、robots.txt、内容质量。但蜘蛛发出的第一条请求，走的第一段路其实是网络层——域名解析、连接建立、CDN 回源。这一层不稳定，页面层做得再规范，蜘蛛也可能根本拿不到东西。
蜘蛛的一次请求，会经过哪几步
以 https://example.com/a 为例，蜘蛛大致会做这几件事：
- 查询 DNS，把域名换成 IP 地址；
- 与这个 IP 建立连接，HTTPS 还要完成 TLS 握手；
- 如果站点接了 CDN，请求先到边缘节点，再由节点回源站取内容；
- 拿到状态码和 HTML，才开始解析链接、继续往下抓。
前两步失败，蜘蛛拿到的是解析超时或连接超时，而不是一个明确的 404；第三步失败，你看到的往往是 CDN 返回的 5xx、超时页，或者节点自己生成的错误响应。
DNS 层面的常见坑
TTL 设得太长，换 IP 后蜘蛛还在敲旧地址
迁移服务器或更换接入商时，如果域名 TTL 设为 24 小时，各地递归解析器会继续缓存旧 A 记录。蜘蛛的抓取节点分布在不同网络环境，缓存到期时间不一致，于是同一批 URL 里，一部分抓到新 IP，一部分还在撞旧 IP，表现为随机失败、间歇超时。做迁移前把 TTL 调短（比如 300 秒），观察一两天再切换，能明显减少这种抖动。
多个 A 记录里有一个是坏的
有的站点为了冗余配了多条 A 记录，其中一台机器已经下线或防火墙没放行。解析器可能轮询到这条记录，蜘蛛就连不上。要么及时清理无效记录，要么在前面加一层带健康检查的负载均衡，让解析结果始终指向可用节点。
权威 DNS 本身响应慢
免费的解析服务偶发抖动时，解析耗时可能从几十毫秒涨到几秒。单次抓取的等待时间被拉长，整体抓取节奏自然变慢。这类问题从页面代码里完全看不出来，只能通过多地解析测试对比发现。
CDN 与回源：别把回源超时当成抓取异常
蜘蛛抓取的 URL 里，很多是缓存未命中的新页面。这时边缘节点必须回源，源站响应慢或并发受限，节点就可能返回 5xx 或超时页。蜘蛛遇到持续的 5xx，会主动降低对站点的抓取频率，等站点稳定后再逐步恢复。所以看到抓取量下滑时，先确认是源站问题还是页面问题，再看是不是 CDN 回源配置导致。
几种容易忽略的情况：回源协议与站点实际协议不一致（例如站点只监听 HTTPS，回源却用 HTTP）；回源时 Host 头被改写，源站虚拟主机匹配不到，直接返回默认站点内容；CDN 缓存规则把 robots.txt 或 Sitemap 也缓存住，蜘蛛读到的是旧版本。
一份可操作的排查清单
- 用多个公共解析服务对比同一域名的解析结果，看是否一致、是否明显变慢；
- 直接绑定源站 IP 请求一次，和走 CDN 的结果对比状态码与响应头；
- 在 CDN 日志里按蜘蛛 UA 过滤，看 2xx、3xx、4xx、5xx 的分布；
- 确认 robots.txt、Sitemap、主要入口页是否也走了 CDN，是否存在缓存或拦截规则；
- 检查回源协议、端口、Host 头是否与源站配置匹配；
- 换 IP 或换 CDN 前后，观察抓取日志里超时请求的比例变化。
它和 URL 发现的关系
网络层长期不稳定，受影响的不只是某一个页面。蜘蛛在首页拿不到内容，就发现不了下一层链接；列表页超时，后面的详情 URL 就迟迟进不了抓取队列。Sitemap 提交只是把 URL 送进队列，真正决定它们能否被抓到、多久被复查的，仍然是每一次请求能不能顺利拿到响应。把 DNS 和 CDN 这两段路走通，是页面层优化能生效的前提。