VPS 机房怎么选：延迟、路由、吞吐与迁移成本
VPS 机房应按主要用户和上游服务的真实请求表现选择，不按管理者所在地、国家名称或一次 ping 排名。 先建立少量候选节点，再用同一来源、时段和方法测试，才能得到可比较的结论。
原文记录的是早期 Linode 工单迁移流程和固定耗时估算，已经删除。当前迁移、克隆、换机和 IP 变化取决于具体产品、实例状态与确认页，不能把历史流程当作统一承诺。
第一步：画出业务访问路径
先列出真正会访问服务器的对象：
- 主要用户所在国家、城市与运营商
- 管理人员的远程入口
- 数据库、对象存储、模型或支付 API
- 监控、备份和日志接收端
- 容灾或替代节点
如果主要用户在日本，而管理者在中国，前台请求应优先于管理者 SSH 体验。若服务器频繁调用美国 API，则还要单独测试节点到该 API 的链路。
第二步：建立少量候选节点
从当前机房列表按用户地区筛选，再查看测试地址、最低配置和产品线。候选通常不需要覆盖所有城市，先保留业务上说得通的几个节点。
地区指南可以继续缩小范围：
同一城市的不同产品线也要分开测试。城市相同，不代表上游、套餐、操作能力和计费规则相同。
第三步：按同一方法测试
为每个候选节点记录以下指标：
| 指标 | 回答的问题 | 工具或方法 |
|---|---|---|
| DNS、TCP、TLS 与首字节 | 用户完成一次真实请求需要多久 | curl 计时或应用监控 |
| 往返延迟与波动 | 交互是否稳定 | 持续 ping，记录平均值和高分位 |
| 路径与持续丢包 | 问题可能出现在哪一段 | 双向 MTR 报告 |
| 正向与反向吞吐 | 两台自有主机之间的传输能力 | iPerf3 |
| 高峰与低峰差异 | 是否存在时段性拥塞 | 固定来源分时段重复测试 |
不要给所有业务套用一个固定延迟阈值。远程桌面、游戏、批处理、静态网站和异步队列对延迟的敏感度不同，应以真实请求是否满足目标为准。
一份可复核的测试表
建议为每个候选节点保存一行：
| 字段 | 示例写法 |
|---|---|
| 候选节点 | 产品线 + 城市 + 机房名称 |
| 来源 | 城市 + 运营商 + 固定监测点 |
| 时段 | 日期、时间和时区 |
| 真实请求 | 成功率、平均值、P95 与错误码 |
| 网络 | ping、MTR、iPerf3 原始结果链接 |
| 资源 | CPU、内存、磁盘、流量和系统 |
| 成本 | Linux/Windows 价格、首期与续费口径 |
| 结论 | 适合场景、已知限制和替代节点 |
同一套测试重复几次后，差异才具有决策价值。只保留“感觉快”或一张截图，后续无法判断网络是否变化。
价格与配置不能脱离网络判断
最低价节点可能对应更小内存、磁盘或不同区域定价。先从产品价格核对套餐与计费，再把满足资源条件的节点放进网络测试。
Windows 还可能有系统附加价，首期不足整月时也可能按日价计算。页面价格是目录快照，最终库存、系统与应付金额以控制台结算页为准。
把迁移成本纳入选择
上线前就准备迁移，而不是出现问题后才研究：
- 数据保留在服务器之外的异地备份。
- DNS TTL 和回退记录已有文档。
- 新节点可以并行验证，不覆盖唯一生产副本。
- 数据库写入切换有明确顺序。
- IP 变化、停机窗口和第三方白名单已评估。
- 旧实例只在新节点验证完成后处理。
iVPSer 控制台中的迁移、克隆、换机或恢复能力按产品与实例实际开放。操作前先看确认页，并自行备份；不要依据旧教程假设 IP、备份或停机时间一定如何变化。
最终选择规则
先淘汰不满足系统、资源和预算的节点，再比较主要用户的真实请求表现。结果接近时，优先选择备份、监控和迁移方案更清楚的候选，而不是继续追逐一次测试中的最高数字。
仍无法判断时，可以先用非生产工作负载验证，并保留第二候选。机房选择不是一次性结论，应在用户分布、上游服务或路由明显变化后重新测试。