VPS迁移或快照恢复后IP会不会变？公网地址、DNS与回滚验收清单

VPS迁移或快照恢复后，最容易被忽略的是“机器恢复了，但网络身份变了”。系统盘、应用文件和数据库可能已经回到某个时间点，公网IPv4、IPv6、反向DNS、域名解析和API白名单却仍指向旧环境。若没有提前记录，业务会表现为域名打不开、白名单拒绝或回调发往错误节点。

判断IP是否变化，不能只看控制台的一行地址。需要把实例网卡、可保留的公网资源、DNS记录和应用配置分开验收，并为不可避免的地址变化准备回滚方案。

先分清四类网络对象

对象	变化可能来自哪里	迁移时要记录什么
实例临时公网IP	关机释放、重建实例、迁移到新资源	旧值、绑定条件和释放规则
弹性或保留公网IP	解绑、跨区域限制、欠费或资源回收	资源ID、绑定实例和转移条件
IPv6地址或前缀	网卡重建、前缀重新分配、路由变化	地址族、前缀、路由与防火墙规则
DNS与反向DNS	TTL、解析商同步、主机名映射	记录类型、TTL、变更时间和验证方式

快照通常描述磁盘或实例状态，不应自动理解为“公网IP资源快照”。是否保留地址，必须以云平台当前产品规则和工单确认结果为准。

迁移前：先做一份网络身份清单

1. 记录IPv4、IPv6、默认路由、反向DNS和安全组规则。
2. 列出依赖固定来源地址的API白名单、数据库授权和远程管理入口。
3. 保存域名A、AAAA、CNAME和健康检查配置，以及当前TTL。
4. 标记哪些配置写在系统盘，哪些由云控制台或外部DNS管理。
5. 准备新旧节点的验证脚本或只读健康检查，不把真实密钥写进脚本仓库。

如果使用的是可单独绑定的公网资源，应确认迁移目标区域、实例类型和网络产品是否支持转移。若不支持，提前申请新地址并安排白名单变更，不要等旧实例已经下线才处理。

迁移后按五个层次验收

1. 实例层：地址是否真的绑定

从控制台和系统内分别读取网卡、路由和地址族。控制台显示的地址不一定已经写入系统，系统看到的地址也不代表服务端可达；两边都要留时间戳。

2. 出口层：外部服务看到谁

通过自有或获授权的回显服务确认IPv4与IPv6出口。若只查看本机网卡，会漏掉NAT、网关或地址族优先级带来的差异。

3. 解析层：域名是否指向正确节点

分别查询A、AAAA和CNAME，等待TTL允许的传播窗口后，再从目标网络发起TLS和健康检查。不要只在本机缓存未刷新时下结论。

4. 授权层：白名单与回调是否更新

把新出口加入自有服务或已授权API的白名单，完成最小请求验证，再移除旧地址。对回调服务，还要检查对方记录的是域名、IPv4还是IPv6。

5. 应用层：数据恢复是否可用

验证数据库连接、后台任务、对象存储、邮件回调和日志写入。快照恢复成功只说明磁盘状态已回到某个时间点，不代表外部依赖的网络身份或凭据同步完成。

DNS变更与IP切换如何安排

如果域名必须指向新IP，先确认新节点健康，再修改A/AAAA记录。对能并行运行的服务，可以短时保留旧记录并使用健康检查；对不支持并行的服务，应在维护窗口内完成授权更新、解析变更和应用验证。TTL只能影响缓存时间，不能替代健康检查。

若IP资源可以原地解绑再绑定，优先采用“先确认资源可转移，再切换实例”的方式。若只能重新申请地址，则将DNS、白名单、监控和文档变更放进同一变更单，确保每一步都有责任人和回滚条件。

回滚清单：恢复旧系统不等于恢复旧网络

• 旧实例或快照是否仍可启动，数据是否在可接受的时间点。
• 旧公网IP或弹性资源是否还保留，是否已经被重新分配。
• DNS记录、白名单和监控告警能否恢复到上一版本。
• 回滚后数据库是否会产生双写、重复任务或消息积压。
• 回滚验证由谁执行，何时宣布恢复完成。

如果旧IP已经释放，回滚只能恢复应用和数据，不能承诺恢复原来的网络身份。此时应把新IP作为正式变更处理，更新白名单和运维文档。

常见误区

误区	实际风险	正确做法
快照恢复就会保留公网IP	新实例获得新地址，白名单拒绝	把磁盘恢复与公网资源恢复分开验收
控制台地址没变就一切正常	IPv6、DNS或出口路径仍不一致	同时看网卡、外部回显与目标服务日志
改完DNS立刻宣布迁移完成	缓存、TLS和健康检查尚未收敛	按TTL和业务验证窗口观察
回滚只恢复系统盘	外部依赖仍指向新节点	把IP、解析、白名单和数据一起回滚

结语

VPS迁移后的IP是否变化，取决于公网资源绑定、实例重建和平台回收规则，不能从快照名称推断。极跃圈建议把“磁盘恢复”和“网络身份恢复”拆成两张验收表：先确认公网IPv4/IPv6和DNS，再验证白名单、回调与业务数据，最后才关闭旧节点。