香港VPS怎么搬家

一、迁移前先想清楚：你要迁的是什么

大部分迁移事故不是技术问题，是「没想清楚要迁什么」导致的。 动土之前，先把这张清单填满。

第一类：必须迁走的。 数据库数据、网站文件与配置（上传的图片、附件、配置文件）、SSL 证书、域名 DNS 记录、定时任务与 crontab、环境变量与密钥、第三方服务的白名单 IP。

第二类：不用迁走的。 系统本身（重装更快更干净）、运行时缓存（Node 的 node_modules、Python 的 venv、编译产物）、日志（除非有审计要求）、已经没用的旧文件。

第三类：最容易漏掉的。 这几项是迁移后才发现缺的东西，几乎每个人都会踩一次：

容易漏的项	漏掉后的表现	迁移时怎么确认
邮件服务器配置（SPF/DKIM/DMARC）	发信进垃圾箱或被拒收	检查 DNS 的 TXT 记录是否跟着迁
第三方 API 的 IP 白名单	所有回调失败	提前把新 IP 加进白名单
对象存储 / CDN 的回源配置	图片 404	检查回源地址是否指向新 IP
支付回调、OAuth 回调地址	支付成功但订单不发货	检查应用后台的回调 URL
定时任务的执行身份	任务静默失败	用 root 和实际用户各跑一次
数据库的存储过程、事件、触发器	报表为空、定时任务不执行	`mysqldump --routines --triggers --events`

数脉科技官网机型与实时报价

第四类：迁移前必须确认的两件事。

第一，你的新机器配置是否真的够。 不能凭「旧机器跑了三年没问题」来判断——旧机器上的实际用量才是依据。 按渠道库快照（2026-11-11 16:30）的真实价格，香港方向起步档是云途 HK.DS.M，350 元人民币每月、32 GB 内存、480 GB 硬盘 SSD、1000 Mbps 端口、10000 GB 月流量、CPU 标注 E5-2630 V2 × 1；往上 DS.ES.C 是 700 元每月、64 GB 内存、800 GB 硬盘 SSD、2000 Mbps 端口、40000 GB 月流量。 换算成单位成本：HK.DS.M 每 GB 内存 10.94 元、每 GB 硬盘 0.729 元、每 TB 流量 35.84 元；DS.ES.C 每 GB 内存 10.94 元、每 GB 硬盘 0.875 元、每 TB 流量 17.92 元。 DS.ES.C 的每 GB 内存单价与 HK.DS.M 完全相同但容量翻倍、流量翻四倍、每 TB 流量单价减半——如果你只是「换一家商家」而不是降配，同样的预算在新商家能拿到更大的机器，这本身就是迁移的收益之一。

第二，你的域名 DNS 能不能改。 这一条决定停机时间。 如果你的域名 NS 指向的是自己控制的一台 DNS 服务器，那改一条 A 记录就能切换；如果 NS 指向的是不可编辑的第三方托管，只能通过其面板改。查的方法是：**

dig +short NS 你的域名
dig +short A 你的域名

如果 NS 返回的是自己控制的主机名，切换成本最低；如果返回的是第三方服务商的名字，去那个平台改记录即可；这两条都不是问题的话，停机可以压到 1 分钟以内。

最后提醒一个前提：香港是全球互联网枢纽，国际出口带宽高度紧张。 同配置机器在香港与美西的单价差距是好几倍——迁移时如果顺便对比一下机房位置的单位成本，往往比单纯比同一家机器的配置更值得花时间。

二、迁移前的准备工作清单

清单的作用是「在出事前把所有依赖找出来」，最有效的方式是照着旧机器的配置反查。

第一步：把旧机器的配置完整导出来。

# 系统信息
uname -a
cat /etc/os-release
# 硬件与磁盘
lscpu | head -20
free -h
df -h
lsblk
# 监听端口与已安装服务
ss -tulnp
systemctl list-units --type=service --state=running --no-pager
# 已安装的包
dpkg -l > /tmp/pkgs-debian.txt
rpm -qa > /tmp/pkgs-rhel.txt
# 定时任务
crontab -l
for u in $(cut -d: -f1 /etc/passwd); do crontab -u $u -l 2>/dev/null; done

