15%

全场主机优惠15%

测试技能，享折扣

使用代码：

Skills
开始使用
21.10.2024
Category icon专用服务器 Category icon安全 Category icon虚拟服务器

迁移到另一家虚拟主机提供商时需要考虑的事项

将网站迁移到新的托管服务商是网站所有者可能进行的风险最高的基础设施操作之一。操作正确，可实现零数据丢失、极短停机时间和可量化的性能提升。操作不当，则会导致数据库损坏、DNS故障、SEO排名下降，以及数小时的紧急恢复工作。

本指南涵盖托管迁移的每个关键阶段——从迁移前审计和兼容性验证，到DNS切换机制，再到迁移后监控——并提供无故障执行所需的技术深度。

第一阶段：在操作任何内容之前审计当前托管环境

迁移失败最常见的单一原因是跳过对现有环境的彻底审计。在评估新服务商之前，您需要精确盘点实际运行的内容。

流量和资源分析

提取至少90天的服务器资源数据——不仅仅是页面浏览量。重要的指标包括：

  • 峰值并发连接数——不是平均流量，而是服务器必须处理的峰值上限
  • 每个PHP工作进程或应用程序进程的内存消耗
  • 磁盘I/O模式——如果您运行WooCommerce或自定义CRM等数据库密集型应用程序，这一点尤为重要
  • 带宽利用率——每月传输总量与当前套餐上限的对比

如果您当前的主机提供cPanel或Plesk，可在资源使用或AWStats部分访问这些数据。在Linux VPS上，运行以下命令获取基准快照：

vmstat 1 10
iostat -x 1 5
free -m
df -h

此输出将告诉您瓶颈是CPU、RAM还是磁盘——这直接决定您是否需要更大的共享套餐、VPS或独立服务器。

软件栈清单

记录栈中每个组件的确切版本号：

  • PHP版本（如8.1、8.2）及已启用的扩展（mbstring、curl、gd、imagick、redis）
  • MySQL或MariaDB版本及存储引擎（InnoDB与MyISAM的区别对迁移工具有影响）
  • Web服务器软件：Apache、Nginx、LiteSpeed或反向代理组合
  • 任何已编译模块、自定义.htaccess规则或nginx.conf位置块
  • Cron任务——从crontab -l导出并单独记录
  • SSL证书类型和颁发机构（Let’s Encrypt、商业CA、通配符）

目标服务器上哪怕缺少一个PHP扩展，都可能悄无声息地破坏仅在特定用户操作下才会触发的功能——这类错误在迁移后极难追踪。

第二阶段：评估并选择正确的托管层级

选择错误的托管层级是一个结构性错误，会迫使您在数月内进行第二次迁移。将审计结果与正确的基础设施类别对应起来。

托管层级对比

标准共享托管VPS托管独立服务器
————
隔离性无——共享资源完整OS级隔离完全硬件隔离
CPU/RAM共享池，受限制保证分配完整硬件分配
Root访问否是是
自定义软件严格限制完全控制完全控制
可扩展性仅垂直扩展，有限垂直+水平扩展需要硬件升级
最适合宣传页面、低流量成长型应用、电商高流量、合规要求高
典型正常运行时间SLA99.9%99.9%–99.99%99.99%
DDoS防护基础或无取决于服务商高级，可配置

关键决策规则：如果您的应用程序需要特定的PHP-FPM池配置、Redis套接字连接、自定义Nginx重写或任何守护进程，共享托管在架构上不兼容。您至少需要一台具有root访问权限的VPS。

对于流量适中的WordPress或Joomla网站，带cPanel的VPS在保留虚拟机隔离性和性能的同时，提供熟悉的控制面板界面。

服务商评估标准

除营销宣传外，还需根据以下可验证的技术因素评估服务商：

  • 含财务处罚条款的正常运行时间SLA——没有赔偿的99.9% SLA毫无意义
  • 数据中心等级评定（生产工作负载需Tier III或Tier IV）
  • 网络冗余——BGP多宿主、多上游服务商
  • 存储类型——NVMe SSD与SATA SSD与机械硬盘（延迟差异显著）
  • 备份策略——频率、保留期限、备份是否异地存储
  • 支持响应时间SLA——区分首次响应时间和解决时间

第三阶段：创建并验证完整备份

任何迁移都不应在没有经过验证的、可恢复备份的情况下开始。”经过验证”意味着您已实际测试过恢复——而不仅仅是确认备份文件存在。

完整备份必须包含的内容

  • Web根目录文件——整个文档根目录，包括.htaccess和.env等隐藏文件
  • 所有数据库——以.sql转储形式导出，而非仅复制数据库目录文件
  • 电子邮件数据——如果您使用与域名绑定的电子邮件托管，请在任何DNS更改之前导出邮箱
  • Cron任务——crontab -l > crontab_backup.txt
  • SSL证书和私钥——如使用商业证书，请导出完整证书链
  • 服务器配置文件——/etc/nginx/、/etc/apache2/、/etc/php/、自定义my.cnf设置

