抓取从解析域名开始
蜘蛛要抓一个 URL，第一步不是发 HTTP 请求，而是把域名解析成 IP。这一步通常很快，但一旦出问题，表现往往不是 404 或 500，而是抓取频次悄悄下降。访问日志里看不到记录，却在抓取数据里出现拐点。
常见的情况包括：权威 DNS 响应慢、解析结果在多个 IP 之间来回切换、CNAME 链过长、TTL 设置过短导致频繁重查。蜘蛛通常有自己的 DNS 缓存，但如果每次解析结果都不一样，它可能在不同 IP 上得到不一致的响应，抓取行为也会变得不稳定。
连接建立与 TLS 握手
解析到 IP 之后是 TCP 连接，再往后是 TLS 握手。对 https 站点来说，证书是硬门槛：过期、域名不匹配、中间证书缺失，都可能导致抓取直接失败。这类失败通常不会落在源站访问日志里，因为请求根本没到达源站。
- 证书到期时间要提前安排续期，不要等到最后一天。
- 确认证书覆盖带 www 与不带 www 的域名，避免解析到了却握手不成功。
- SNI、ALPN、HTTP/2 的配置要和 CDN、源站保持一致。
- 如果只支持较老的低版本 TLS，部分抓取客户端可能连不上。
CDN、WAF 与源站之间的那一段
很多时候域名解析到的是 CDN 边缘节点，蜘蛛拿到的是边缘返回的页面。这一层如果有 WAF 规则、速率限制或人机校验，蜘蛛可能被挡在门外，而你从源站日志里什么也看不到。回源失败、边缘缓存异常、按地区返回不同内容，也会让同一批 URL 的抓取结果前后不一致。
还要注意 IPv4 与 IPv6 的差异。有些域名只对其中一种协议做了完整配置，蜘蛛走另一条路时可能超时或得到默认页。定期用两种协议分别测一测，比较省事。
从日志和数据里判断问题出在哪
DNS 失败和连接失败不会出现在访问日志中，所以不能只盯着 200 和 404 的比例。可以结合几个信号：
- 抓取总量在没有改版的情况下明显下滑。
- 不同机房、不同解析 IP 的返回结果不一致。
- 用 curl --resolve 指定 IP 访问，复现蜘蛛看到的结果。
- 看 TTFB 的构成，区分是 DNS、连接还是后端处理耗时。
如果确认是解析或证书问题，修复通常很快，恢复抓取却需要一段时间。蜘蛛会记住失败的路径，短期内不会立刻回到原来的频次。
让抓取通道保持稳定
- DNS 记录尽量简单，少用多层 CNAME，TTL 保持合理区间。
- 证书到期前完成续期，检查域名覆盖范围。
- 不要频繁更换源站 IP 或解析策略，给蜘蛛一段稳定的观察期。
- CDN、WAF 与源站对蜘蛛的策略保持一致，避免一层放行一层拦截。
- 把 DNS、证书、连通性纳入日常巡检，而不是等抓取量掉了再查。
抓取不只是内容层面的事，链路上的每一段都可能成为瓶颈。把基础设施当作抓取路径的一部分来看，很多问题会更容易定位。