第二步：把配置文件和数据路径找出来。 这一步用 grep 比人工翻目录快得多。

# 在配置里找绝对路径
grep -rhoE "/(var|opt|srv|home|etc)/[a-zA-Z0-9_./-]+" /etc/nginx /etc/php* 2>/dev/null | sort -u
# 找环境变量文件
find / -maxdepth 4 -name ".env" -o -name "*.env" 2>/dev/null | grep -v proc
# 找上传目录
find /var/www -type d -name "upload*" 2>/dev/null

第三步：记录当前的实际用量，而不是配置上限。 这是判断新机器够不够的唯一依据。

# 内存峰值：看过去一周的最高使用
sar -r -f /var/log/sysstat/sa* 2>/dev/null | awk '/Average/{print $4,$5,$6}' | sort -k3 -n | tail -3
# 或者直接看当前
free -h
# 磁盘实际占用
du -sh /var/www /var/lib/mysql 2>/dev/null
# 流量：从服务商控制台看上个月实际用了多少

第四步：新机器的环境准备。 不要在新机器上临时装，尽量写成一个可重复执行的脚本。

# 一个安装脚本，重复执行不报错
cat > /tmp/setup.sh <<'EOF'
#!/bin/bash
set -e
export DEBIAN_FRONTEND=noninteractive
apt update
apt install -y nginx mysql-server php-fpm php-mysql redis-server \
  rsync screen unzip git
systemctl enable --now nginx mysql redis-server
EOF
bash /tmp/setup.sh

这一步的关键不是脚本本身，是「可重复」。 迁移失败重做一次时，有脚本和没脚本的差别是 20 分钟和 2 小时。

第五步：装 fail2ban 并提前放行。 这一步和第一节说的 SSH 加固是同一套：新机器在配置完成前，SSH 端口要保证能连。

# 新机器的安全组先放行 SSH 端口，再做端口变更

顺便说一句：迁移是加固的最佳时机。 **新机器上直接按第四节的基线配置（密钥登录、fail2ban、防火墙默认拒绝入站），比迁移完再补做要省事得多——反正都要重装一遍系统。

第六步：把应用的运行时环境参数对齐。 这一步最容易被忘，因为系统装好了、文件也传过去了，页面却还是报错。 需要逐项核对的是：

# PHP 版本与扩展（跨机迁移最常见的报错来源）
php -v
php -m | sort > /tmp/php-new-modules.txt
# 在旧机器上跑同样的命令，diff 两份扩展列表
# 缺哪个扩展就装哪个，例如
apt install -y php8.1-mysql php8.1-curl php8.1-mbstring php8.1-xml php8.1-gd
# 时区
php -i | grep "date.timezone"
# MySQL 字符集与排序规则，两端必须一致
mysql -e "SHOW VARIABLES LIKE 'character_set_%'; SHOW VARIABLES LIKE 'collation_%';"

查看 joysol 当前月价与库存

为什么这一项要单独列出来：PHP 大版本从 7 升到 8 时，很多老代码会直接报致命错误；MySQL 两端字符集不一致会导致「旧机器上正常、新机器上插入中文报错」这类幽灵问题。 这两个坑排查起来都很费时间，不如在迁移前 10 分钟就核对一遍。

三、文件同步：rsync 的正确用法

文件同步是迁移里最简单也最容易出岔子的一环。 关键在于用对 rsync 的参数，并且知道什么时候该用 --delete。

第一次同步（全量）：

rsync -avz --delete \
  --exclude '.git' \
  --exclude 'node_modules' \
  --exclude 'vendor' \
  --exclude '*.log' \
  --exclude 'cache/' \
  -e "ssh -p 20222 -i ~/.ssh/id_ed25519" \
  /var/www/ deploy@新服务器:/var/www/

这个命令里每个参数都有理由：

-a 是归档模式，等价于 -rlptgoD（递归、软链接、保留权限、保留时间、保留属主属组、保留设备文件、保留特殊文件）。 权限和时间戳必须保留——否则 WordPress 的文件权限乱了会直接 403。