执行数据库导出

对于MySQL/MariaDB，使用mysqldump并附带保留完整保真度的选项：

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

--single-transaction标志对InnoDB表至关重要——它在不锁定表的情况下获取一致快照，这意味着您的线上网站在转储期间可继续响应请求。

验证备份完整性

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

未经恢复测试的备份不是备份——而是虚假的安全感。

第四阶段：在目标服务器上验证兼容性

在传输生产数据之前，先启动新环境并使用预发布方式验证兼容性。

PHP版本和扩展验证

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

将此输出与第一阶段的清单进行对比。任何缺失的扩展必须在迁移前安装，而非迁移后。

数据库兼容性检查

如果从MySQL 5.7迁移到MySQL 8.0（常见场景），请注意以下重大变更：

  • utf8mb3字符集已弃用；列可能需要显式字符集声明
  • GROUP BY行为已更改——在5.7中有效的查询在8.0中可能在不调整ONLY_FULL_GROUP_BY模式的情况下失败
  • NO_ZERO_DATE在严格模式下默认启用，会拒绝包含0000-00-00的日期字段

在切换生产流量之前，请针对目标MySQL版本测试您的SQL转储。

Web服务器配置转换

如果从Apache迁移到Nginx（迁移到性能优化VPS时的常见场景），您的.htaccess规则不会自动转换。常见转换：

Apache .htaccess重定向：

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Nginx在server块中的等效配置：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

遗漏此转换是迁移后出现404错误和重定向循环最常见的原因之一。

第五阶段：以最小化停机时间执行迁移

策略性选择迁移窗口

分析您的Google Analytics或服务器日志，找出流量最低的时间窗口——通常是主要受众所在时区周二或周三凌晨02:00至05:00之间。避免周五；如果出现问题，周末的支持选项会大幅减少。

预发布优先的迁移工作流

  1. 将子域名指向新服务器（如staging.example.com），使用A记录，不触动生产DNS
  2. 将所有文件和数据库传输到新服务器
  3. 更新应用程序的数据库连接字符串，指向新数据库
  4. 修改本地/etc/hosts文件，将生产域名解析到新服务器的IP——这样您可以在不影响线上用户的情况下测试完整的生产配置：
# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com
  1. 运行完整功能测试——每个表单、支付流程、登录系统、API端点和媒体上传
  2. 使用ab（Apache Benchmark）或wrk运行性能基准测试：
ab -n 1000 -c 50 https://example.com/
  1. 仅在通过所有测试后，才进行DNS切换

SSL证书配置

确保在DNS切换之前，SSL证书已在新服务器上安装并验证。如果使用Let’s Encrypt：

certbot --nginx -d example.com -d www.example.com

如果使用通过SSL证书等服务商提供的商业证书，请安装完整的证书链（证书+中间CA+根CA），以避免旧版客户端出现链验证错误。

第六阶段：DNS切换——技术上最敏感的步骤

DNS传播被普遍误解。48小时的说法是最坏情况的上限，而非典型时长。实际上，大多数解析器会遵守被更改记录的TTL值。

切换前降低TTL

在迁移窗口至少24–48小时前，将A记录和CNAME记录的TTL降低至300秒（5分钟）：

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

这意味着在您将记录更新为新IP后，大多数解析器的旧缓存值将在5分钟内过期——而非48小时。这是最小化DNS传播窗口最有效的单一技术手段。

名称服务器与A记录更新

DNS切换有两种不同方式：

  • 仅更改A记录（保持相同的权威名称服务器）：传播遵循记录的TTL。如果您的域名注册商允许直接记录管理，这是最快的方式。
  • 更改名称服务器（指向新主机的DNS）：名称服务器TTL通常为24–48小时，不在您的直接控制范围内。此方式耗时更长。

尽可能优先选择A记录更新。通过您的域名注册控制面板管理域名DNS，以实现记录级别的直接控制。

传播期间保持旧服务器运行

DNS切换后不要立即取消或关闭旧托管套餐。至少保持运行72小时。在传播期间，部分用户仍会解析到旧IP——这些请求必须继续得到响应。过早关闭旧服务器会对这些用户造成真实的服务中断。

第七阶段：迁移后监控与验证

正常运行时间和性能监控

在DNS切换后立即配置外部正常运行时间监控——而非等到您认为传播完成之后。需部署的工具：

  • UptimeRobot或Better Uptime——每1–5分钟从多个地理位置进行HTTP(S)检查
  • Google Search Console——在迁移后7天内关注覆盖率和Core Web Vitals报告中的异常
  • New Relic或Datadog——如果您的应用程序有需要，进行应用程序级性能监控

识别和解决迁移后错误

使用Screaming Frog或wget mirror立即对新网站进行爬取：

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

