域名解析是访客和蜘蛛到达站点的第一跳，也是最容易被忽略的一环。它平时安静得让人忘记存在，一旦要换服务器、上 CDN、加新子域，问题就集中冒头：一部分人访问到旧机器，一部分人访问到新机器，日志里两套 IP 混着出现，排查时又说不清是哪一层配错。下面这份清单按“定位—配置—切换—验证”的顺序整理，可以在动手前先过一遍。
一、先搞清楚是谁在解析
同名解析结果不一致，先别急着改记录，先确认差异来自哪一层。常见的链路有四段，任何一段都可能留下旧数据：
- 本地与系统缓存：浏览器、操作系统、部分安全软件都会缓存解析结果；
- 递归解析器：运营商或公共 DNS 会按 TTL 缓存，TTL 没到期就不会重新问；
- 权威 DNS：域名商或自建 DNS 上的记录，才是真正被读取的源头；
- 调度层：使用 CDN 或智能解析时，返回的 IP 是调度结果，不一定是源站地址。
用 dig 或 nslookup 分别向本地、公共 DNS 和权威服务器查询，看到的结果差异落在哪一段，基本就能定位问题范围。
二、日常最容易踩的几类配置问题
- TTL 设得过长：为了“稳定”把 TTL 设成一天甚至一周，真到迁移时旧记录会长时间残留，用户和新老机器之间来回跳。
- CNAME 与其他记录冲突：同一主机名同时存在 CNAME 和 A、MX、TXT 等记录，解析行为不确定，部分解析器会直接返回失败。
- 泛解析放得太宽：* 通配记录会让拼错的子域也返回正常页面，蜘蛛可能顺着无效地址抓到大量内容相同的页面。
- 线路解析漏配：做了电信、联通、移动分线路解析，却只配了一两条线路，其余线路回落到默认值，出现“部分地区打不开”。
- IPv6 记录与服务器不匹配：配了 AAAA 记录但服务器或安全组没有放行 IPv6，部分访客会拿到连不通的地址。
- 迁移时顺手删记录：整理解析列表时误删 MX、SPF、DKIM 或第三方验证用的 TXT，站点能开但邮件和验证全断。
- 域名本身的状态：到期时间、实名或备案状态、DNS 服务器是否被改动，这些属于基础项，建议固定周期核对。
三、换服务器或切换解析的推荐顺序
- 提前一两天把目标记录的 TTL 调低，给后续改动留出快速生效的窗口；
- 新环境先把站点跑通，用本地 hosts 或测试域名验证页面、证书、重定向、表单等关键路径；
- 确认证书覆盖所有要用到的域名与子域，避免切换后出现证书告警；
- 改动解析记录，一次只改一层，便于出问题时快速回退；
- 旧机器继续保留一段时间，观察访问日志是否还有请求打进来，确认没有遗漏来源；
- 稳定运行几天后，再把 TTL 恢复到常规值。
四、切换之后要验证什么
记录改完不等于事情结束，建议至少检查这几项：
- 从不同网络环境查询解析结果，确认各地返回一致；
- 用不带缓存的请求方式访问首页与几个内页，看返回状态码与内容是否正确；
- 查看站点日志里的来源 IP 分布，判断是否还有流量落在旧地址；
- 检查 HTTPS 握手是否正常，有没有证书不匹配或混合内容提示；
- 观察一段时间内的抓取情况，确认蜘蛛抓到的版本与当前线上版本一致。
五、把 DNS 纳入日常巡检
解析不需要天天改，但值得定期看一眼：保存一份当前解析记录清单，记录域名到期时间，给关键记录设置解析监控与告警。这样下一次迁移时，你手里有一份可对照的底稿，而不是对着一堆陌生的记录猜测哪条还能删。
DNS 出问题的特点是不报错、只是有人看不到、有人看到旧的。把记录、TTL 和到期时间管清楚，比出事后反复刷新缓存有效得多。