Mist Network
DNS 生效时间：域名解析多久生效，如何加快 DNS 传播
DNS 修改并不会被“推送”到任何地方，只是旧的解析结果从缓存中过期而已。了解真正决定 DNS 生效时间的因素，让下一次修改在几分钟内完成。
DNS 生效时间（也常被称为 DNS 传播时间）是指从你保存 DNS 修改，到互联网上所有解析器都返回新结果之间的延迟。普通解析记录的修改通常需要几分钟，最长不超过该记录原来的 TTL；而修改 NS 服务器则可能需要 24–48 小时，因为上级区域的委派记录会被缓存更久。
“传播”这个词其实有点误导。并没有任何东西在互联网上广播。你点击保存的那一刻，权威 DNS 服务器就已经知道了新值。你真正在等待的，是运营商、公共解析器、路由器和操作系统中成千上万个独立缓存，丢弃它们之前保存的结果并重新查询。
为什么 DNS 修改不能立即生效
每个 DNS 应答都带有一个 TTL（生存时间），即一个秒数，告诉解析器在重新查询之前可以重复使用这个结果多久。如果访客的运营商解析器查询你的 A 记录时 TTL 为 3600，那么在你修改之后，这个解析器最多还可以继续返回旧 IP 一小时，无论你的 DNS 服务商速度有多快。
这就是全部机制。不同的解析器在不同时刻获取了你的记录，所以它们的缓存也在不同时刻过期。这就是为什么一个朋友已经看到新网站，另一个却还看到旧网站；也是为什么在线“DNS 生效检测”工具会在一段时间内显示红绿交错的地点。
域名解析多久生效？常见时间参考
答案取决于你修改了什么。下表列出了实际的时间范围，前提是缓存遵守 TTL（大多数大型解析器都会遵守）。
| 修改内容 | 决定延迟的因素 | 常见时间 |
|---|---|---|
| 修改 A、AAAA 或 CNAME 记录 | 该记录原来的 TTL | 1 分钟至原 TTL（通常 5 分钟到 1 小时） |
| 添加一条全新记录 | 否定缓存（SOA 最小值） | 若无人查询过则立即生效；否则几分钟到一小时左右 |
| 修改 MX 或 TXT（SPF、DKIM、验证记录） | 该记录集原来的 TTL | 几分钟到几小时 |
| 在注册商处修改 NS 服务器 | 顶级域区域中 NS 记录的 TTL | 几小时，最长 24–48 小时 |
| 注册新域名 | 注册局发布委派记录 | 通常几分钟 |
“新记录”这一行常常让人意外。如果你或某个工具在 app.example.com 创建之前就查询过它，解析器会缓存“不存在”这个结果。这个否定应答同样会被缓存，缓存时长由区域的 SOA 记录决定，具体定义见 RFC 2308。因此，不要在创建主机名之前就去测试它。
修改解析记录与修改 NS 服务器的区别
同一区域内的记录修改
如果你只是修改记录，比如通过更新 A 记录把网站迁到新服务器，那么只涉及一层缓存和一个 TTL。如果 TTL 是 300 秒，几乎所有人都会在大约五分钟内看到新 IP。这是快速且可预测的情况，按照我们的域名解析到 VPS 教程操作时就是这种情况。
修改 NS 服务器
修改 NS 服务器会把整个区域转移到另一家 DNS 服务商。解析器是从顶级域自己的服务器得知哪些 NS 服务器具有权威性的，而大型顶级域的这些委派记录通常带有一到两天的 TTL。你无法降低这个 TTL，它由注册局设定。著名的“最长 48 小时”正是由此而来。
在这段时间内，有些解析器仍在询问旧服务商，有些已经在询问新服务商。如果两个区域的记录不一致，访客就会得到不同的结果。稳妥的做法是：先在新服务商处重建所有记录，直接查询确认无误，然后再切换 NS 服务器。如果你还在考虑是否要迁移 DNS，建议先阅读Cloudflare DNS 与注册商 DNS 对比。
如何加快 DNS 生效（实用方法）
你无法强迫别人的解析器清空缓存，但可以确保需要等待过期的缓存尽可能少。请这样规划修改：
- 提前降低 TTL — 至少在修改前一个完整的原 TTL 周期（如果原 TTL 为 1 小时，就提前几个小时），把要修改的记录设为 60–300 秒。
- 准备好目标环境 — 确保新服务器、邮箱或服务已经能正确响应，这样提前到达的流量也能被正常处理。
- 执行修改 — 更新记录。由于缓存现在只保留一到五分钟，切换几乎会立即扩散。
- 从外部验证 — 查询多个公共解析器，并直接查询权威服务器（见下一节）。
- 短期保留旧目标 — 让旧服务器至少再运行一个原 TTL 周期并留出余量，避免慢一步的访客访问到失效的 IP。
- 重新调高 TTL — 稳定之后，恢复为 3600 等较长的值，以减少查询次数并提升容灾能力。
如何检测 DNS 是否生效
先从最权威的来源开始：直接查询你的权威 NS 服务器。如果它返回了新值，你这边的工作就完成了，剩下的只是缓存问题。常用命令：
dig +short example.com A @ns1.yourprovider.com— 权威服务器的应答。dig +short example.com A @1.1.1.1以及@8.8.8.8— 两个大型公共解析器当前返回的结果。完整dig输出中显示的 TTL 会递减，归零后下一次查询就会获取新值。nslookup example.com— 在没有 dig 的 Windows 上可用。dig NS example.com +trace— 从根服务器开始跟踪委派链，适合确认顶级域层面的 NS 修改是否生效。
全球“DNS 生效检测”网站会从多个国家运行同样的查询。它们便于直观了解整体情况，但请记住，这些结果只反映少数几个解析器，并不代表所有运营商。
清除本机 DNS 缓存
很多时候，过期的结果就在你自己的电脑上。清除操作系统缓存（Windows 上运行 ipconfig /flushdns，许多 Linux 系统上运行 sudo resolvectl flush-caches，macOS 上运行 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder），重启浏览器，或者用手机流量测试以绕过家里的路由器。
示例：把网站迁移到新服务器
假设你要把网站从旧的共享主机迁移到新的 VPS，而当前 A 记录的 TTL 为 3600 秒。一个零中断的时间线可以是这样的：
- 周一上午：把 A 记录和 www 记录的 TTL 降到 300 秒。至少等待一小时，让旧的一小时缓存全部过期；稳妥起见也可以第二天再切换。
- 切换之前：把文件和数据库复制到新服务器，并通过修改本机 hosts 文件在新 IP 上测试网站。
- 切换：更新 A 记录。由于缓存最多保留五分钟，流量会在几分钟内开始流向新服务器。
- 第二天：当旧服务器日志不再出现访问记录后，关闭旧服务器，并把 TTL 调回 3600。
对于依赖数据库的网站，切换期间请短暂暂停评论、订单等写入操作；否则最后几条落在旧服务器上的数据可能永远不会同步到新服务器。如果要迁移邮件，对 MX 记录采用同样的思路，并让旧邮箱继续保留几天。
常见的 DNS 生效问题及解决方法
- 自己能访问，别人不能 — 检查权威服务器；如果结果正确，就只是在等待缓存过期。如果不正确，说明记录保存到了错误的区域或服务商。
- 48 小时后仍是旧结果 — 通常是域名实际使用的 NS 服务器与你修改记录的地方不一致。对比注册商处的 NS 记录与你修改记录的位置。
- 迁移后邮件被退回 — 切换 NS 之前没有把 MX、SPF 和 DKIM 记录复制到新区域。
- SSL 证书签发失败 — 证书颁发机构验证时访问到了旧 IP，或者被 CAA 记录阻止。等 TTL 过期后重试。
mistREG 上的 DNS 生效时间
在 mistREG 注册的域名，其 DNS 区域托管在 Cloudflare 的权威网络上，并通过 mistREG 面板管理，因此修改几乎会立即在权威服务器上生效。你可以选择 60 到 86,400 秒之间的任意 TTL，或保持“自动”，这让上面“先降低 TTL”的流程很容易执行。
记录以“仅 DNS”模式提供解析，也就是说，你填写的 IP 正是访客获得的 IP。如果你更喜欢自己的 NS 服务器，可以随时设置自定义 NS；此时域名将离开 Cloudflare 托管区域，并适用常规的 NS 生效时间。你可以在 200 多个后缀中搜索域名，查看常见问题，或通过 Telegram @mistnetwork 及面板内工单系统联系客服。服务的使用须遵守服务商条款。
