如何把 WordPress 网站从旧服务器完整搬到新主机而不丢数据？这篇指南拆解 LEMP 环境整站迁移的每一步：先在旧服务器打包文件和数据库，再同步到新主机恢复运行，最后切换 DNS（域名解析系统）并验证，全程附可直接执行的命令。按这套流程走，一两个小时内即可完成迁移，并且随时具备回滚能力。
迁移前的准备工作
正式动手前，先把”家底”盘点清楚。我们见过太多迁移失败案例，根源都在准备阶段漏了某一项配置，恢复时才发现对不上。
迁移前要核对的内容其实不多：
- 旧服务器的 PHP 版本、MySQL/MariaDB 版本，以及
php.ini中的upload_max_filesize、memory_limit取值 - Nginx 站点配置文件路径（通常在
/etc/nginx/conf.d/或/etc/nginx/sites-available/） - WordPress 的
wp-config.php中数据库名、用户名和表前缀 - 是否使用了 HTTPS 证书（Let’s Encrypt 还是商业证书）、是否有定时任务（crontab 里的 wp-cron 或自定义脚本）
新主机的环境版本必须等于或高于旧服务器。举个例子：旧机 PHP 7.4、新机 PHP 8.1，大部分站点可以直接跑；但如果旧机用的是 PHP 5.6 的老插件，迁到 PHP 8.1 很可能出现函数废弃报错。建议先在新主机上用 php -v 和 mysql --version 核对版本。迁移窗口尽量选在流量低谷时段，并提前把 LEMP 环境装好。如果你还没选新主机，可以参考这篇 VPS（虚拟专用服务器）购买指南，按流量和配置需求选型。
第一步：在旧服务器打包文件和数据库
准备工作就绪后，进入打包阶段。这里的关键是”完整”二字——文件、数据库、证书三样都要打包，少一样恢复时都会卡住。
1. 打包 WordPress 文件
先进入网站根目录（假设是 /var/www/example.com），用 tar 打包：
cd /var/www
tar -czf site-files.tar.gz example.com
如果站点附件特别多（比如图片上万张），tar 打包可能需要几分钟，期间建议不要在后台更新文章。打包完成后用 ls -lh site-files.tar.gz 确认文件大小是否合理——一个几十 MB 的企业站打包出来只有几百 KB，就要怀疑是不是路径写错了。
2. 导出数据库
数据库是整站迁移中最容易出错的环节。用 mysqldump 导出时，建议加上 --single-transaction 参数，避免导出过程中锁表影响前台访问：
mysqldump -u wpuser -p --single-transaction --default-character-set=utf8mb4 wordpress_db > wordpress_db.sql
这里的 wordpress_db 替换为你 wp-config.php 里的实际数据库名。导出后执行 head -50 wordpress_db.sql 快速抽查，确认文件开头有 CREATE TABLE 语句、结尾有 -- Dump completed，说明导出完整。
3. 收集 Nginx 配置和证书
把站点对应的 Nginx 配置文件复制一份到打包目录，证书文件（/etc/letsencrypt/ 下的密钥和证书，或商业证书的 .pem/.key 文件）也一并收集：
cp /etc/nginx/conf.d/example.com.conf ./nginx-conf/
cp -r /etc/letsencrypt/live/example.com ./certs/
最后把这三类文件合并成一个总包，等下同步时只需要传一个文件：
tar -czf migration-bundle.tar.gz site-files.tar.gz wordpress_db.sql nginx-conf/ certs/
值得一提的是，数据库导出和文件打包之间会有几分钟的时间差，这期间新产生的评论或订单可能不在备份里。所以正式切换 DNS 前，建议在低峰期再做一次增量补导（只需重跑上面的 mysqldump 命令）。
第二步：在新主机上恢复站点
打包完成后，把迁移总包同步到新主机。这里推荐用 scp 直传，两台机器之间走加密通道，几十 MB 的包通常一两分钟就能传完：
scp migration-bundle.tar.gz root@新主机IP:/root/
1. 解压并还原文件
在新主机上解压总包，把网站文件放到与旧机一致的路径下。路径一致能省去很多配置修改，比如旧机是 /var/www/example.com，新机也保持一样：
cd /root && tar -xzf migration-bundle.tar.gz
tar -xzf site-files.tar.gz -C /var/www/
chown -R www-data:www-data /var/www/example.com
chown 这一步不能省。LEMP 环境下 PHP 进程通常以 www-data 用户运行，权限不对会直接导致 WordPress 后台装不了插件、更新失败。
2. 导入数据库
先在新主机的 MySQL 里创建同名数据库和用户，再导入数据：
mysql -u root -p -e "CREATE DATABASE wordpress_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p -e "CREATE USER 'wpuser'@'localhost' IDENTIFIED BY '你的新密码'; GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wpuser'@'localhost'; FLUSH PRIVILEGES;"
mysql -u root -p wordpress_db < wordpress_db.sql
导入完成后，编辑 /var/www/example.com/wp-config.php，核对新主机的数据库密码是否与旧机一致；如果新建用户时换了密码，这里要同步修改。
3. 恢复 Nginx 配置并启动
把配置文件和证书放回对应位置，然后测试并重载 Nginx：
cp nginx-conf/example.com.conf /etc/nginx/conf.d/
mkdir -p /etc/letsencrypt/live/example.com && cp certs/* /etc/letsencrypt/live/example.com/
nginx -t && systemctl reload nginx
nginx -t 是这一步的安全阀——它会在不中断服务的前提下检查配置语法，只有输出 syntax is ok 和 test is successful 才继续，避免带着错误配置重启导致整站 502。
到这里先别切 DNS，用本地 hosts 验证：在你自己的电脑上把域名临时指向新主机 IP，访问首页、文章页、后台登录页各一遍。三项都正常，说明新环境真正可用了，这一步也是整站迁移能否零故障的关键验证点。
第三步：切换 DNS 并完成收尾
新环境验证通过后，就进入正式切换。到域名解析服务商处，把 A 记录从旧 IP 改为新 IP；TTL（DNS 缓存存活时间）建议提前一晚调低到 300 秒，这样切换后全球生效更快。切换后用下面的命令观察解析是否已经指向新机：
dig +short example.com
DNS 生效时间因地区和运营商而异，通常几分钟到几小时不等。生效期间会有部分访客到旧机、部分到新机，这也是为什么旧服务器建议保留 48 小时再关机——它不仅是回滚保障，还能在不占用新机带宽（单位时间内可传输的数据量）的前提下承接老访客。
切换完成后的收尾清单：
- 重跑一次 mysqldump 补齐最后几分钟的数据差异
- 在旧机 Nginx 上临时开启反向代理，承接还没切换解析的老访客
- 确认 HTTPS 证书在新机正常，用
curl -Iv https://example.com查看证书链 - 观察新机 24 小时的错误日志：
tail -f /var/log/nginx/error.log
如果切换后发现严重问题，回滚很简单：把 DNS 的 A 记录改回旧 IP，解析生效后流量就回到旧服务器，通常几分钟内可恢复。这也是整站迁移方案里”旧机保留 48 小时”的真正意义——它买的不是带宽，是后悔药。
常见问题排查
即使每一步都按流程走，迁移后仍可能遇到几个高频报错。遇到问题时先对号入座，能省下大量排查时间。
首页正常、内页 404：这是固定链接结构没被 Nginx 识别。在站点配置的 server 块里补上伪静态规则即可解决：
location / { try_files $uri $uri/ /index.php?$args; }
提示”建立数据库连接时出错”：说明 wp-config.php 里的数据库密码和新机 MySQL 用户不匹配，或 MySQL 服务没启动。先执行 systemctl status mysql 确认服务状态，再核对密码。
上传图片提示权限不足：九成是文件属主没改。回到第二步的 chown -R www-data:www-data 检查是否执行到位，另外确认 php.ini 的 upload_max_filesize 不小于旧机取值。
后台特别慢：常见原因是 WordPress 连接外部更新服务被新机网络阻断。如果新主机在海外而读者主要在国内，可以接入 CDN（内容分发网络）中国加速方案改善访问链路。
解决这些问题的通用思路是看日志：Nginx 的 error.log 定位请求层错误，PHP-FPM 的日志定位执行层错误，MySQL 日志定位数据层错误。三层日志对一遍，绝大多数迁移问题都能找到根因。如果你希望减少这类运维负担，也可以考虑托管型方案，比如 WordPress 主机，由服务商处理环境配置和日常维护，你只需要专注内容和业务。
总结与行动建议
回顾整个 LEMP 环境整站迁移流程，核心其实是三句话：旧机打包要完整（文件、数据库、证书、Nginx 配置缺一不可），新机恢复要验证（hosts 验证通过才算环境可用），DNS 切换要留退路（旧机保留 48 小时随时可回滚）。
给你几条可以直接落地的建议：
- 第一次迁移前，先拿一个不重要的测试站在新机完整演练一遍，把坑都踩在测试环境
- 把本文的命令整理成自己的迁移脚本，每次搬家只需替换域名和数据库名等几个变量
- 迁移完成后 48 小时内，每天检查一次 Nginx 错误日志和搜索收录是否正常
- 如果你管理多个站点或缺少专职运维，推荐考虑 Hostease 的 独立服务器 或托管型 WordPress 方案，环境部署和备份由服务商承接
迁移本身并不可怕，可怕的是没有验证、没有回滚的裸奔式搬家。按这套流程执行，你的下一次换主机可以做到用户无感知。