网站要从旧机房迁到新服务器，最担心的问题就是停机。业务一旦中断，不只是收入受损，用户的信任也会流失。迁移本身并不复杂，真正的难点在于如何让切换做到“无感”：用户访问的域名依旧生效，访客不会碰到打不开、卡顿或数据不一致的情况。本文围绕 DNS TTL（域名系统缓存刷新时间）调整与灰度切换这两个关键动作，给你一套迁移不停机的完整思路和可执行步骤。
为什么直接切换 IP 会停机：理解 DNS 缓存的延迟
要理解不停机迁移，先要弄清域名是怎么被找到的。访客输入网址时，浏览器先向 DNS（域名系统，负责把域名翻译成服务器 IP 地址）发起查询，拿到对应的 IP 之后才会建立连接。问题在于，这个查询结果会被“缓存”在运营商、地区解析服务器和用户本地等多个层级，而每条解析记录都带有一个 TTL 值，也就是允许缓存的时间。
假设你直接修改 A 记录把域名指向新服务器，改动虽然瞬间生效，但旧的解析结果还能在缓存里存活很久——通常是几小时甚至一天。对一小部分用户来说，他们仍然访问旧服务器；如果旧服务器已经下线，这部分访客就会直接看到网站打不开。这就是“一刀切切换必停机”的根本原因。
所以要实现不停机，核心思路是两层配合：第一，提前把 TTL 调低，缩短旧缓存的存活时间；第二，用灰度切换的方式，让新旧两个服务器并行运行一段时间，而不是在同一时刻彻底切换。下面分别展开这两步怎么做。如果你刚开始规划新机房，也可以先参考我们整理的服务器配置与选型指南，把新环境的基础打好。
迁移前的准备：把 TTL 调低并跑顺新环境
正式的迁移动作从降低 TTL 开始。操作上，你需要在域名解析服务商的管理后台，把你需要迁移的这条 A 记录（以及可能用到的 CNAME、MX 等在域名系统里用于邮件路由的解析记录）的 TTL 值，从默认的 3600 秒甚至 86400 秒，调低到 300 秒或更低。这里给出常见 TTL 档位与效果参考：
- 3600 秒（1 小时）：常规默认值，适合稳定不改动的情况
- 300 秒（5 分钟）：迁移前使用，绝大多数缓存一小时内会刷新
- 60 秒（1 分钟）：适合临近切换窗口，收敛速度最快
需要注意，TTL 调低并不会让所有缓存立刻失效，它只影响“生效之后新产生的缓存”。所以正确做法是：至少提前一个完整的 TTL 周期（建议 24 小时以上）把 TTL 调低，让全网缓存逐步刷新，再进入切换阶段。与此同时，新服务器要并行完成环境搭建，包括同样的 Web 服务、数据库、PHP 或 Java 运行时与应用文件，并用只读方式导入一份数据快照做验证。你可以把新服务器放在内网或通过 hosts 临时绑定域名来测试，确认前台页面、后台登录和关键接口都正常，再谈切换。
灰度切换：让新旧两站并行运行逐步放量
环境就绪、TTL 已调低之后，进入灰度切换。这一步的核心是“不一次性改死”，而是让新服务器先承接一部分流量，观察稳定后再扩大。常见的实现方式有三种，你可以按团队能力选择：
- 低流量分片：把解析记录同时指向新旧两个 IP，权重先设为 1:9 或 2:8，让少量流量先到新服务器验证
- 负载均衡引流：如果新老都在同一套负载均衡器后面，直接调整后端服务器权重，从 0 逐步加到 100
- 按区域灰度：在支持 GeoDNS 或分线路解析的服务商上，先只把某一地区的流量切到新节点，其余地区保持旧节点
无论用哪种方式，灰度阶段的时长通常建议拉到几小时到一天。这段时间里要重点观察新服务器的错误日志、CPU 与内存占用、数据库连接数以及首页响应时间（TTFB，即从发出请求到收到首个字节的时间）。如果发现异常，由于旧服务器仍在运行，可以直接把权重调回，风险集中在最早的一小部分流量上。新机如果偏重 WordPress 站点，切换前后也建议顺带做一次网站性能与 TTFB 优化，把提速效果一并落地。对于承载较高流量或数据库的站点，也可评估WordPress 主机调优相关文章里的缓存与数据库设置，避免迁移后出现性能回退。
正式切换与回滚：验证通过后再放量
灰度期间一切稳定后，才把权重逐步调到 100%，让全部流量进入新服务器。这里有两个常见误区值得提醒：一是切换后立刻关闭旧服务器——正确做法是保留旧环境至少 1 到 3 天，作为随时回滚的退路；二是忽略邮件记录的迁移，如果站点使用自己的域名邮箱，必须同步迁移 MX 记录并在新服务器上完成邮件数据同步，否则迁移完成后会发现邮件收发异常。
切换之后的验证不能只看首页。建议你检查这几类关键项：用户能正常登录并提交订单或留言（写操作是否落库）、静态资源（图片、CSS、JS）能否正常加载、后台管理面板能否打开、支付或第三方接口回调是否连通。每项都建议用两个角度确认：真实浏览器访问新域名的结果，以及直接通过新服务器 IP 加 hosts 绑定的结果，避免被 CDN（内容分发网络，用于缓存和加速静态资源）或本地缓存干扰判断。
一旦发现严重问题需要回滚，因为 TTL 已经处于低位，把解析记录切回旧服务器 IP 后，全网通常在几小时内就能收敛，不需要等待漫长的旧缓存过期。这也是为什么“迁移前调低 TTL”这件事必须放在最前面——它既加快灰度放量，也加快回滚速度。
总结与行动建议
迁移不停机不是一个运气问题，而是一套可以提前规划的操作流程。把 TTL 提前调低 + 新旧并行 + 权重灰度 + 保留回滚窗口，四件事按顺序做完，绝大多数网站都能在用户无感的情况下完成机房或服务器切换。
如果你手头正好有迁移任务，建议按下面的清单走：先备份全站与数据库并校验可用，提前 24 小时调低 TTL，搭建并测试新环境，灰度比例从低到高逐步放量，放满后保留旧环境三天再回收。对于数据量大或需要全程同步的场景，可以考虑先把数据库迁移到独立的云服务器（指按需分配计算资源的云端主机）或托管数据库，降低应用层迁移的复杂度；若站点访客集中在特定国家或地区，先评估该地区解析与线路的稳定性，再决定是否在切换后引入 CDN 加速。迁移过程中的数据一致性校验，也可以参考我们关于WordPress 数据与插件迁移要点这篇文章的细节。如果需要稳定的迁移目标环境，可以参考我们关于 Hostease 的 VPS（虚拟专用服务器）与独立服务器选型介绍，结合预算和连接数规划新机配置。