-v 输出详细过程，-z 传输时压缩。 对 HTML/CSS/JS 为主的站点，压缩比不错；对已经压缩过的图片和视频，-z 反而浪费 CPU，这时可以加 --exclude '*.jpg' --exclude '*.png' --exclude '*.mp4' 跳过压缩。**

--delete 删除目标端源端已不存在的文件。 这是最容易被误用的一项——目标路径写错一个字符，--delete 就会把那个目录里的东西全删掉。安全做法：第一次同步不加 --delete，等确认同步正常后再加；或者先加 --dry-run 跑一遍看会删什么。**

--exclude 排除掉不该同步的内容。 这些排除项不是可有可无的：node_modules 可能有几百 MB 且能在新机器上重装；.git 如果新机器要用 git 拉代码反而应该同步，取决于你的部署方式——如果新机器是「git clone + 同步上传目录」，那 .git 不用传；如果是「纯文件拷贝」，那必须传，否则新机器上的 git 仓库状态是错的。**

-e "ssh -p 20222 -i ..." 指定 SSH 的端口和密钥。 如果你的 SSH 不是 22 端口（按第二节加固过的一般都不是），这个参数必须写，否则 rsync 会去连 22 端口然后卡住等密码。

第二次同步（增量，在停机前做）：

rsync -avz --delete --exclude '...' -e "ssh -p 20222 -i ~/.ssh/id_ed25519" \
  /var/www/ deploy@新服务器:/var/www/

增量同步只传变化部分，通常几十秒内完成。 这一步的作用是把「停机期间的差异量」压到最小——差异越小，DNS 切换后的数据不一致窗口就越短。

大数据量时的增量同步技巧：

# 第一次用 --inplace 提高大文件传输效率
rsync -avz --inplace --partial --append-verify \
  -e "ssh -p 20222 -i ~/.ssh/id_ed25519" \
  /data/ deploy@新服务器:/data/

--partial 保留中断的传输进度，断了可以续传；--append-verify 适合只追加不改的日志、大文件镜像。

传大文件时更推荐用 screen 或 tmux 挂着，避免 SSH 断线导致任务中断：

# 在本地执行
screen -S sync
# 在 screen 里跑 rsync，然后按 Ctrl+A 再按 D 脱离
# 回来时 screen -r sync 恢复

最后一步：校验。 同步完必须验证，不能凭「rsync 没报错」就认为成功。

# 比对文件数量
find /var/www -type f | wc -l
# 在新机器上执行同样的命令，对比数字
# 比对总大小
du -sb /var/www
# 关键文件抽样校验（MD5）
md5sum /var/www/index.php /var/www/wp-config.php

数量对不上就说明有文件没同步过去，回查 --exclude 是否误排除了重要目录。

最后补一个容易被忽略的场景：跨商家迁移时文件权限的差异。 不同商家、不同发行版的默认 umask 可能不同，同一个上传目录在新机器上可能出现「文件属主是 root、PHP 进程读不到」的情况。 标准做法是统一属主：

# 统一为 web 运行用户
chown -R www-data:www-data /var/www/
# 目录需要可进入，文件需要可读
find /var/www -type d -exec chmod 755 {} \;
find /var/www -type f -exec chmod 644 {} \;
# 上传目录需要可写
find /var/www/uploads -type d -exec chmod 775 {} \;

tmhhost 官网机型与实时报价

注意 chown -R 是递归的，执行前用 -print 预览一遍要改哪些路径，别在根目录上执行。

四、数据库迁移：一致性与不停机

数据库迁移比文件迁移难，因为文件是静态的、数据库在持续变。 核心问题是「怎么保证切换的那一刻两边数据一致」。

方案一：停机迁移（最简单，适合个人站）。

# 1. 在旧机器上锁表并导出（锁表期间写入被挂起）
mysqldump -u root -p --single-transaction --quick --routines --triggers --events \
  --default-character-set=utf8mb4 yourdb | gzip > /tmp/dbdump.sql.gz

# 2. 传输
scp -P 20222 /tmp/dbdump.sql.gz deploy@新服务器:/tmp/

