蜘蛛要抓一个页面，第一步并不是读 HTML，而是把域名解析成 IP、建立连接、完成加密握手，然后才拿到源站或 CDN 返回的内容。这几步里任何一环出问题，外在对表现往往都一样：抓取失败或者超时。内容层面的自查做过很多，但基础设施这一层如果平时不看，出问题时就容易从一个栏目一路查到服务器，花掉不少时间。
域名解析：能解析不等于解析稳定
解析正常是常态，所以大家很少主动检查它，直到某次改完记录，发现部分地区的请求落到了旧地址上。可以按下面几项过一遍：
- 记录是否齐全：主域名和 www 是否都指向了正确位置，别只解析其中一个，另一个靠跳转兜底。
- TTL 设置：计划改解析之前，先把 TTL 调小，等旧记录过期再切换，减少切换期间请求分散到两个地址的情况。
- 多 IP 与多线路：如果配了多条 A 记录，逐一确认每个地址都能正常响应，别让蜘蛛随机分到一个已经下线的节点。
- 变更后的观察：改完至少观察一个 TTL 周期，确认各地解析结果趋于一致，再去看抓取数据是否恢复。
证书：有效期、链完整与域名覆盖
证书问题的特点是来得突然。到期当天之前一切正常，过期之后所有请求直接失败。与其等提醒，不如把它当成一个固定条目：
- 记录每张证书的到期时间，提前留出更换和生效的缓冲期。
- 检查证书链是否完整，中间证书缺失时，部分客户端会直接拒绝连接。
- 确认域名覆盖范围，带 www 与不带 www、常用子域名是否都在证书里。
- 确认从 HTTP 到 HTTPS 的跳转只有一跳，不要出现跳转之后再跳转。
CDN 与回源：节点之间可能不一样
用 CDN 的好处是就近响应，麻烦也在这里——不同节点拿到的结果可能并不一致。自查时可以关注三件事：回源是否正常、缓存命中是否稳定、有没有个别节点返回 5xx 而其他节点正常。
遇到「自己这边能打开、蜘蛛那边抓不到」的情况，先别急着改页面，可以换个地点、换个网络多测几次同一个 URL，把节点差异先排除掉。
源站时间与时区
服务器时间不准，会连带影响几件事：Last-Modified 的判断、日志时间的排序、以及部分证书校验逻辑。日志时间错乱时，按小时统计抓取量就会失真，看到的高峰可能是假的。建议保持系统时间同步，并统一时区，分析日志时心里有数。
可以固定下来的巡检节奏
- 每周：抽查首页和几个主要栏目页的响应时间与状态码，顺手确认 HTTPS 是否正常。
- 每月：确认证书剩余天数、DNS 记录有没有被意外改动、CDN 配置是否被同事调整过。
- 变更前后：任何解析、证书、CDN 配置的改动，都先记录变更时间和内容，再观察一到两天的抓取数据，确认没有异常波动。
基础设施的问题，很多时候不是「抓不到」，而是「偶尔抓不到」。偶发的问题最难发现，也最值得用固定节奏去覆盖。
这一层不需要多复杂的工具，把关键节点、检查项和变更记录固定下来就够了。等到抓取数据出现异常时，你至少有一条清晰的线索可以顺着查下去。