# 迁移机房：准备、执行与恢复访问

先在当前实例后台确认允许迁往哪些机房。迁移可能改变 IP、路由、流量规则和应用访问地址，不能仅把它理解成换一个城市名称。

更新日期：2026-09-16

规范地址：https://stock.iftalking.com/guides/migrate-datacenter/

## 迁移前先确认三件事

第一，当前套餐是否允许迁移到目标机房；第二，业务是否能接受中断和 IP 变化；第三，数据是否已有服务器之外的备份。迁移功能与新购库存不是同一个入口，能否迁入以当前实例的选项为准。

不要照搬历史套餐的迁移清单、费用或流量比例。特别是限量方案、已更名机房和跨系列套餐，条件可能不同。

## 1. 记录原地址与受影响的配置

在 KiwiVM 保存当前 IP、机房、系统和用量。整理所有依赖 IP 的地方：域名 A/AAAA 记录、应用监听地址、防火墙、数据库白名单、第三方回调白名单、监控和本地 SSH 配置。

对网站，先备份文件和数据库；对持续写入的应用，安排停止写入或一致性备份。若准备调整 DNS TTL，应提前进行，并理解旧缓存仍会保留到原 TTL 到期。

## 2. 打开 Migrate to another DC

进入对应 VPS 的 KiwiVM，在迁移菜单找 **Migrate to another DC** 或当前的数据中心迁移入口。先核对 Current Location，再阅读目标列表和说明。

![KiwiVM 左侧 Migration 区域中的机房迁移入口](https://stock.iftalking.com/tutorial-media/provider-kiwivm-overview.jpg)

*图示说明：服务商官方知识库公开截图（旧版界面），用于对照功能名称；当前菜单位置可能调整。图中的套餐、IP、端口和日期仅为示例。*

选中目标后，检查 IP 是否变化、可用流量如何计算、预计处理方式和停机提示。页面出现下一步确认时，先把这些信息看完，再继续。单击选择机房与最终启动迁移是两个阶段。

## 3. 提交前完成最后核对

- 当前服务 ID 与要迁移的服务器一致。
- 目标机房名称准确，不是名称相似的其他节点。
- 最新备份能从服务器之外取得。
- 已准备好更新 DNS、监控及白名单。
- 没有同时执行重装、快照恢复或其他迁移任务。

确认后提交一次，查看任务进度。总耗时受数据量、文件数量和平台状态影响，不按旧文章中的几分钟做固定承诺。SSH 暂时中断时，先查看任务状态，避免重复提交。

## 4. 迁移完成后先用 IP 验证

回 Main Controls 记录新 IP、机房、运行状态和流量信息。使用新 IP 与实际 SSH 端口连接，核对文件、应用进程和数据库，再更新对外 DNS。

网站可以在本机用指定新 IP 的方式检查 HTTPS 服务，避免等待 DNS 缓存期间误判：

```sh
# 将 example.com 与 203.0.113.10 换成自己的域名和新 IP
curl --resolve example.com:443:203.0.113.10 -I https://example.com/
```

这个命令仍使用域名进行 TLS 校验，不需要关闭证书验证。若请求失败，先查应用监听地址和证书配置，再发布 DNS 变更。

## 5. 遇到迁移失败怎样处理

| 提示或现象 | 处理方向 |
| --- | --- |
| Region is full | 目标暂不可用，稍后再查或选择其他允许的机房 |
| Migration backend is not available | 记录编号和任务状态，必要时联系支持 |
| 找不到目标地区 | 核对套餐权限，不能靠旧直达地址获得权限 |
| 任务完成但网站打不开 | 查新 IP、监听地址、DNS 和白名单 |

不要运行高频循环脚本反复申请迁移。处理完成后按[迁移后的检查清单](https://stock.iftalking.com/guides/after-migration/)逐项验证，确认新机房表现符合预期。


## 完成后检查

保留旧配置与异地备份直到验证完成。是否保留数据、是否计入传输量，以本次迁移页面规则为准。

## 参考资料

- [官方网络连接排障](https://bandwagonhost.com/kb.php?action=displayarticle&id=26)
- [服务商官方说明](https://bandwagonhost.com/kb.php?action=displayarticle&id=30)