换VPS不掉线：迁移清单

我是小够，只推够用的 VPS。

换 VPS 是每个站长都会遇到的事：商家涨价、线路变差、配置不够用了。但很多人一想到迁移就头大——怕网站掉线、怕数据丢、怕配了半天环境起不来。其实迁移有套标准流程，照着走，基本可以做到访客无感，半夜切完第二天用户都不知道你换过机器。这篇给你一份完整的迁移清单。

迁移前准备：三件事

第一件：DNS TTL 改小。提前 24-48 小时，把域名的 TTL 改成 300 秒（5 分钟）。TTL 是 DNS 缓存时间，改小了，切换解析后全球生效快；不改的话，默认 TTL 可能 24 小时，切换后一半用户还在访问旧机器。这是"不掉线"的关键，别省这一步。

第二件：完整备份。按本站 VPS 备份 321 原则 的方法，把网站文件、数据库、配置文件全备一份。迁移本身就是一次"恢复演练"，备份是底气。

第三件：新机器环境搭好。新 VPS 上先装好 Web 环境（Nginx/Apache、PHP、MySQL 版本尽量和旧机器一致），别等数据传过去了才发现 PHP 版本对不上。版本不一致是迁移翻车的高发原因。

迁移步骤：按顺序来

步骤一：停写 / 进维护模式。如果网站有用户交互（评论、订单、发帖），迁移期间先开维护模式，或者选在凌晨低峰期操作。纯展示站可以跳过这步。

步骤二：打包网站文件。

# 旧机器上
tar -czf www.tar.gz /var/www/你的网站目录

传到新机器解压，注意文件权限和属主：chown -R www-data:www-data（Ubuntu/Debian）或对应用户，权限不对网站会 500 报错。

步骤三：迁移数据库。

# 旧机器导出
mysqldump -u root -p --single-transaction 数据库名 | gzip > db.sql.gz

# 新机器导入
gunzip < db.sql.gz | mysql -u root -p 数据库名

--single-transaction 保证导出时数据一致，InnoDB 表必备。大库（几十 GB）用 mydumper 多线程导，速度快很多。

步骤四：改配置文件。数据库名、用户名、密码、域名，wp-config.php 这类配置文件里的信息按新机器改一遍。别漏了缓存配置（Redis 地址）、邮件发送配置。

步骤五：本地测试。DNS 还没切，先用 hosts 文件把域名指向新机器 IP，本地浏览器访问一遍：首页、内页、后台登录、发一篇文章、下一个测试订单。所有功能在 hosts 阶段测完，别等切了 DNS 才发现问题。

DNS 切换：正式上线

测试没问题，改 DNS 解析到新 IP：

1. 域名 DNS 管理处（Cloudflare / DNSPod / 域名商），A 记录改成新机器 IP。
2. TTL 已经是 300 秒，5-10 分钟全球基本生效。
3. 用 ITDOG 这类工具查全球解析，确认各地都指向新 IP。
4. 观察 24 小时：网站日志、用户反馈、监控告警（Uptime Kuma 这时候很有用）。

旧机器别急着删：保留 3-7 天，确认一切正常再释放。这 3 天就是你的"后悔药"，也是回滚方案的前提。

切换后检查清单

• 网站能打开，首页、内页、后台都正常
• HTTPS 证书正常（新机器要重新申请 / 部署证书，别漏了）
• 数据库读写正常（发文章、评论测试）
• 定时任务（crontab）搬过去了，备份脚本在新机器上跑起来了
• 邮件发送正常（密码重置、订单通知这类）
• 第三方回调正常（支付回调、API 回调，IP 变了要在第三方后台更新白名单）
• 监控告警指向新 IP

最容易漏的三样：SSL 证书、crontab 定时任务、第三方 IP 白名单。这三样出问题，网站表面看着正常，实际功能是坏的。

翻车了怎么办：回滚方案

万一切了 DNS 发现大问题，别慌，回滚就行：

1. DNS 改回旧 IP（TTL 300 秒，5 分钟生效）。
2. 旧机器还在，数据是切换前备份的，最多丢切换期间的新数据。
3. 查清楚问题，修好再切。

所以旧机器保留 3-7 天不是浪费钱，是买保险。按小时计费的云（Vultr）留几天也就几毛钱。

不同建站方式的迁移差异

WordPress / 传统 LNMP：按上面的标准流程走就行。注意 wp-config.php 和 .htaccess / 伪静态规则，Nginx 和 Apache 的伪静态写法不一样，换 Web 服务器的要重写规则。

宝塔面板：宝塔有"网站备份 + 计划任务"功能，旧机器上一键备份网站（含数据库），新机器装宝塔后一键恢复。面板用户迁移最省心，但注意宝塔版本尽量一致，插件（PHP 版本）也要对上。面板教程可以参考本站建站场景的内容。

Docker Compose 部署：最优雅的一种。docker-compose.yml + 数据卷 + .env 文件拷到新机器，docker compose up -d 一把起。数据库在容器里的，docker exec 进去 dump，或者直接拷数据卷（停容器后拷）。平时就把 compose 文件扔 Git 仓库，迁移就是 git clone + up。

静态站（Hugo / Hexo）：最简单。源码在 Git 仓库，换机器重新 hugo 构建一把，Nginx 指过去就行。甚至不用迁移，直接在新机器重新部署。静态站的优势这时候体现得淋漓尽致。

有用户上传的站：wp-content/uploads 这类目录可能几十 GB，rsync 增量同步，分两次传：切换前传一次（大部分数据），切换当天再传一次增量（只传新增的），停机时间最短。

常见坑

坑一：PHP / MySQL 版本不一致。旧机器 PHP 7.4，新机器装了 PHP 8.2，老程序直接白屏。迁移前 php -v、mysql --version 对一遍，不一致的先在新机器装对版本。

坑二：忘记迁定时任务。备份脚本、缓存清理、订单同步，这些 crontab 里的任务不搬，新机器上悄悄就不工作了。crontab -l 导出一份，对着搬。

坑三：大文件传一半断了。网站附件几十 GB，scp 传一半断了。用 rsync 传，支持断点续传：rsync -avzP 旧机器:/var/www/ 新机器:/var/www/，-P 就是断点续传。

坑四：DNS 生效慢被误判为失败。TTL 没提前改小，切了半小时还有用户访问旧机器，以为迁移失败又切回去，来回折腾。记住：提前 24 小时改 TTL，切换后用 ITDOG 确认全球解析。

坑五：邮件进垃圾箱。新 IP 发邮件，SPF、DKIM、DMARC 记录要更新（IP 变了），不然密码重置邮件全进垃圾箱，用户以为网站坏了。

一句话总结

迁移 = 提前改 TTL + 完整备份 + 新机器搭好环境 + 文件数据库搬家 + hosts 测试 + 切 DNS + 观察 24 小时 + 旧机器留 3 天。流程不复杂，关键是按顺序、别跳步。收藏这篇，下次换 VPS 照着走就行，祝迁移顺利。