# 3. 在新机器上导入
gunzip -c /tmp/dbdump.sql.gz | mysql -u root -p yourdb

注意 --single-transaction 这个参数：它让 InnoDB 表的导出不阻塞写入，所以如果你能接受「导出期间数据还有微小变动」，用 --single-transaction 比锁表更平滑。 真正需要严格一致时才用 --lock-tables（默认行为会锁表），代价是导出期间网站写入会卡住。

方案的停机时间估算：

数据量	导出耗时	传输耗时	导入耗时	合计停机
100 MB 以内	1 到 3 分钟	1 到 2 分钟	2 到 5 分钟	5 到 10 分钟
1 GB 左右	5 到 15 分钟	3 到 8 分钟	10 到 30 分钟	20 到 50 分钟
10 GB 以上	30 到 90 分钟	10 到 40 分钟	1 到 3 小时	2 到 5 小时

野草云官网机型与实时报价

表里的数字是按常见 SSD 机器和千兆以上带宽估的量级，实际以你机器实测为准。 关键结论：数据量超过 10 GB，方案一就不划算了，要用方案二。

方案二：主从复制（不停机，适合有写入的业务）。

# 在旧机器（主库）上
# 1. 确认 binlog 已开启
grep binlog /etc/mysql/my.cnf
# 需要配置：
# [mysqld]
# server-id = 1
# log-bin = mysql-bin
# binlog_format = ROW
# binlog_expire_logs_seconds = 604800

# 2. 创建同步账号
CREATE USER 'repl'@'新服务器IP' IDENTIFIED BY '强密码';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'新服务器IP';
FLUSH PRIVILEGES;

# 在新机器（从库）上
# 3. 配置从库
mysql -u root -p <<'EOF'
CHANGE MASTER TO
  MASTER_HOST='旧服务器IP',
  MASTER_USER='repl',
  MASTER_PASSWORD='强密码',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=4;
START SLAVE;
SHOW SLAVE STATUS\G
EOF

复制跑起来后，观察 SHOW SLAVE STATUS 的两个关键字段：Seconds_Behind_Master 应该是 0 或很小，Slave_IO_Running 和 Slave_SQL_Running 都应该是 Yes。 如果 IO 线程报错，多半是旧机器的防火墙没放行新服务器的 3306 端口——这是最常见的坑。

切换时的关键动作是「只读降级 → 等复制追平 → 停写 → 反向切换 → 切 DNS」。 让旧库在切换前进入只读状态（FLUSH TABLES WITH READ LOCK 或 SET GLOBAL read_only = ON），这样不会有新数据写进旧库导致复制断裂。

方案三：逻辑复制或第三方工具（大规模场景）。

对于读写分离、只读副本、表结构不同、需要过滤部分表同步的业务，可以考虑 mysql-replication 系列工具或云厂商的迁移服务。 这一节的适用条件是：单表超过 1 亿行、需要跨版本同步、或需要在迁移过程中保持源可读。 如果只是普通业务站，方案一和方案二足够，不要为了用工具而用工具。

迁移后的校验，这一步不能省：

-- 对比两边的行数（每张关键表都查一遍）
SELECT COUNT(*) FROM users;
SELECT COUNT(*) FROM orders;
-- 对比校验和（MySQL 5.7+）
CHECKSUM TABLE users, orders;
-- 抽查最新数据
SELECT * FROM orders ORDER BY id DESC LIMIT 10;

行数对得上不代表数据对得上——所以最后一定要抽查几行最新的实际内容，肉眼确认字段没有错位、没有截断。

五、DNS 切换：让流量真正走过来

DNS 切换是整个迁移的临门一脚，也是最容易出心理落差的一步——因为改完之后「感觉上」不会立刻生效。

第一步：提前降低 TTL。 这一步要在迁移前 24 到 48 小时做。

# 查询当前 TTL
dig 你的域名 A +noall +answer
# 在 DNS 服务商面板把 TTL 改成 300 秒（5 分钟）

为什么要改：默认 TTL 常常是 3600 秒（1 小时）甚至更久。 如果迁移完成时才改 TTL，之前的解析记录还在各处的递归 DNS 服务器里缓存着，老 IP 会继续被访问一小时。 提前改 TTL，等于给缓存一个自然过期的窗口。

