您更新了一条 A 记录。您的新服务器正在运行。您导航到您的域，但仍然看到旧网站。或者其他国家/地区的某人可以看到新网站，但您却看不到。或者这两种情况对于不同的用户同时发生。

这是 DNS 传播。这不是错误，也不是您的注册商速度慢。这就是正在发生的事情以及如何管理它。

什么是 DNS 传播？

DNS（域名系统）是一个全球分布的数据库，将域名映射到 IP 地址。它不是一个单一的服务器——它是一个由数千个解析器组成的层次结构，每个解析器都会缓存一段时间的答案。

当您更新 DNS 记录时，您正在更改您的 DNS 记录上的数据 权威域名服务器 — 您的注册商或 DNS 提供商控制的。但互联网的其余部分不会直接查询您的权威服务器。他们问他们的 本地递归解析器 （通常由其 ISP 或公共 DNS 服务运行，例如 1.1.1.1 或 8.8.8.8），它有自己的记录缓存副本。

传播是缓存副本过期并被新记录替换的过程。

完整的 DNS 解析器链

理解 为什么 传播需要时间，需要了解 DNS 查询的实际工作原理：

DNS 解析器链图显示查询如何从设备通过 ISP 解析器、根服务器、TLD 服务器传输到权威域名服务器
完整的 DNS 查找链。步骤 2-4 通常会被跳过，因为递归解析器已经缓存了答案 - 这正是传播需要时间的原因。

步骤 1 — 您的浏览器检查其本地缓存。 现代浏览器独立于操作系统缓存 DNS 结果。 Chrome 缓存 60 秒； Firefox 最多可达 TTL 值。 chrome://net-internals/#dns 显示Chrome当前的缓存。

步骤 2 — 您的操作系统存根解析器检查其缓存。 Windows、macOS 和 Linux 都维护本地 DNS 缓存（用 ipconfig /flushdns, dscacheutil -flushcache, 或 resolvectl flush-caches ）。

步骤 3 — 查询您的递归解析器。 这通常是您的 ISP 的解析器， 1.1.1.1, 8.8.8.8，或企业 DNS 服务器。它有自己的缓存，与您的缓存分开，并在所有用户之间共享。如果 10,000 人使用同一个 ISP 解析器，则一个缓存的答案可以为所有人提供服务。

步骤 4 — 递归解析器遍历层次结构 （如果其缓存为空）。它向根域名服务器请求 TLD，向 TLD 服务器请求权威域名服务器，然后向权威服务器请求您的记录。它会使用您指定的 TTL 缓存答案。

传播很慢，因为： 步骤 4 仅在解析器的缓存过期时运行。在那之前，它会提供旧的缓存答案 - 无论您在权威服务器上更改了什么。

TTL：控制一切的数字

TTL（生存时间）是您在每个 DNS 记录上设置的值，以秒为单位。它告诉解析器在重新查询权威服务器之前将您的记录缓存多长时间。

常用TTL值：

TTL 秒 典型用途
1分钟 60 主动迁移、测试
5分钟 300 预迁移（设置24小时前）
15分钟 900 经常更改的记录
1小时 3600 大多数记录的标准
4小时 14400 稳定记录
24小时 86400 许多提供商的默认值
48小时 172800 名称服务器 (NS) 记录

您设置的TTL决定了 最大 传播窗口。但有一个问题。

图表显示 DNS 传播时间与 TTL 值以及最佳、典型和最坏情况的情况
最好的情况反映了完全尊重 TTL 的解析器。最坏的情况：一些 ISP 解析器缓存远远超出声明的 TTL，特别是对于短 TTL，将 5 分钟以下的任何内容视为“5 分钟”以减少负载。

关于 TTL 的肮脏秘密： 许多 ISP 忽略低 TTL 值。为数百万用户提供服务的解析器无法承受每 60 秒重新查询一次高流量域的费用。无论您声明什么，有些都会强制执行 5 分钟的最短缓存时间。这意味着对于部分解析器来说，非常低的 TTL（60-300 秒）在实践中更像是 5 分钟的 TTL。

24 小时 TTL 意味着某些用户可能会在您进行更改后的整整 24 小时内看到您的旧记录 - 即使您在上一次 TTL 到期后立即进行了更改。

DNS 传播实际需要多长时间？

甘特式时间线图显示 DNS 记录更改后 DNS 传播到世界不同区域
1 小时 TTL 记录的区域传播时间线。 Local resolvers update fastest; outlier ISPs that ignore TTL can lag by hours.这解释了为什么有些用户看到您的新网站，而另一些用户看到旧网站。

对于标准 1 小时 TTL，您可以期待以下结果：

  • 您的本地设备： 刷新缓存后几乎立即完成
  • 同城解析器： 5–30 分钟（解析器在缓存过期时进行权威查询）
  • 主要公共 DNS（8.8.8.8、1.1.1.1）： 通常 10–60 分钟
  • 全球传播： 1–4 小时
  • 速度慢/异常的 ISP： 长达 8-12 小时

你随处可见的“长达 48 小时”的数字在技术上是可行的，但对于具有正常 TTL 的 A 和 CNAME 记录来说越来越罕见。对于 NS（名称服务器）记录更改来说更准确，NS（名称服务器）记录更改具有更长的固有 TTL，并通过根/TLD 层传播。

为什么具体是48小时？ NS 记录的 TTL 通常由注册表（而不是您）设置，通常为 24-48 小时。当您在注册商处更改域名服务器时，您将等待 TLD 注册机构更新，并且该更新会通过全球根服务器传播。此路径比固定名称服务器内的简单记录更改需要更长的时间。

专业方法：预先降低 TTL

