你 迁移了一个网站，在你这边一切看起来都很正常，然后消息开始不断涌入。一些访客看到了新网站，另一些仍在访问旧网站，还有少数人报告了你完全无法复现的错误。
当这种情况发生时，人们很容易责怪主机商或迁移过程本身。然而，更常见的情况是，真正的原因是 DNS（不是因为它坏了，而是因为它正在做它该做的事）。
DNS 更新不会一次性完成。它依赖于托管环境之外的缓存层和解析器，这就是为什么即使网站已经准备就绪，迁移过程仍可能让人感到不可预测。
本指南解释了 DNS 实际控制的范围，为什么传播对不同人的表现不同，以及如何规划迁移，使 DNS 成为受控的最后一步，而不是停机或混乱的根源。
DNS 实际的作用
DNS 回答一个非常具体的问题：这个域名应该指向哪里？
当有人在浏览器中输入你的域名时，DNS 将该名称转换为 IP 地址。该 IP 地址 告诉浏览器应该连接到哪台服务器。DNS 不加载页面，也不关心服务器上运行着什么。它只是处理查询。
为了确保查询可靠地工作，DNS 被分成几个独立的部分，每个部分都有明确的角色。
- 域名注册商： 你的 注册商 是购买和续费域名的地方。它不托管你的网站或控制流量。从 DNS 的角度来看，其主要职责是将域名指向正确的名称服务器。
- 权威 DNS 提供商：这是存储你的 DNS 记录 并在互联网询问你的域名应该解析到哪里时提供最终答案的服务。像 Cloudflare 或你的 托管平台 这样的提供商通常扮演这个角色。
- 名称服务器：名称服务器 告诉互联网哪个 DNS 提供商对你的域名具有权威性。它们本身不包含网站数据或配置。它们只是将 DNS 查询路由到正确的地方。
- DNS 记录（A、AAAA、CNAME）： 这些记录定义了流量去向。A 记录将域名指向 IPv4 地址，AAAA 记录指向 IPv6 地址，CNAME 记录将一个域名别名指向另一个域名。
这些记录共同决定了访客在加载你的网站时到达哪台服务器。
同样重要的是 DNS 不 做什么。DNS 不传输文件、不移动 数据库、不同步内容，也不管理 SSL 证书。它从不接触你的托管环境。
一旦这个界限清晰了，迁移过程的其余部分就变得更容易理解了。
网站迁移期间什么会改变，什么保持不变
DNS 在迁移期间造成如此多困惑的一个原因是，实际上只有一小部分设置会改变。其余部分与之前完全相同，即使网站本身可能正在迁移到全新的环境。
在典型的网站迁移期间，通常有几件事会改变。
- IP 地址 几乎总是会发生变化，因为网站现在位于不同的服务器上。这是最常见的与 DNS 相关的更新，也是最终告诉流量该去哪里的设置。
- 托管环境 也会发生变化。这包括运行您网站的服务器、基础设施和平台。虽然这会影响性能和稳定性，但它与 DNS 是分开的，并且应该在任何 DNS 更新发生之前完全准备就绪。
- 在许多情况下，特定的 DNS 记录 会发生变化。A 记录或 AAAA 记录会被更新以指向新的 IP 地址。有时会根据网站的配置方式调整 CNAME 记录。
与此同时，有几件事通常保持不变。
- 域名 不会改变。访问者仍然输入相同的 URL，面向公众的地址无需任何更新。
- 域名服务器 也保持不变，除非您有意更换 DNS 提供商。大多数迁移根本不需要更改域名服务器，即使托管提供商发生了变化也是如此。
这就是为什么 DNS 几乎总是 迁移 的最后一步。您先构建并验证新环境，然后在一切准备就绪可以接收流量时再更新 DNS。
将 DNS 视为最终开关而不是早期任务，可以减少不确定性、限制风险敞口，并使避免停机变得更加容易。
DNS 传播及其不可预测的原因
DNS 传播 并不意味着互联网正在一次性"更新"您的域名。它描述的是 DNS 更改被众多独立系统获取、缓存和重用所需的时间。
当有人访问您的网站时，他们的请求并不会每次都直接发送到您的 DNS 提供商。它通常会经过一个 递归解析器，通常由 ISP、企业网络或 Google 或 Cloudflare 等公共服务运营。该解析器向权威 DNS 提供商请求答案，然后存储结果供以后使用。
一旦解析器缓存了 DNS 响应，它就会一直使用该答案，直到缓存过期。这就是不可预测性的来源。不同的解析器将 DNS 数据缓存的时间长短不一。有些精确地遵守 TTL 值。另一些则应用自己的限制，或者比预期更长时间地重用 缓存数据。
此外，浏览器和操作系统缓存可以在本地存储 DNS 结果。即使全局 DNS 记录已更新，用户的设备也可能继续使用较旧的答案，直到本地缓存清除或过期。
这种分层缓存解释了为什么位于不同位置的两个人可以同时看到同一网站的不同版本。一个解析器拥有新的 IP 地址。另一个仍然指向旧服务器。
常见的"24-48 小时"规则过于简化了实际发生的情况。许多用户在几分钟内就能看到更新。其他人可能需要更长的时间才能看到，这取决于他们的解析器和本地缓存的行为方式。
TTL 以及它如何帮助避免停机
TTL（生存时间）控制 DNS 答案在被解析器请求新信息之前可以缓存多长时间。它不会强制更新更快发生，但会限制过时信息可以被重用的时间。
每个 DNS 记录都有自己的 TTL 值，以秒为单位。如果一条记录的 TTL 为 300，解析器可以在再次检查之前重用该答案长达五分钟。TTL 为 86,400 则允许缓存一整天。
这就是为什么在迁移之前降低 TTL 很重要。如果解析器已经保存了短期存活的 DNS 答案，那么当您更改记录时，它们会更频繁地刷新。这减少了在切换后访问者可能被发送到旧服务器的时间窗口。
对于大多数迁移来说，TTL 设置在 300 到 600 秒之间是一个比较好的平衡点。这个时间足够短，可以限制传播延迟，同时也不会给 DNS 基础设施带来不必要的负载。
设置得过低可能会引发问题。极短的 TTL 并不能保证即时更新，而且某些解析器会忽略异常小的值。其他解析器可能会对请求进行速率限制，或者干脆回退到缓存数据。在最后一刻才降低 TTL 是另一个常见错误。如果缓存中已经保存了长期有效的记录，更改 TTL 不会影响它们，直到这些缓存过期。
最安全的方法是把握好时机。在迁移前至少 24 小时降低 TTL，确认新值已生效，然后再安排 DNS 更改。
安全的 DNS 迁移时间线（分步指南）
顺利的 DNS 迁移优先考虑顺序而非速度。当每个步骤都按正确顺序执行时，DNS 就成为了一个可控的开关，而不是猜测游戏。以下是成功完成迁移的方法：
1. 准备新的托管环境
在接触 DNS 之前，先完整搭建好新站点。这包括安装依赖项、配置缓存、设置重定向以及验证性能。
使用临时 URL 或本地 hosts 文件测试站点，这样你就可以像 DNS 已经指向新服务器一样查看它。确保证书已准备就绪且有效，特别是如果启用了 HTTPS。绝不应该在 DNS 这一步才发现配置问题。
你可以在 MyKinsta 中轻松 调整 DNS 信息：进入仪表板，点击 DNS，然后点击 添加你的第一个域名。
在 MyKinsta 中管理 DNS 信息。
2. 提前降低 TTL
在迁移前尽早降低相关 DNS 记录的 TTL 值。理想情况下，应在计划切换前至少 24 小时完成。
迁移前降低 TTL 记录
更改 TTL 后，使用 DNS 查找工具确认新值已生效。这可以确保解析器在进行任何 IP 更改之前开始缓存较短生命周期的应答。
3. 冻结高风险更改
如果站点依赖单一数据库，请暂停内容编辑、电商订单和表单提交。DNS 不会移动数据，因此在迁移快照后对旧站点所做的更改可能会丢失。
大多数迁移数据问题来自重叠写入，而非 DNS 延迟。冻结更改可以消除这种风险。
4. 更新 DNS 记录
只更改需要更新的记录，通常是指向站点的 A、AAAA 或 CNAME 记录。避免在同一时间窗口内修改不相关的记录。你也可以在 MyKinsta 中调整此信息。在同一个 DNS 页面中，向下滚动到 DNS 记录，然后选择 添加 DNS 记录 以手动添加此信息。
在 MyKinsta 中手动添加 DNS 记录。
仔细检查 IP 地址、记录类型和主机名，以防止冲突。更新后，使用直接 DNS 查询验证更改，而不是仅依赖浏览器测试。
你也可以通过点击自动扫描下的 开始扫描 来对 DNS 记录进行自动扫描。
在 MyKinsta 中对 DNS 记录进行自动扫描。
5. 实时监控传播情况
从多个地区跟踪 DNS 解析，以确认流量正在到达新服务器。在推广过程中出现混合结果是正常的。
成功并不意味着每个人都立即更新。它意味着新流量始终解析到正确的目的地，没有错误或中断。
遵循此序列可保持 DNS 的可预测性。每一步都限制风险、缩小不确定性，并防止因仓促或重叠变更导致的停机。
停机通常来自何处以及如何预防
当迁移过程中发生停机时，DNS 经常受到指责。实际上，根本原因通常在别处。
DNS 问题往往是简单且二元的：记录指向正确位置，或者没有。大多数中断源于 DNS、主机托管和应用程序本身之间的差距。
- 一个常见的故障点是错误的 IP 地址。单个拼写错误或过期值会将流量发送到错误的服务器，这看起来像是停机，尽管 DNS 解析正确。
- 缺失或不完整的 DNS 记录会导致类似的症状。邮件记录、www 子域名或验证记录在变更过程中有时被忽视，导致部分中断或功能损坏。
- SSL 不匹配是另一个常见原因。DNS 可能指向新服务器，但证书尚未安装或尚未涵盖正确的域名。浏览器随后会阻止访问，用户将其体验为停机。
- 缓存也可能对你不利。缓存内容或重定向在 DNS 更新后可能仍指向旧服务器，特别是如果反向代理或 CDN 层未与新环境对齐。
防止这些问题的最可靠方法是重叠。保持旧环境和新环境同时在线、完全正常运行，直到流量明显转移。当两台服务器都能安全地处理请求时，DNS 传播的风险就会大大降低。
托管主机如何降低与 DNS 相关的风险
托管主机可以通过确保在 DNS 变更之前新环境已完全准备就绪来降低迁移风险。大多数托管平台提供暂存或临时 URL、预配置的服务器堆栈和 SSL 就绪检查，因此可以在旧站点仍为访客提供服务的同时对新站点进行端到端测试。
迁移支持也发挥着作用。经验丰富的团队会验证 DNS 记录、确认 IP 分配，并留意导致中断的常见错误配置。无需猜测问题是 DNS、SSL 还是应用程序级别的问题，而是在流程早期识别并解决问题。
Kinsta 构建迁移的方式使重叠环境成为默认设置。旧站点继续提供流量服务，同时新站点正在准备和验证。当 DNS 更新发生时，两端都准备好处理请求。
导致不必要恐慌的 DNS 误区
许多迁移压力来自听起来合理但并不准确的关于 DNS 的想法。澄清这些误区可以使当事物没有立即更新时更容易冷静地做出反应。
"DNS 变更是即时的。"
DNS 更新不会实时推送到互联网。它们是在缓存过期和解析器刷新其数据时被获取的。即使是完美配置的变更也是逐步推出的。
"如果站点宕机，DNS 就坏了。"
大多数迁移停机根本不是由 DNS 引起的。SSL 错误、服务器错误配置或应用程序问题通常表现为 DNS 故障，因为用户无法加载站点。
"清除缓存可以修复传播。"
清除浏览器缓存可能有助于单个用户看到新站点，但它不会改变解析器或 ISP 缓存的内容。传播发生在它们的时间线上，而不是你的。
"每次迁移都需要更改域名服务器。"
只有在切换 DNS 提供商时才需要更改域名服务器。大多数站点迁移根本不需要触及域名服务器就能完美运行。
如果你确实需要做出更改，可以在 MyKinsta 中通过 DNS**> 在注册商处更改域名服务器** 访问 Kinsta 域名服务器。
Kinsta 域名服务器可在 MyKinsta 的 DNS 设置中查看。
DNS 很少因为"损坏"而表现出不可预测的行为。它的行为是按照那些容易被误解的规则可预测地进行的。了解这些规则可以消除围绕迁移的大部分恐慌。
迁移后检查清单：DNS 上线后该做什么
一旦 DNS 变更生效，工作并未结束。现在的目标是确认流量持续到达新环境，并且没有任何东西在后台悄悄失效。
- 首先确认流量正在访问新服务器： 检查服务器日志、分析数据或托管仪表板，以验证请求是否正在到达正确的 IP 和环境。早期出现混合流量是正常的，但它应该完全趋向新站点。
- 验证 SSL 和重定向： 确保证书对所有预期域都有效，并且 HTTP 到 HTTPS 以及旧版重定向按预期运行。证书错误或重定向循环通常只在真实流量到达后才会出现。
- 一旦流量稳定，恢复正常的 TTL 值： 较长的 TTL 可减少 DNS 查询量并提高解析器效率。这一步经常被遗忘，但对长期稳定性很重要。
- 安全移除旧环境： 在你确信旧服务器不再接收有意义的流量之前，不要关闭它。短暂的重叠窗口可防止边缘情况故障演变为中断。
这最后一步将成功的 DNS 更新转变为干净、稳定的迁移。
迁移期间的停机通常是可以避免的
站点迁移期间的停机通常是仓促更改、职责重叠或把 DNS 当作需要在压力下"修复"的东西的结果。
最安全的迁移优先考虑准备工作而非速度。托管、应用程序配置和 SSL 首先得到验证。DNS 最后更新，并对传播和缓存有现实的预期。
有了正确的工作流程和支持，站点迁移不需要有压力或风险。当 DNS 变更发生在稳定、受管理的环境之上时，例如 Kinsta 提供的托管主机服务，停机就成为过去式。