第二步：切换当天，先做一次完整的预演。

# 在新机器上，把本地 hosts 指向新 IP，直接访问新服务器
echo "新服务器IP 你的域名" >> /etc/hosts
# 浏览器或 curl 访问，确认应用、数据库、邮件、回调全部正常
curl -I http://你的域名

这一步是整个流程里最有价值的一步——它让你在切 DNS 之前就把所有问题暴露出来。域名解析到本地 hosts 后，应用里的绝对 URL、第三方回调、证书校验都会走真实的路径。**

第三步：正式切换。

# 在 DNS 服务商面板，把 A 记录从旧 IP 改成新 IP
# 或者用命令行（以 Cloudflare 为例）
# 用 API 更可靠，具体参数以服务商文档为准

切换后立刻验证：

# 看解析是否已经生效（注意有些机器本地还缓存着旧记录）
dig +short 你的域名
# 从外部验证
curl -I http://你的域名
# 检查返回的服务器标识是否是新机器
curl -s http://你的域名/healthz

第四步：处理旧机器的收尾。 不要立刻关掉旧机器，至少保留 24 到 48 小时。

# 在旧机器上，把服务停掉但保留系统
systemctl stop nginx
# 或者保留一个提示页面，说明已迁移

保留旧机器的意义有三个：回滚（第四节讲过）、对比排查（两边数据不一致时能查）、以及等搜索引擎和 CDN 的缓存过期。

第五步：别忘了 CDN。 如果用了 CDN，源站 IP 变更后必须去 CDN 面板更新回源地址，并刷新缓存。 这是最常见的「DNS 切了但网站还是 502」的原因——CDN 还在回源到旧 IP。

查 isvoro 在售套餐与库存

同时提醒：切换前 48 小时内不要同时改 DNS 和做大规模代码发布。 变量一次只动一个，否则出问题时你分不清是哪个引起的。

六、回滚方案：把风险控制在可接受范围

任何迁移都必须有回滚方案，没有回滚方案的迁移叫赌博。 这一节给出一个具体的、可在 5 分钟内执行的回滚流程。

回滚的前提：老机器在切换后必须保持可写或至少保持数据完整。

推荐的回滚设计：

第一步，在旧机器上把数据库设为只读，而不是关掉。

-- 切换前
FLUSH TABLES WITH READ LOCK;
-- 保持连接不断开，等待新库追平

-- 回滚时（如果需要切回旧库）
SET GLOBAL read_only = OFF;

第二步，记录切换的确切时间点。 这个时间戳是回滚时判断「哪些数据要补」的唯一依据：

date '+%Y-%m-%d %H:%M:%S %Z' | tee /tmp/migration-cutover.txt

第三步，回滚的操作清单（按顺序执行）：

# 1. 停止新机器的写入（避免数据继续分叉）
# 在新机器上
systemctl stop php-fpm
systemctl stop nginx

# 2. 把分叉期间的数据从新库导回旧库（如果有写入）
mysqldump -u root -p --single-transaction --quick \
  --where="updated_at > '切换时间戳'" yourdb | \
  gzip > /tmp/diff.sql.gz
scp -P 20222 /tmp/diff.sql.gz root@旧服务器:/tmp/
# 在旧机器上导入
gunzip -c /tmp/diff.sql.gz | mysql -u root -p yourdb

# 3. 把 DNS 切回旧 IP
# 在 DNS 服务商面板改回

# 4. 恢复旧机器的写入
systemctl start php-fpm
systemctl start nginx

回滚的时间成本：第 1 步 30 秒，第 2 步取决于分叉数据量（通常几分钟），第 3 步 1 分钟（DNS 生效受 TTL 影响），第 4 步 30 秒。 整体在 5 到 15 分钟内。

但这里有一个必须提前想清楚的问题：DNS 回滚不是瞬时的。 因为 TTL 是 300 秒，意味着最坏情况下有 5 分钟的流量会继续打到新机器上。 如果你的新机器在回滚期间是「停止写入」的状态，这些请求会报错。 更稳的做法是：新机器不要停止服务，而是切成只读模式（返回维护页或者从旧库读），这样即使有残留流量打过去也不会产生分叉数据。

