站点訪問異常的时候，很多人的第一反應是服務器挂了、程序报错了、被攻击了。但有一類問题藏得更靠前：域名解析。它處在用戶和服務器之間的第一跳，平时几乎没人想起，一旦出错，表現却五花八门——有的地区能打開、有的打不開，有的设备正常、有的直接报错。排查时容易先怀疑程序，绕一大圈才回到解析上。
哪些現象可能指向解析問题
- 同一時間，不同地区或不同运营商的訪問结果不一致。
- 修改解析後，等了很久仍然不生效，或者只有部分網絡生效。
- 換了服務器，但仍有用戶被解析到舊 IP 上。
- 主域名正常，某個子域名却打不開。
- 接了 CDN 之後，回源異常或證书與解析對不上。
- 信箱、站点驗證、第三方服務的记錄突然失效。
這些現象不一定都是解析造成的，但只要出現，就值得把解析记錄先過一遍，因為它是最容易查、也最容易被忽略的一层。
解析记錄自查清單
记錄類型與指向是否正确
A 记錄、AAAA 记錄、CNAME、MX、TXT、NS 各司其职，先確認有没有重复、冲突或早已過期的记錄。重点看指向的 IP 是不是目前正在使用的服務器地址，換机、換服務商之後有没有同步更新。残留的舊记錄不一定马上出問题，但在迁移或切換时會突然冒出来。
TTL 是否設定得合理
TTL 太短，解析频繁變更會增加不必要的压力；太長，變更生效慢，出問题时回滚也慢。較稳妥的做法是：計划迁移前提前把 TTL 調小，等切換稳定几天後再調回常規值。如果從没關注過這項，可以先看看目前設定是多少。
子域名與泛解析
- 常用子域名如 www、m、api、static 是否都有正确记錄。
- 是否使用了泛解析，以至于測試域名、临时域名也被指向生产环境。
- 歷史上開過的子域名是否還能訪問，有没有已经不再使用的入口。
CDN 與 CNAME 的對應關系
接入 CDN 後，源站 IP 通常不應直接暴露，解析應指向服務商提供的 CNAME。需要確認 CNAME 是否按服務商要求填寫、證书是否覆盖目前域名、回源配置是否與源站實际地址一致。改動其中一环时，最好把另外两环一起看。
解析商與 NS 是否一致
NS 记錄决定了域名由哪家解析服務商负责。常见問题是：在 A 平台改了记錄，但域名的 NS 還指向 B 平台，等于白改。迁移解析服務商时，這條尤其要先確認。
變更时的操作建议
- 變更前先截图或導出目前解析记錄，留一份快照。
- 提前降低 TTL，给後續調整留出空間。
- 分批修改，先動低流量、影响面小的记錄。
- 變更後從多個網絡环境分別驗證解析结果。
- 观察一段時間後再收尾，不要刚改完就下结论。
- 准备好回滚方案，出問题时能快速還原。
日常可以做的小事
- 定期從不同地区节点解析主域名，對比结果是否一致。
- 把域名到期、證书到期、解析服務商帳號安全放在同一張日歷里。
- 解析服務商帳號開啟二次驗證，避免帳號层面的意外變更。
- 把 DNS 自查寫進季度运维清單，而不是等故障發生才翻记錄。
解析不是設定一次就一劳永逸的事。它和服務器、證书、CDN 一样，需要定期回头看。
DNS 自查並不复杂，成本也不高，但它能把很多模糊的訪問故障缩小到明确的范围。真正省時間的，往往不是出了事之後的补救，而是平时就清楚自己的解析结构長什么样。