机房搬迁不是把服务器从A机房拉到B机房那么简单，真正决定业务恢复速度的往往是DNS重新指向的时机和方式。DNS作为域名到IP的映射系统，天然存在各级缓存，如果直接修改解析记录而不提前调整TTL，可能出现部分地区用户仍访问旧机房、新建机房却长时间无流量的情况。要平稳完成切换，需要从缓存控制、切换步骤、验证手段和回退预案四个方面做好设计。
搬迁前先理解TTL与缓存机制
DNS解析结果并不会每次都回到权威服务器查询，它会在本地递归解析器、运营商缓存、用户操作系统和浏览器层被缓存。TTL就是这条缓存的有效期，单位通常为秒。比如一条A记录的TTL为86400秒，意味着本地递归解析器拿到结果后可以缓存24小时，这段时间内即使权威服务器上的记录已经改变，解析器也可能继续返回旧IP。
如果搬迁当天直接把域名A记录从旧机房IP改成新机房IP，而旧记录的TTL还是86400秒，那么已经缓存了旧解析结果的用户最长可能需要24小时才会访问到新机房。这期间新旧机房同时存在流量，如果数据库或文件存储没有做好同步，很容易产生数据不一致。判断当前TTL可以使用dig命令，示例输出中第二列的300就表示剩余缓存时间为300秒。
dig +noall +answer ipipp.com ;; ANSWER SECTION: ipipp.com. 300 IN A 203.0.113.10
降低TTL的操作必须在正式切换前完成。如果原TTL是86400秒，那么最好提前至少24小时把TTL调整到300秒或60秒。这样等到真正修改A记录时，所有递归解析器里残留的旧记录最多只有5分钟或1分钟。提前时间不够会导致部分解析器仍按旧TTL缓存，切换后依旧可能出现长时间访问旧IP的问题。
切换方案设计：并行解析与灰度切换
最简单的切换方式是直接修改A记录，但风险最大，不推荐用于核心业务。更稳妥的做法是提前在新机房部署好完整服务，使用新IP进行内网验证，确认应用、数据库连接、证书、定时任务都正常后，再修改公网解析。如果条件允许，可以保留旧机房入口一段时间，让新旧IP并行存在。
对于没有负载均衡设备的场景，可以在DNS层同时配置两条A记录，一条指向旧机房，一条指向新机房。DNS轮询会把请求分散到两个IP，但这种方式无法精确控制流量比例，而且客户端可能缓存其中一个IP，导致部分用户始终访问旧机房。更好的方案是使用智能DNS或云解析的权重控制功能，先将10%的流量切到新机房，观察错误率和日志后逐步提升比例。
切换窗口建议选择业务低峰期，并提前通知相关团队。修改前要记录旧IP、新IP、原TTL、操作时间和操作人。测试阶段可以先使用一个不对外提供服务的子域名验证链路，例如把test.ipipp.com解析到新机房IP，确认从公网可以正常访问后再操作主域名。以下是一个修改后的BIND区域文件示例，TTL已经被调整为300秒。
$TTL 300
@ IN SOA ns1.ipipp.com. admin.ipipp.com. (
2025010101 ; serial
3600 ; refresh
900 ; retry
604800 ; expire
300 ) ; minimum
IN NS ns1.ipipp.com.
www IN A 203.0.113.20执行切换与多节点验证
正式切换时把主域名的A记录修改为新机房入口IP，确认当前TTL已经是低值。修改完成后不要只看域名注册商或DNS服务商控制台的生效提示，因为那只能说明权威服务器已经更新，并不代表所有递归解析器都拿到了新结果。需要从多个公共DNS服务器发起查询，观察返回的IP是否已经变成新地址。
dig @8.8.8.8 ipipp.com +short dig @1.1.1.1 ipipp.com +short nslookup ipipp.com 223.5.5.5
不同公共DNS服务器的缓存状态可能不一致，这是正常现象。如果某个解析器仍然返回旧IP，可以稍等几分钟后再次查询。要验证本机是否已经丢弃旧缓存，可以在Windows上执行ipconfig /flushdns，在Linux系统上使用systemd-resolve --flush-caches。需要注意的是，清空本机缓存只影响当前这台机器，不会影响运营商递归解析器。
ipconfig /flushdns sudo systemd-resolve --flush-caches
解析结果验证通过后，还要从业务层面确认流量是否真正进入新机房。可以在新服务器上查看访问日志中的来源IP和请求域名，同时观察旧服务器的连接数是否逐步下降。使用curl指定域名访问并检查响应头，也能帮助判断当前命中的是哪个机房。若业务使用HTTPS，还要确保证书在新机房已经正确配置，避免出现证书不匹配导致连接失败。
常见故障排查与回退预案
切换过程中最常见的故障是防火墙或安全组未放行新机房的公网入口。很多搬迁项目在测试内网时一切正常，但公网用户始终无法访问，原因往往是新机房的安全组只允许内网网段，没有放行0.0.0.0/0或指定的公网网段。另一个常见问题是数据库同步没有完成，新机房的应用虽然能启动，但读到的数据落后于旧机房，或者写入后无法同步回旧机房。
如果新机房出现严重故障，需要把A记录改回旧IP。由于TTL已经降低，回退生效时间会明显缩短。但回退前必须确认旧机房的服务和数据库仍然可用，不能已经把数据库主库切到新机房后再盲目回退，否则会造成数据丢失或写入冲突。建议在搬迁期间保留旧机房完整运行，直到新机房稳定观察至少24到48小时后再下线。
切换完成后要持续监控新旧机房的流量变化、应用错误率、数据库延迟和证书到期时间。只有确认旧机房已经没有任何业务流量，且新机房各项指标平稳，才能逐步关闭旧机房资源。DNS重新指向不是一次简单的记录修改，而是一套包含提前准备、灰度验证、多节点检查和回退策略的完整流程。