所有教程都说「等 24 到 48 小时 DNS 传播」。截至 2026 年 6 月，对于大家最常做的操作——在一个本来就能用的域名上改一条记录——这话几乎总是错的。Cloudflare、Route 53、NS1、Google Cloud DNS 把改动推到自己的边缘节点，普遍不到 5 分钟。你之后等的根本不是「传播」，而是某个 resolver 里旧值剩下的 TTL。改完 30 分钟还不通，那就是配置错了，不是传播问题。本文教你用几条 dig 命令证明到底是哪种情况。
一句话结论——真实时间线（截至 2026 年 6 月）
| 你做的改动 | 真实等待 | 硬上限 |
|---|---|---|
| 改一条已有的 A / CNAME / TXT 记录 | 几秒到几分钟 | 旧记录的 TTL（常见 300–3600 秒） |
| Cloudflare 代理记录（橙云） | 通常 2 分钟内 | 300 秒（Cloudflare 固定的代理 TTL） |
| 先降 TTL，24 小时后再改 | 一个你设的新 TTL | 新 TTL（如 300 秒） |
| 把已有域名指向新 nameserver | 几小时 | 约 24 小时（ICANN registry 规定） |
| 全新域名首次配 nameserver | 30 分钟到几小时 | 约 24 小时 |
最关键的杠杆是你要「替换掉」的那条记录的 TTL。你没法让缓存的 resolver 提前丢掉旧值，只能在改之前就把 TTL 设短。下面全部内容，都是教你把「缓存延迟」和「真的配坏了」分开。
为什么「传播」这个词是错的
根本没有什么全球推送把你的记录扇出到整个互联网。权威 nameserver 只是被查时返回你的记录加一个 TTL。resolver（你 ISP 的、1.1.1.1、你的笔记本）把这个回答缓存下来，反复用，直到 TTL 倒数到 0 才重新查。所以任何人卡在旧值上的最长时间，就是你改之前那条记录的 TTL。现代服务商默认 300 秒 TTL，这个天花板就是 5 分钟，不是两天。
那个著名的 24–48 小时只适用一种情况：改这个域名由哪些 nameserver 负责。这个改动在 registry 那边生效，ICANN 要求 registry 在 24 小时内处理完。实际上 .com、.net 通常几小时就推完了。
怎么区分缓存延迟和真问题
大概率是缓存延迟（等就行），如果：
- 自己能通但另一个国家的朋友不通，或者反过来。
- whatsmydns.net 这类检查工具有些区域显示新值、有些显示旧值。
dig +short yoursite.com在一个 resolver 返回新 IP，另一个返回旧 IP。
大概率是配置错了（别等了，去改），如果：
- 改完 30 分钟以上，每一个公共 resolver 都还返回旧值。
dig NS yoursite.com显示的 nameserver 根本不是你在改的那个。- host 后台显示「pending verification」，但
dig查到验证记录其实已经对了。
实操步骤
-
记下改动的准确时间。 从这开始算，不是从你发现不对劲那一刻算。
-
读旧 TTL——这就是你的最坏情况。
dig把它印在记录类型前面那个数字：
dig yoursite.com A
# ;; ANSWER SECTION:
# yoursite.com. 3600 IN A 151.101.1.195
# ^^^^
# TTL（秒）——旧值可能被缓存这么久- 连查两次
dig，看 TTL 在倒数——这个技巧多数人不知道。 如果第二次查数字变小了，说明你读的是缓存答案，倒数的数字正好告诉你旧值还能活多久。如果数字两次一样，说明你直接命中了权威服务器（它永远返回完整 TTL）：
dig +noall +answer yoursite.com A
# yoursite.com. 287 IN A 151.101.1.195 <- 这个缓存还剩 287 秒
sleep 5
dig +noall +answer yoursite.com A
# yoursite.com. 282 IN A 151.101.1.195 <- 在倒数，所以确实是缓存- 把你的 resolver 和公共 resolver 对比。 三个
+short都一致，说明你这边视角已经完全更新：
dig +short yoursite.com # 你本地 resolver
# 76.76.21.21
dig +short @1.1.1.1 yoursite.com # Cloudflare 公共 resolver
# 76.76.21.21
dig +short @8.8.8.8 yoursite.com # Google 公共 resolver
# 76.76.21.21- 确认到底谁在为这个域名应答。 「改了没用」的头号原因，就是你在注册商改 zone，但流量其实走 Cloudflare 或 Route 53：
dig NS yoursite.com +short
# adi.ns.cloudflare.com.
# kim.ns.cloudflare.com.
# → 该在 Cloudflare 后台改 zone，不是在注册商-
做多区域检查，用 whatsmydns.net 或 dnschecker.org。每一行是一个全球 resolver。数红点，别只扫绿勾。这些工具每次都重新查 resolver，所以一个区域过了 TTL 窗口还是红的，就很可疑。
-
host 显示「pending verification」时，先看它到底在查什么。 如果
dig已经返回了期望值，延迟就在 host 那边，不是 DNS：
# 确认 host 要的具体记录（以 Vercel 为例）
dig +short TXT _vercel.yoursite.com
# "vc-domain-verify=yoursite.com,abc123"
# 或者确认 A 记录 / CDN 端点已经活了
curl -sI https://yoursite.com | head -3记录对了的话，回 host 后台点「re-check / 刷新」，别干等。
- 新域名或刚换 nameserver？这才是真慢的情况。 验证 registry 是否已经接受你的 nameserver：
whois yoursite.com | grep -i 'name server'
# Name Server: ADI.NS.CLOUDFLARE.COM
# Name Server: KIM.NS.CLOUDFLARE.COM如果 whois 还显示旧 nameserver，说明 registry 还没处理完——这就是那个最长 24 小时的等待，你做什么都加不了速。
- 只在确实只有你自己机器卡住时，才清本地缓存：
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo resolvectl flush-caches
# Windows（管理员 PowerShell）
ipconfig /flushdns提前规划：迁移前先降 TTL
要彻底避免体感上的「传播」等待，干净的做法是在切换之前把 TTL 降下来：
- 迁移前 24–48 小时，把记录 TTL 设成 300（或你服务商允许的最低值——Cloudflare 非代理记录最低 60 秒）。
- 等旧的高 TTL 完全老化掉，这样 resolver 现在只缓存 300 秒。
- 再做真正的改动。resolver 在一个短 TTL 内就接上了。
- 新目标稳定后，把 TTL 调回 3600 或 86400，减少查询量。
Cloudflare 代理（橙云）记录是个特例：它的 TTL 固定在 300 秒（「Auto」），你改不了，但也没关系，因为它的边缘本来就两分钟内更新。
容易踩的坑
- nameserver 已指向 Cloudflare，还在注册商改 DNS。 Cloudflare 完全不读注册商 zone，改了等于没改。先跑
dig NS。 - 迁移前不降 TTL。 86400 的 TTL 意味着部分 resolver 缓存旧值整整一天。
- 相信浏览器。 浏览器和 OS 缓存 DNS 非常激进。下结论前先 flush DNS 或开无痕窗口测。
- 把 host 的每个延迟都当成 DNS。 经常是记录没问题，host 在签 SSL，或者在按自己的节奏跑域名验证轮询。
- 期待新买的域名 60 秒就通。 首次 registry 传播才是真正的慢路径，30 分钟到几小时都算正常。
FAQ
- 「24 到 48 小时」有真的时候吗？: 只有改域名的 nameserver 时（尤其全新域名）。在一个已经能解析的域名上改记录，是分钟级，上限是旧记录的 TTL。
- 怎么知道我看到的是缓存值还是实时值？: 隔几秒连跑两次
dig +noall +answer yoursite.com。TTL 数字变小，就说明你读的是缓存，那个数字就是它刷新前还剩的秒数。 - 能强制让改动更快传播吗？: 不能。你没法提前把某个值从别人的 resolver 里赶出去。唯一的杠杆是在改之前就设了低 TTL。你能清自己机器的缓存，但清不了全球互联网的。
- 为什么一个国家显示、另一个不显示？: 不同 resolver 在不同时刻缓存了旧值，所以它们的 TTL 倒数在不同时间结束。等最长的那个旧 TTL 过期，就都一致了。
- TTL 要一直留低吗？: 不要。低 TTL 意味着多得多的 DNS 查询。迁移稳定后调回 3600 或 86400。