回滚的触发条件要提前写死，不能临场判断。建议这样定：

故障类型	判断标准	动作
DNS 解析错误	外部访问大量 NXDOMAIN 或超时	立即回滚
应用 502	新机器错误率超过 5% 持续 5 分钟	立即回滚
数据不一致	抽查发现关键数据缺失	立即回滚并补数据
性能明显下降	p99 比旧机器高出 50% 以上	先观察 30 分钟，仍不恢复则回滚
单个非核心功能异常	邮件回调、统计脚本等	单独修，不回滚

查看 zorocloud 当前月价与库存

「回滚是一个正常操作，不是失败」这个心态很重要。 很多团队为了「不认输」硬撑，结果把 10 分钟的回滚拖成了 2 小时的排查。

七、迁移后的验证与善后

迁移不是「DNS 切了就完了」，切完之后还有一整套验证清单。 这一节给一份可直接逐条打勾的表。

第一层：技术验证（切完立刻做，15 分钟内）。

# 1. 解析是否指向新 IP
dig +short 你的域名
# 2. 站点是否正常响应
curl -I https://你的域名
# 3. 关键接口是否通
curl -s https://你的域名/api/health
# 4. 证书是否正确（IP 换了但域名没变，证书应该不用动）
openssl s_client -connect 你的域名:443 -servername 你的域名 2>/dev/null | openssl x509 -noout -dates
# 5. 定时任务是否在跑
crontab -l && systemctl list-timers --all

第二层：业务验证（切完 1 小时内）。

验证项	怎么验	通过标准
下单流程	真实下一单（可后取消）	支付成功、订单生成、库存扣减、发货通知都到
邮件发送	触发一次真实邮件	收到且不在垃圾箱
登录注册	新用户注册 + 老用户登录	验证码/链接能收到，session 正常
上传下载	传一张图再访问	上传成功、可访问、不 404
后台统计	打开数据看板	数据量与旧机器一致
第三方回调	触发一次 webhook	对方收到回调，日志有记录
定时任务	手动触发一个	邮件/报表正常发出

查看 backwaves 当前月价与库存

第三层：持续观察（24 到 48 小时）。

看四个指标：HTTP 错误率、日志里的 5xx 数量、服务器资源占用（CPU、内存、磁盘）、流量消耗。 流量消耗这一项特别值得盯——如果迁移后流量突然翻倍，往往意味着 CDN 回源配置错了（静态资源没走 CDN，直接回源打到了 VPS）。

第四层：善后清理（第 3 到 7 天）。

# 1. 旧机器上的定时任务全部停掉（防止两台机器同时执行同一个任务）
crontab -r
# 2. 旧机器上的服务停掉
systemctl stop nginx php-fpm
# 3. 保留旧机器至少 7 天，确认稳定后再释放

释放旧机器之前，有三件事必须做完：

第一，确认数据已经完整迁移并且能独立运行。 在新机器上完整导出一份数据库，然后做一次本地恢复测试——导入成功才说明新机器上的数据是自洽的。**

第二，把旧机器上的独有关联全部转移。 包括：旧 IP 在其他平台的白名单、旧服务器上的 SSH 密钥被其他机器信任的情况、监控系统的服务器列表、CDN 的回源记录、第三方服务的回调配置。

第三，确认 DNS 已经全部切换，包括那些你忘了的子域名。

# 列出所有指向旧 IP 的解析
dig +short -x 旧服务器IP
# 或者用在线工具做反向查询，确认没有遗漏的记录

最后一条建议，是给以后省钱的：把这次的迁移过程写成脚本。 下一次迁移时，你只需要改几个变量（IP、域名、库名）就能重跑整个流程。 这比任何一篇迁移教程都值钱。

还有一件事值得单独说：迁移期的新旧机器不要同时接流量。 如果两台机器都对外提供服务、并且都连着同一个数据库，那么数据库连接数会翻倍、写入会互相覆盖。 正确的做法是切换前把旧机器的应用层停掉（只保留数据库给从库复制用），切换后再把新机器的应用层拉起来。 这个顺序搞反，常见的后果是「数据莫名少了几条」——实际上是两台机器的应用在同时写入同一批订单。

