你从一个托管商迁到另一个，在 registrar 改了 A 记录。浏览器仍然打开旧主机，dig +short yourdomain.com 返回旧 IP。你确定改了 DNS，但改动毫无效果。
最快的修复： 运行 dig NS yourdomain.com。返回的那些 nameserver 才是全世界真正查询的权威 nameserver。如果它们不是你 registrar 的 nameserver（比如显示 cloudflare.com、vercel-dns.com 或 awsdns），那么你 registrar 的 DNS 面板就是个死胡同。登录那个权威提供商，删掉旧的 A/CNAME 记录，加上新的，改动会在记录 TTL 内生效。
整个问题几乎总是这一个错位：你在一个地方改 DNS，而真正回答查询的是另一个提供商。
60 秒诊断
按顺序运行这三条命令，它们能告诉你属于哪一类。
# 1. 到底是谁在回答这个域名？
dig NS yourdomain.com +short
# 2. 现在全世界看到的是什么 IP？
dig A yourdomain.com @1.1.1.1 +short
# 3. 完整委托链：根 -> TLD -> 权威
dig yourdomain.com +trace| 你看到的现象 | 可能原因 | 怎么修 |
|---|---|---|
dig NS 显示一个你没改过的提供商 | 权威 nameserver 在别处 | 去那个提供商改 DNS（原因 1） |
dig A @1.1.1.1 返回 2+ 个不同 IP | 旧记录跟新的并存 | 删掉陈旧记录（原因 2） |
dig A @1.1.1.1 是新的，本机 dig A 是旧的 | 本地缓存陈旧 | 清本地 DNS（原因 5） |
dig A @1.1.1.1 仍是旧的、但 NS 正确 | TTL 太高 / 还在传播 | 看 TTL，然后等（原因 3） |
| IP 属于某 CDN，不是你的源站 | 前置代理仍指向旧源站 | 改代理的源站（原因 6） |
关于 dig +trace：它从根域往下查，走的是真实 resolver 会走的同一条路，所以会绕过本地 resolver 缓存的任何答案。如果 +trace 的终点跟 registrar 的 WHOIS 显示的 nameserver 不一致，说明你正处于委托切换中、或者委托从未完成。把它跟 registrar 的 nameserver 字段对比：WHOIS 显示 registrar 委托了谁，dig NS 显示今天在回答的是谁。
常见原因
按命中率从高到低。
1. 权威 nameserver 在别处
你 registrar 的 nameserver（ns1.yourregistrar.com）不是世界查询的那些。世界查询的是 Cloudflare、Vercel DNS、Route 53，或者几个月前你委托出去的某处。registrar 面板的编辑没用，因为那个面板已经不是权威的了。
怎么判断：
dig NS yourdomain.com +short如果返回 Cloudflare 的 nameserver（leah.ns.cloudflare.com、walt.ns.cloudflare.com 等），那 Cloudflare 就是权威，registrar 的 DNS 面板无关。这是”我改了 DNS 却什么都没变”最常见的单一原因。
2. 旧 A / CNAME 记录跟新的并存
你加了新 A 记录但没删旧的。区域里现在同名有两条 A 记录，resolver 轮询返回，于是大约一半的请求仍落到旧主机。
怎么判断：
dig A yourdomain.com @1.1.1.1如果 ;; ANSWER SECTION: 里列出两条或更多指向不同 IP 的 A 记录，就有一条陈旧记录要删。
3. 旧记录的 TTL 太高
你改了记录，但它的 TTL 是 86400（24 小时）。在你改动之前缓存了旧值的 resolver 会一直提供旧值，直到 TTL 过期。截至 2026 年 6 月，多数 resolver 会在几小时内遵从 TTL，但 24 小时的 TTL 确实可能意味着要等 24 小时。
怎么判断： 看 dig A yourdomain.com 输出里的 TTL 列。如果数值很大、且改动是最近的，那修复方式就是等。下次改动之前把 TTL 降到 300。
4. 多个 A 记录（有意多主机，或意外）
A 记录分发在有意时没问题（一个主机的多个 IP 做轮询负载均衡）。当这些 IP 属于两个不相关的主机时就会出问题，因为一半流量去了旧主机。
怎么判断： dig A yourdomain.com +short 显示多个 IP。确认每个 IP 都属于同一个主机。源站混在一起就是原因 2 那种意外情况。
5. 本地 DNS 缓存陈旧
全球 DNS 已经在提供新 IP，但你笔记本的系统 resolver 或浏览器还握着旧答案。
怎么判断：
dig A yourdomain.com @8.8.8.8 +short # 公共 resolver：显示新 IP
dig A yourdomain.com +short # 系统 resolver：显示旧 IP如果公共 resolver 正确而本地的不对，就清本地缓存（见下面第 6 步）。
6. 前置 CDN 代理指向旧源站
Cloudflare 的橙云代理开着。公网 IP 是 Cloudflare 的 edge、不是你的主机，而 edge 配置成跟旧源站通讯。改被代理的 DNS 记录并不会改变 edge 把流量发到哪。
怎么判断： dig A 返回的 IP 属于 Cloudflare（或别的 CDN），不是你的主机。在 Cloudflare 仪表盘进入你的域名，再到 DNS 再到 Records，检查被代理的记录指向的源站。也检查 Rules 再到 Origin Rules（或旧的 Page Rule）里有没有钉死的源站。
最短修复路径
第 1 步：找权威 DNS 提供商
dig NS yourdomain.com +short这是真相。返回什么就是谁在服务你的 DNS。例子：
ns1.dreamhost.com-> DreamHost 权威leah.ns.cloudflare.com-> Cloudflare 权威ns-376.awsdns-47.com-> Route 53 权威
第 2 步：登录那个权威提供商
在那里改 DNS 记录，不是在 registrar。registrar 面板可能仍显示一个 DNS 章节，但如果 registrar 的 nameserver 不是权威的，那部分就是死代码，在里面保存什么都不变。
第 3 步：删旧的 A / CNAME 记录
加新记录前，先删同名的旧记录。不要两个都留，否则又会制造原因 2。
第 4 步：按主机要求加新记录
严格按你主机的文档。Vercel 顶级域（apex）的通用值是 A 76.76.21.21；截至 2026 年 6 月，Vercel 还建议运行 vercel domains inspect yourdomain.com 拿到按项目动态分配的值，比如 xyz.vercel-dns-016.com，它比旧的 76.76.21.21 和 cname.vercel-dns.com（两者仍然可用）更受推荐。子域名则用主机给你的 CNAME。参见 A vs CNAME 困惑。
第 5 步：全球验证
dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @1.1.1.1两个都应返回新 IP。如果有一个仍是旧的，说明改动没保存、改在了错误的提供商、或者还没传播。在 dnschecker.org 从多个地点交叉验证。
第 6 步：清本地 DNS
# macOS（Sonoma 及更新版本）
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
# Linux（systemd-resolved：Ubuntu 18.04+，较新的 Debian/Fedora/Arch）
sudo resolvectl flush-caches
# Windows 10/11
ipconfig /flushdns浏览器也要清：打开 chrome://net-internals/#dns（Edge：edge://net-internals/#dns），点 Clear host cache。
第 7 步：如何确认已修好
下面三条全部成立时就算修好了：
dig +short yourdomain.com @1.1.1.1只返回新 IP，没有旧 IP。curl -sI https://yourdomain.com返回新主机的响应头（看server:或主机特有的头，例如x-vercel-id）。- dnschecker.org 上多数地区都绿色显示新 IP。
如果 dig 已正确但浏览器仍打开旧站，那只是本地缓存（原因 5），不是 DNS 问题。
第 8 步：记下权威提供商
在 DNS.md（或你的运维手册）里记一条，例如：yourdomain.com 的权威 DNS：Cloudflare (leah/walt.ns.cloudflare.com)。就是这条记录能让你下次不再改错面板。
哪些情况可能不是你操作错了
某些 resolver 和 ISP 不看 TTL 一直过度缓存，而 nameserver（NS）变更尤其可能要 24-48 小时才稳定，因为它要经过 TLD 的父区域传播，比单纯改一条 A 记录慢。截至 2026 年 6 月，单条 A 记录变更通常几小时内可见，但一次完整的 nameserver 委托切换确实可能要两天。在认定有东西坏掉之前，先用 dnschecker.org 从多个地理位置验证。
容易误判的情况
人们在 nameserver 指向别处时却去 registrar 改 DNS。改动在 registrar UI 里保存成功、不报任何错，却对全世界解析到什么毫无影响。动任何记录之前，永远先运行 dig NS。
预防建议
- 每个域名记下权威 DNS 提供商（写在
DNS.md里）。 - 任何主机变更至少 24 小时前把 TTL 降到 300 秒，让缓存的旧值尽快过期。
- 换主机后删掉旧的 A/CNAME 记录，不要留着。
- 共享 / 团队域名，把 DNS 编辑权限限制给一个人，避免两人互相覆盖记录。
- 用多个公共 resolver（
@8.8.8.8、@1.1.1.1）验证，不只是本机。
FAQ
- 怎么找权威 DNS 提供商？ 运行
dig NS yourdomain.com +short，返回的 nameserver 就是权威的。要看从根域往下的完整委托链，用dig yourdomain.com +trace。 - registrar 显示的 nameserver 跟
dig NS不一样，哪个对？ WHOIS / registrar 字段显示的是委托了谁；dig NS显示的是现在在回答的是谁。nameserver 切换期间两者会不一致，最长 24-48 小时。判断”今天该去哪改”时以dig NS为准。 - 能 registrar DNS 与 Cloudflare 同时用吗？ 不能。只有一组 nameserver 是权威的。把 registrar 设为委托给 Cloudflare 的 nameserver，然后所有记录都在 Cloudflare 管。
- 我改对了地方、
dig @1.1.1.1也正确，但浏览器还是打开旧站，为什么？ 那是本地缓存陈旧，不是 DNS。清系统 resolver 并清浏览器 host cache（第 6 步）。不是全局问题。 - 改动多久才全网生效？ 截至 2026 年 6 月，单条 A/CNAME 变更通常几小时内可见；nameserver（NS）委托变更可能要 24-48 小时，因为要经过 TLD 父区域传播。
dig返回的 IP 不是我主机的 IP。 它很可能是某个 CDN edge（Cloudflare、Fastly）。代理指向了你的旧源站。去 CDN 仪表盘里改源站，而不是改公网 DNS 记录（原因 6）。
相关阅读
标签: #域名 #DNS #SSL #排查 #Name Server