常见迁移后问题及其原因：

问题可能原因解决方案
———
所有页面404`.htaccess`缺失或mod_rewrite未启用恢复`.htaccess`，启用`AllowOverride All`
数据库连接错误配置文件中凭据错误更新`wp-config.php`或`.env`
混合内容警告数据库中硬编码的`http://` URL对数据库执行搜索替换
邮件无法发送新服务器上未配置SMTP中继配置Postfix或使用SMTP插件
图片损坏文件权限不正确`find /var/www -type f -exec chmod 644 {} ;`
重定向循环SSL重定向在`.htaccess`和Nginx中重复删除重复的重定向规则

修复WordPress数据库中的硬编码URL

一个常见且隐蔽的问题：WordPress将网站URL存储在数据库中，许多主题和插件将绝对URL存储在序列化数据中。迁移到新域名或协议后，运行：

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

--precise标志能正确处理PHP序列化数据，而简单的字符串替换会破坏序列化数据。

第八阶段：取消旧托管套餐

仅在确认以下所有条件后，才取消旧套餐：

  • DNS传播完成（通过dig +trace example.com从多个位置验证）
  • 正常运行时间监控显示至少连续72小时100%可用
  • 爬取日志中未检测到404错误或失效链接
  • 电子邮件在新服务器上正常投递
  • 分析数据显示正常流量模式，无异常下降
  • 您拥有独立于任何托管服务商的所有备份文件的本地副本

技术要点检查清单

将此作为您的迁移执行检查清单：

迁移前

  • [ ] 已导出90天资源使用基准（CPU、RAM、I/O、带宽）
  • [ ] 已记录完整软件栈及确切版本号
  • [ ] 已在切换前至少24小时将DNS TTL降低至300秒
  • [ ] 已创建并测试完整备份（文件+数据库+Cron任务+电子邮件）
  • [ ] 已在目标服务器上验证PHP版本和所有必需扩展
  • [ ] 如切换Web服务器，已将.htaccess规则转换为Nginx格式
  • [ ] 已在DNS更改前在新服务器上安装并验证SSL证书

迁移中

  • [ ] 已使用rsync并附带校验和验证（rsync -avz --checksum）传输文件
  • [ ] 已导入数据库并验证行数与源数据库匹配
  • [ ] 已在DNS更改前通过/etc/hosts覆盖测试完整网站功能
  • [ ] 已更新应用程序配置文件（数据库主机、凭据、网站URL）

迁移后

  • [ ] 外部正常运行时间监控在DNS切换后5分钟内启动
  • [ ] 切换后旧服务器至少保持运行72小时
  • [ ] 完成完整网站爬取；所有404错误和失效链接已解决
  • [ ] 数据库中的硬编码URL已更正（尤其是WordPress）
  • [ ] 迁移后7天内持续监控Google Search Console
  • [ ] 仅在以上所有项目确认后才取消旧托管套餐

常见问题

DNS传播实际需要多长时间，我能加快它吗？

DNS传播时长由被更改记录的TTL值决定，而非固定的48小时窗口。如果您在迁移前至少24小时将A记录TTL降低至300秒，大多数解析器将在更改后5–10分钟内获取新IP。48小时的说法适用于名称服务器委派更改，其TTL不在您的直接控制范围内。

迁移到新主机会影响我的Google搜索排名吗？

正确执行的迁移——无停机、保留URL结构、有效SSL——对SEO没有负面影响。如果新服务器速度较慢、URL在没有适当301重定向的情况下发生变化，或网站在爬取期间无法访问，排名可能会暂时下降。迁移后14天内监控Google Search Console的覆盖率和Core Web Vitals报告。

在不损坏数据的情况下传输大型数据库最安全的方法是什么？

对InnoDB表使用带--single-transaction标志的mysqldump，以确保在不锁定表的情况下获取一致快照。通过SSH使用scp或rsync传输转储文件，而非使用phpMyAdmin——后者有文件大小限制和超时限制，会导致大型数据库出现无声截断。

迁移后需要重新安装SSL证书吗？

是的。SSL证书与服务器的私钥绑定，私钥存储在原始服务器上。您必须在新服务器上重新颁发证书（Let’s Encrypt免费），或从旧服务器导出私钥和证书链并安装到新服务器上。确保在更新DNS之前证书已完全验证，以便切换后HTTPS立即生效。

如何在取消旧套餐之前验证迁移已完成？

运行dig +trace example.com @8.8.8.8和dig +trace example.com @1.1.1.1，确认Google和Cloudflare解析器均返回新服务器的IP。检查正常运行时间监控，确保连续72小时响应正常。爬取网站检查404错误并验证电子邮件投递。只有在所有这些检查通过后，才可以安全地终止旧托管账户。

15%

全场主机优惠15%

测试技能，享折扣

使用代码：

Skills
开始使用