八、常见误区与常见报错

误区一：以为文件同步完就是迁移完了。 数据库、配置、证书、定时任务、白名单，每一项都能让新站点「看起来在跑，但数据不对」。

误区二：以为 DNS 改了流量就立刻过来。 要看 TTL。 默认 1 小时的 TTL 意味着最坏情况下有 1 小时的残留流量；要快就提前把 TTL 改成 300 秒。

误区三：以为可以边写边同步不用停机。 rsync 只能同步文件，不能同步数据库的写操作。 数据库要么停写导出，要么用主从复制追平后切换——没有第三条路。

误区四：以为新机器装完就能用。 PHP 扩展、时区、字符集、Redis 配置、OPcache、Nginx 的伪静态规则，这些都要照抄旧机器的。

误区五：以为迁完就能立刻删旧机器。 至少留 7 天。

报错一：rsync 传到一半断，提示 Connection reset by peer。 SSH 会话超时或网络不稳。 解法是加 --partial --append-verify 支持断点续传，并用 screen 挂住任务；同时确认新机器的防火墙没限制出站连接。

报错二：rsync 报 rsync: [sender] send_files failed: Permission denied 或 change_dir ... failed。 权限问题。 老机器上文件属于 www 用户、新机器上目录属主不同。 **解法是加 -a 保留属主（需要 root 权限执行 rsync），或者先用 sudo chown 统一属主。

报错三：rsync 加了 --delete 之后，误删了新机器上的文件。 这是最危险的一个错误。 解法：立即停止后续同步（Ctrl+C），检查新机器上是否有其他重要数据在同一个目录下；长期做法是加 --backup --backup-dir=/tmp/rsync-backup，让被删的文件先落到备份目录。

报错四：mysqldump 导出报错 Unknown table 'mysql.user'。 这个报错在 MySQL 8.0 出现——8.0 里 mysql.user 是视图，mysqldump 默认会跳过系统库。 解法是显式指定 --databases 或用 --no-tablespaces。

报错五：导入时报 ERROR 1064 (42000) at line 100 或中文乱码。 字符集不匹配。 导出和导入两端都加 --default-character-set=utf8mb4。

报错六：主从复制报 Could not find first log file name in binary log index file。 主库的 binlog 文件名或 position 不对。 解法是在主库上执行 SHOW MASTER STATUS; 拿到当前的 binlog 文件名和 position，再用这两个值重新执行 CHANGE MASTER TO。

报错七：主从复制报 Replica I/O for channel '': Got fatal error 2003: Can't connect to MySQL server on '旧IP' (110)。 110 是连接超时。 几乎总是因为旧机器的防火墙没放行新服务器的 IP 去连 3306。 解法是在旧机器的防火墙里放行新服务器 IP 的 3306，而不是放行整个公网。

报错八：DNS 切了之后部分用户还是访问旧站点。 这是 TTL 缓存，属正常现象，等 TTL 过期即可。 如果急，可以用 dig @8.8.8.8 你的域名 看公共 DNS 的解析结果是否已更新。

报错九：切过去之后大量 502，日志显示连不上数据库。 按顺序排查三件事：新机器上 MySQL 是否在运行、应用配置的数据库地址是不是还是旧 IP、以及新机器的防火墙有没有放行 3306 给本机回环。

报错十：迁移后网站能访问，但上传功能报 Upload failed，日志里有 Permission denied 或 Call to undefined function。 这是第六节说的两类问题叠加：前者是属主权限没统一，后者是 PHP 扩展没装齐。 对应解法分别是 chown -R 统一属主，以及在旧机器上 php -m 导出扩展列表逐个比对补装。

报错十一：迁移后时间显示差了 8 小时，定时任务全乱。 时区没对齐。 检查 /etc/timezone 和 php.ini 里的 date.timezone 两处，两处要一致；容器或虚拟机环境还要确认宿主机的时间同步服务是否正常。

