域名 DNS 解析故障排查：网站无法访问的常见原因与解决方法
"网站打不开"是站长最常遇到的求助。虽然报错五花八门——浏览器提示"找不到服务器"、请求间歇性超时、有的地区能打开有的打不开——但十有八九问题出在 DNS 解析环节。DNS 就像互联网的电话簿，负责把 example.com 这样的域名翻译成服务器的 IP 地址。这一步出了问题，后面的 HTTP、HTTPS、邮件服务全都无从谈起。
参考：Cloudflare 关于 DNS 的官方科普 https://www.cloudflare.com/learning/dns/what-is-dns/
DNS 解析是怎么工作的
一次完整的解析通常要经过本地缓存、递归解析器、根服务器、TLD 服务器和权威服务器几个环节：
- 浏览器先查本地 DNS 缓存（浏览器、操作系统、路由器各级缓存）；
- 缓存未命中，请求交给递归解析器（通常是 ISP 或 8.8.8.8 这类公共 DNS）；
- 递归解析器依次询问根服务器、
.com的 TLD 服务器，最终找到域名的权威 NS 服务器； - 权威服务器返回 A/AAAA/CNAME 记录，解析器缓存结果并按 TTL 失效。
任何一个环节延迟、超时或返回错误数据，都会表现为"网站打不开"。理解了这条链路，排查时就能顺着它逐级验证。
常见 DNS 故障类型
| 故障类型 | 现象 | 常见原因 |
|---|---|---|
| 域名未解析 | 浏览器提示找不到服务器、DNS_PROBE_FINISHED_NXDOMAIN | 记录未添加、拼写错误、未生效 |
| 解析到错误 IP | 打开的是别的网站或报证书错误 | A 记录填错、CDN 切换残留旧 IP |
| 解析缓慢 | 首屏加载很慢、浏览器长时间转圈 | 递归解析器慢、权威服务器响应慢 |
| 部分区域无法访问 | 移动能开、宽带打不开，或国内外不一致 | 传播未完成、地区解析策略 |
| 间歇性失败 | 有时能开有时不能 | TTL 太短导致缓存频繁刷新、上游抖动 |
排查工具
下面这些命令按"由近及远"的顺序使用，可以快速定位问题出在哪一环。
# 1. 基础查询：看记录是否存在、值是否正确
nslookup example.com
nslookup -type=MX example.com # 查邮件记录
nslookup -type=NS example.com # 查权威服务器
# 2. 跳过本地缓存，直接用公共 DNS 查询，排除本机/ISP 缓存干扰
dig example.com @8.8.8.8
dig +short example.com A
# 3. 查 WHOIS，确认域名状态和 NS 是否被注册局正确接管
whois example.com
# 4. 检查网络连通性（确认不是服务器宕机）
ping -c 4 example.com
curl -sv https://example.com
dig返回里，status: NOERROR表示解析成功，NXDOMAIN表示域名不存在，SERVFAIL表示权威服务器异常。- 在线工具如 whatsmydns.net 可从全球多个节点同时查询，适合判断是否只是"部分地区还没传播完"。
一次典型的排查过程
假设用户反馈 example.com 打不开，可以按下面的流程走一遍：
- 先用
nslookup example.com看本机解析结果——如果显示 NXDOMAIN，先检查记录是否真的添加了、是否漏了主机名（很多新手把example.com和www.example.com当成一回事，只配了 A 记录却没配www）。 - 本机查不到，但
dig example.com @8.8.8.8能查到——问题在本地缓存或 ISP 的递归解析器，清缓存、换 DNS 即可。 - 两个都能查到，但网站还是打不开——用
curl -sv和ping排除服务器和网络层问题。 - 网站能开但邮件收不到——查 MX 记录是否配置，SPF/DKIM/DMARC 是否完整。
常见问题与解决方法
| 问题 | 解决方法 |
|---|---|
| 记录改了但没生效 | 新记录通常 5 分钟到 1 小时生效，改 NS 才需要 24-48 小时；可用 dig @新NS 提前验证 |
| NS 记录指向错误 | 登录注册商，把 NS 指向 DNS 托管服务商指定的两组服务器 |
| TTL 设置过长 | 计划迁移前 48 小时把 TTL 调低到 300 秒，切换完成后再调回 |
| DNSSEC 配置错误 | 检查 DS 记录是否与公钥签名匹配，错误配置会导致整域 SERVFAIL |
| CDN 切换后仍有旧 IP | 先确认 CNAME/A 记录已更新，再用 dig +short 对比新旧地址 |
预防措施
DNS 故障很难做到零发生，但可以通过下面几点大幅降低概率：
- 使用稳定的托管 DNS 服务商（Cloudflare、阿里云 DNS、DNSPod 等），避免把 NS 放在单点。
- 保留两组以上的 NS 记录，分散在不同网络。
- 日常记录 TTL 保持在 600-3600 秒，不要随意调低。
- 开启监控（UptimeRobot、自建定时 dig），解析异常第一时间告警。
- 启用 DNSSEC 防止 DNS 劫持，但务必先在测试环境验证 DS 记录，否则可能导致整域不可解析。
16IDC 观察
域名解析看起来是"小事"，却是网站可用性的地基。建议把解析记录纳入版本管理：每次变更记录前先记录旧值，变更后用 dig 双端验证，重要域名尽量配置 DNSSEC 和解析监控。这样即使出现故障，也能在十分钟内定位到具体环节，而不是半夜对着控制台干着急。