人们在 DNS 迁移中犯的最大错误：更改记录而不首先降低 TTL。

计划迁移的正确流程：

  1. 迁移前48小时： 将您计划更改的所有记录的 TTL 降低至 300 秒（5 分钟）
  2. 等待完整的当前 TTL （给解析器时间来获取新的短 TTL）
  3. 更改您的记录 — 传播现在最多需要 5 分钟而不是 24 小时
  4. 迁移稳定后： 将 TTL 提高到 3600 或更高

这是 5 分钟传播窗口和 24 小时传播窗口之间的差异。每个 DNS 专业人员都会这样做。大多数初学者都是通过艰难的方式学习的。

如何立即检查 DNS 传播

最快的方法：使用我们的 DNS 传播检查器 — 它同时从多个地理位置查询您的域，并显示每个区域是否返回您的旧记录或新记录。

您要找的是：

  • 绿色/匹配IP： 这些地区看到您的新记录
  • 旧IP仍然显示： 这些解析器的缓存尚未过期
  • 混合结果： 传播过程中正常 — 有些区域看到新的，有些区域看到旧的

通过命令行检查 如果你想直接验证权威答案（绕过任何缓存）：

命令 
# Query a specific DNS server directly (bypasses your local cache)
nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1

# On Linux/macOS — dig gives more detail
dig example.com @8.8.8.8
dig example.com @1.1.1.1

# Check the TTL of your current record
dig example.com | grep -i ttl

# Query the authoritative nameserver directly (no cache)
dig example.com @ns1.yourprovider.com

如果 dig @ns1.yourprovider.com 显示您的新记录，但是 dig @8.8.8.8 仍然显示旧的，您的更改是正确的 - 您只是在等待递归解析器的缓存过期。

刷新本地 DNS 缓存 停止在您自己的计算机上看到过时的数据：

命令 
# Windows
ipconfig /flushdns

# macOS (Sequoia / Sonoma)
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Chrome browser cache only
# Navigate to: chrome://net-internals/#dns → click "Clear host cache"

注意：如果您的 ISP 解析器仍然缓存了旧答案，则刷新本地缓存并没有帮助。您的设备只会重新查询 ISP 的解析器并再次获得过时的答案。

常见 DNS 传播场景

场景一：网站迁移到新服务器

您将从旧主机→新主机。旧A记录： 203.0.113.10。新： 198.51.100.20.

传播过程中会发生什么： 拥有缓存旧记录的用户登陆旧服务器。解析器已刷新的用户会看到新服务器。两台服务器都需要运行并提供相同的内容，直到传播完成。如果过早关闭旧服务器，缓存陈旧的用户会收到错误。

缓解措施： 更改后，使旧服务器保持至少一个完整的 TTL 活动状态。如果原始 TTL 为 24 小时，请在更改后保持旧服务器 24 小时运行。

场景 2：电子邮件提供商迁移（MX 记录）

MX 记录更改会影响入站电子邮件的递送位置。传播期间发送的电子邮件可能会落在旧邮件服务器或新邮件服务器上，具体取决于发送服务器解析的 MX 记录。

风险： 电子邮件在您停止监控旧服务器后发送到旧服务器。 修复： 配置旧邮件服务器在迁移后一周内转发到新邮件服务器，或在 TTL 窗口期间保持旧邮箱可访问。

场景3：CDN或负载均衡器割接（CNAME更改）

指向 CDN 或负载均衡器的 CNAME 记录通常比 A 记录传播得更快 — CNAME 本身会缓存，但 CDN 返回的底层 IP 可以快速更改，而不会影响记录的传播。

注意： CNAME 扁平化。某些 DNS 提供商会在区域顶端“扁平化”CNAME 记录（将 CNAME 替换为其解析为的 A 记录）。如果提供商缓存了扁平化 IP，则可能会在迁移期间导致意外行为。

场景 4：名称服务器（NS 记录）更改

最慢的传播类型。 Nameserver records are stored at the TLD registry level (.com, .net等），TTL 由注册表设置，通常为 24-48 小时。您无法控制此 TTL。

当您在注册商处更改域名服务器时：

  1. 您的注册商通知 TLD 注册管理机构
  2. Registry updates the delegation
  3. 注册管理机构的更新在全球根名称服务器上传播

预计完全传播需要 12-48 小时。没有任何 TTL 预降低技巧可以提供帮助。

故障排除清单

✅ 如果您的 DNS 更改没有传播

1. 确认新记录在<strong>权威服务器</strong>上正确无误：<code>dig example.com @ns1.yourprovider.com</code><br> 2. 检查多个公共解析器看到的内容：<a href="/dns-propagation.php">DNS 传播工具 →</a><br> 3. 刷新本地缓存（上面的命令） - 您可能只是看到自己的旧记录缓存<br> 4. 检查您的 TTL：<code>dig example.com | grep TTL</code> — 如果是 86400，您将等待 24 小时<br> 5. 如果权威显示正确，但解析器不正确：等待 TTL 到期 — 无其他可做<br> 6. 如果权威显示错误记录：您在错误的提供商处进行了更改，或者尚未保存

DNS 传播与 DNS 复制：区别

这些经常被混淆。它们相关但又不同：

DNS 传播 = 等待递归解析器缓存过期并重新查询。这是您作为用户所经历的延迟。你不能强迫它。只能通过预先降低TTL来减少它。

DNS 复制 = 在同一区域的多个权威名称服务器之间同步（例如， ns1.provider.com 和 ns2.provider.com）。大多数 DNS 提供商会在几秒钟内完成复制。如果您进行了更改，但在 5 分钟内未在提供商自己的名称服务器上显示，则这是提供商方面的问题 - 请联系支持人员。

工具