访客打不开网站，很多时候问题既不在服务器，也不在代码，而是卡在最前面的一步：域名解析。DNS 平时安静得几乎让人忘记它的存在，可一旦记录被改错、TTL 设得不合适，或者域名本身出了状况，整站就会一起"消失"，而且从服务器内部看日志几乎是干净的，排查方向很容易跑偏。
先把域名本身的状态确认一遍
解析记录是在域名之上的，域名本身有问题，记录配得再对也没用。建议每隔一段时间登录注册商后台看几项：
- 到期时间与自动续费：是否已开启自动续费，绑定的支付方式是否还有效。到期后进入宽限期，解析会先被停掉。
- 域名状态：确认没有出现 clientHold、serverHold 这类暂停解析的状态。
- 注册邮箱：注册时填的邮箱现在还能不能收信。续费提醒、转出确认、实名审核通知都发到这里，邮箱失效等于失去控制权。
- 实名与资质：需要审核的域名，确认审核已通过且没有过期材料。
- 转移锁：开启转移锁可以降低域名被恶意转走的风险，但自己真要转移时记得先关掉。
逐条核对关键解析记录
A 记录与 AAAA 记录
最容易被忽略的情况是服务器换过机器、换过公网 IP，解析记录却还是旧的。核对一下 A 记录指向的 IP 是否就是当前服务器的地址，如果启用了 IPv6，AAAA 记录同样要确认。
CNAME 与 CDN 接入
接入 CDN 后，主域名的 CNAME 应该指向服务商给的地址。要注意两件事：一是 CNAME 链条不要拉得太长，中间某一环失效会直接导致解析失败；二是回源配置是否还指向现在这台源站，源站换过 IP 而回源地址没更新，访客看到的就是 5xx 或空白页。
顺带检查 MX 和 TXT
很多人的注意力全在网站解析上，把邮箱记录改没了还不知道。MX 记录关系到企业邮箱能否收信，SPF、DKIM、DMARC 这类 TXT 记录关系到邮件送达率。改解析时如果用的是"清空重配"的方式，很容易顺手把这些记录一起删掉。
TTL 决定变更生效的快慢
TTL 是解析记录的缓存时间。平时可以把 TTL 设得长一些，减少解析查询压力；一旦计划迁移服务器或更换 CDN，提前一天把 TTL 调低到几百秒，等旧缓存自然过期后再做变更，切换过程会平滑很多。变更完成后，再按需调回原来的值。避免在流量高峰时段直接改动，也避免调低 TTL 后立刻切换，那样等于没调。
判断解析是否真的生效
本地看到的解析结果不一定代表全局，因为本地和运营商的 DNS 缓存还没过期。想确认结果，可以这样做：
- 用几个不同的公共 DNS 查询工具分别查询，看返回的 IP 或 CNAME 是否一致。
- 在本机刷新 DNS 缓存后再试，排除本地缓存干扰。
- 用不同网络环境测试，例如公司网络、手机移动网络、家用宽带，观察是否存在地域差异。
- 命令行下用 dig 或 nslookup 指定具体 DNS 服务器查询，绕过默认解析器，结果更接近真实情况。
- 如果多地结果长期不一致，检查解析商是否配置了分线路解析，以及各线路是否都填了正确的地址。
几个容易踩的坑
- 只配了 www 忘了裸域：访客直接输入不带 www 的域名就打不开，或者反过来。两个入口都应该可达，并统一跳转到同一个版本。
- 泛解析意外开启：\*.example.com 指向服务器后，任何拼错的子域都能解析成功，可能出现重复内容和无意义的抓取入口。
- 残留记录没清理：换过的旧 CDN、停用的测试子域、废弃的第三方服务 CNAME，都还挂在解析列表里。
- 注册商和解析商不是同一家：改记录时找错后台，改完发现根本没生效。
一份可执行的自查清单
- 域名到期时间、自动续费、注册邮箱是否可用。
- A 或 CNAME 是否指向当前的服务器或 CDN 地址。
- 裸域与 www 是否都可达，跳转是否统一。
- 是否存在多余的泛解析或废弃子域记录。
- MX 与 TXT 记录是否完整，邮箱收发是否正常。
- TTL 是否与近期的变更计划匹配。
- 多地查询结果是否一致，有无长期未生效的线路。
- 每次变更后留一份记录，写清楚改了什么、为什么改。
DNS 不出问题的时候，几乎没人会想起它；可它一旦出问题，就是整站级别的。把这几项并进上线和迁移的检查清单里，比事后从服务器日志里一点点倒查要轻松得多。