帮助中心产品文档与操作指南

把WordPress网站迁移到新服务器

发布时间：2026-11-05

本文处理原域名、原网址结构保持不变的 WordPress 单站迁移。目标是把网站文件和数据库搬到新实例，并在新机恢复同一套业务。域名更换、多站点网络、分布式存储和复杂订单系统需要另外制定迁移方案，不与本次搬机混在一起。

先把新机准备成可接收的环境

记录旧机的 PHP 版本与扩展、数据库类型和版本、网站根目录、WordPress/主题/插件版本、定时任务以及 HTTPS 配置。新机先保持兼容，软件升级留到迁移稳定以后进行。

在新机建立独立网站目录、数据库和业务账号。PHP 网站可沿用Nginx与PHP-FPM配置；数据库账号参考MariaDB专用账号。目标目录和数据库不得与现有业务混用。源站使用 MariaDB 时，按MariaDB 备份与隔离恢复导出并检查副本，备份和导入工具也按 MariaDB 选择。

新机的 Web 入口先通过安全组或主机防火墙限制为管理员测试来源，并保留 SSH 管理通道。配置还没有改好、真实外部依赖还没有隔离时，不开放副本供公众访问。

保存旧机文件、数据库、站点配置及证书的独立备份，并先做一次恢复演练。记录当前 DNS、原 TTL、新旧 IP 和计划切换时间；如准备降低 TTL，应给原缓存至少一个旧 TTL 的时间自然到期。

第一次复制，用来验证新环境

从首次复制到正式切换期间，暂停旧站 WordPress 核心、主题和插件的自动更新，并冻结代码发布；登记原设置以便迁移后恢复。期间如果必须修复程序，先登记变更，切换前把同一版本代码补同步到新机并重新验证，避免最终数据库配上旧版程序。

下面从旧服务器把站点目录复制到新服务器的专用目录。两端需已有 rsync，目标部署账号应能写该新目录。替换真实路径、SSH 端口、账号和新机 IP；首次连接先核对新机 SSH 主机指纹。

rsync -a --dry-run --itemize-changes -e 'ssh -p 22' /var/www/baole-site/ deploy@203.0.113.20:/var/www/baole-site/

确认预演的来源、目标、文件数量符合预期，再执行：

rsync -a --itemize-changes -e 'ssh -p 22' /var/www/baole-site/ deploy@203.0.113.20:/var/www/baole-site/

目录末尾的斜杠表示复制目录内容。两端用户名或 UID 不同时，传完后必须按新机的部署账户与 PHP 用户检查归属，不能把旧机的数字 UID 当作新机的正确权限。

将数据库导入新机专用库后，在新机的 wp-config.php中更新数据库名、业务账号、密码和连接地址。保留原来的表前缀及站点密钥；不要把密码贴在终端命令参数或公开截图中。域名、协议和路径都没有变化时，不需要批量替换数据库里的网址。

DNS不切换，也能先检查新站

新机需要有覆盖正式域名的有效 HTTPS 证书。可以通过域名验证签发，或在授权范围内用受控通道迁移现用证书与私钥；测试时不跳过证书校验。

在自己的电脑检查新机，以下示例不会修改公共 DNS：

curl --resolve www.example.com:443:203.0.113.20 https://www.example.com/ -I

Windows PowerShell 中使用 curl.exe，避免旧版系统把 curl解释成其他命令。把域名和 IP 换成实际值；检查证书、状态码及重定向位置。要通过浏览器完整测试，可临时在本地 hosts 文件添加新机 IP 和实际域名。Windows 文件位于 C:\Windows\System32\drivers\etc\hosts，macOS/Linux 为 /etc/hosts；操作结束后删掉本次测试行。

测试副本先隔离真实发信、支付和自动通知，暂停这套副本的任务及队列，避免两台机器同时处理同一业务。检查首页、文章、固定链接、后台登录、图片上传、表单和日志，确认请求命中了新机；只看到相同首页不足以证明访问目标正确。

正式切换：旧机停写，最后同步

  1. 进入维护窗口。保存旧站点配置，在旧站域名的对外 Nginx server段临时加入 return 503;，配置检查通过后重载。确认旧站对外已进入维护，再暂停旧站任务、队列及其他写入入口。不要停止整台机器上不相关的业务。
  2. 生成最终数据库备份。在旧站停写后重新导出，并确认退出码、日志和文件完整性。新机的首次测试数据属于演练副本，最终恢复使用独立空库，导入后修改新机配置指向它。
  3. 补齐最后的媒体变化。同步停写前最后产生的上传文件。新机已修改过的 wp-config.php和环境配置不能被旧文件覆盖。使用下面命令时，先运行预演、核对目标，再执行正式同步。
rsync -a --dry-run --itemize-changes -e 'ssh -p 22' /var/www/baole-site/wp-content/uploads/ deploy@203.0.113.20:/var/www/baole-site/wp-content/uploads/
rsync -a --itemize-changes -e 'ssh -p 22' /var/www/baole-site/wp-content/uploads/ deploy@203.0.113.20:/var/www/baole-site/wp-content/uploads/

本例不删除目标端多余文件；若旧站在初次复制后删除或改名了媒体，应根据变更清单在新机另行核对，不能在未确认目标时追加 --delete。插件把数据写在 uploads 之外的目录时，也要同步那些已登记的数据目录。

  1. 再次验收新机。重新核对两端核心、主题和插件版本及登记的代码差异，再通过 hosts 或 --resolve核对最终数据、附件与配置。正式恢复发信等依赖前，应撤销演练用的拦截配置，并确认只有新机运行正式任务。
  2. 切换解析。修改实际入口的 A 记录；原来有 AAAA、CDN 回源或其他入口时一起核对，避免部分访问仍到旧机。新机开放业务，旧机继续停写，并保留原数据和配置。

切换后观察和回退

从至少两个实际访问网络检查域名解析与业务，确认新机有对应访问日志、最新内容和新增记录。DNS 缓存更新期间，少数访问仍可能到达旧机；保持旧机停写可以避免两边各产生一份数据。按已记录的旧 TTL 和实际访问情况安排观察期，不以“我电脑能打开”作为唯一依据。

发现问题的时间 处理方式
新机尚未接收正式写入 保留新机日志，确认旧数据完整后把入口切回旧机，恢复旧站原配置和任务状态。
新机已经产生新文章、注册、订单或上传 先让新机停写并导出最新数据库、媒体和必要日志；确认如何把增量迁回或合并，再切回旧机，不能直接恢复切换前备份。

旧机保留到验证和观察完成后再处理。删除旧实例、清理备份和更换数据库版本是后续独立操作，不是 DNS 切换后立即执行的固定步骤。