查 digitalvirt 在售套餐与库存

报错十二：数据同步完成后，新机器上的 WordPress 提示「数据库连接正常但内容为空」。 常见原因是导出的数据库没有包含表结构——多半是用了 mysqldump 但漏了 --routines（存储过程）或站点用的是 --no-data 误操作。 对照检查：旧机器上 SHOW TABLES; 的表数量和新机器上是否一致。

按你的情况，下一步该看哪家

上面讲的是判断标准，但多数人最后还是想问一句「那我该买谁」。按你的实际情况对照下面几条，直接去看对应的机型页比继续比价更快：

只想搭个站、预算优先：先看价格最低那档够不够用，别为用不上的配置付钱。看数脉科技当前机型与价格
只是开发测试、临时用：按小时或月付，用完就删，别买年付。看 joysol 当前机型与价格

价格与库存以商家页面当日显示为准，下单前建议先确认退款窗口与是否支持按月付费。

九、常见问题

问：香港VPS怎么搬家？

答：按六步走——盘点要迁的东西、写好可重复的环境安装脚本、rsync 全量加增量同步文件、mysqldump 或主从复制同步数据库、提前 48 小时把 DNS 的 TTL 改成 300 秒、切换后按技术、业务、观察三层清单逐条验证。 完整命令见第二到第七节。

问：迁移要停机多久？

答：看数据量。 100 MB 以内的库，停机迁移大约 5 到 10 分钟；1 GB 左右 20 到 50 分钟；10 GB 以上建议用主从复制做到近乎不停机，切窗口在 1 分钟内。 文件部分用 rsync 增量同步，切前先做一次增量可以把停机时的差异压到最小。

问：能不能做到完全不停机？

答：可以，用主从复制。 旧库做主库、新库做从库，复制追平后把旧库设为只读，切 DNS，再把新库提升为主库。 实际停机只有 DNS 生效那一两分钟。 但要注意：整个切换期间旧机器不能释放，通常要留 7 天。

问：DNS 切换后流量没立刻过来怎么办？

答：是 TTL 的问题，不是故障。 默认 TTL 常常是 3600 秒，所以旧解析会在递归 DNS 里缓存一小时。 下次迁移前 48 小时先把 TTL 改成 300 秒，切换就会快得多。 用 dig @8.8.8.8 你的域名 可以看到公共 DNS 的最新解析。

问：回滚要多久？

答：5 到 15 分钟。 步骤是：停新机器写入、把分叉数据导回旧库、DNS 切回旧 IP、恢复旧机器服务。 但要提前设计好——如果切换时把旧库设成了只读而新库完全停止，回滚期间有 5 分钟残留流量会打到停止的新机器上，会报错。 更稳的做法是新机器切成只读而不是停服。

问：迁完之后旧机器什么时候能退？

答：至少 7 天之后，且要先做完三件事： 在新机器上完整导出并本地恢复一次数据库、把旧 IP 在其他平台的白名单全部转移、用反向解析确认没有遗漏的子域名还指向旧 IP。

问：迁到配置更高的新机器，配置该怎么选？

答：按旧机器的实际用量选，不是按标称配置。 按渠道库快照（2026-11-11 16:30），香港方向起步档是云途 HK.DS.M，350 元每月、32 GB 内存、480 GB 硬盘 SSD、1000 Mbps 端口、10000 GB 月流量，每 GB 内存 10.94 元、每 GB 硬盘 0.729 元、每 TB 流量 35.84 元；上一档 DS.ES.C 是 700 元每月、64 GB 内存、800 GB 硬盘 SSD、2000 Mbps 端口、40000 GB 月流量，每 GB 内存同样是 10.94 元、每 TB 流量降到 17.92 元。 同预算下 DS.ES.C 的内存翻倍、流量翻四倍，是迁移时最直接的升级路径。 实际报价与库存以官网当日显示为准。

最后再提醒一次价格口径：以上涉及机型配置与价格的内容来自渠道库快照（2026-11-11 16:30 抓取），各机型的实际报价、库存、续费价、IP 数量与退款政策请以官网当日显示和客服回复为准。

飞翔声明：飞翔网登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。