网站迁移不是把文件和数据库复制到新服务器就结束。真正容易出问题的地方，往往出现在 DNS（域名解析系统）、SSL（安全传输协议）与邮件服务之间的联动：域名已经指向新 IP，但证书仍绑定旧环境；网站可以打开，但表单邮件收不到；主站访问正常，子域名或邮件记录却还停在旧服务器。本文是一份网站迁移后的检查指南，帮助你按顺序解决访问、证书和邮件投递问题，避免迁移窗口结束后才发现业务异常。
先确认迁移范围，避免只检查首页
网站迁移前后要先划清边界：这次迁移的是整站、某个子域名，还是只迁移 Web 服务而邮件继续留在原服务商。不同范围对应不同检查项。如果只迁移官网，DNS（域名解析系统）的 A 记录可能需要切换；如果连邮件也迁移，MX 记录、SPF 记录、DKIM 记录和邮件客户端配置都要同步检查。
迁移开始前建议保留一份基线记录，至少包括旧服务器 IP、新服务器 IP、主域名、www 子域名、常用子域名、MX 记录、TXT 记录、证书覆盖域名和计划切换时间。这个记录不需要复杂工具，一个表格就够，但每一项都要能回溯。等迁移后出现“只有部分用户打不开”或“邮件能收不能发”时，这份基线能快速判断问题在解析、证书还是邮件链路。
如果你使用的是 VPS（虚拟专用服务器）或独立服务器，迁移时还要确认新环境是否已经具备原站依赖，例如 Web 服务、PHP 版本、数据库版本、计划任务和防火墙规则。Hostease 在迁移类场景中通常建议先完成新服务器环境验证，再执行 DNS（域名解析系统）切换，因为解析一旦扩散，用户请求会直接进入新环境，留给现场排障的时间会明显变少。
第一步：检查 DNS（域名解析系统）是否按预期切换
DNS（域名解析系统）检查的目标不是“我这里能打开”，而是确认主域名、www、常用子域名和邮件相关记录都已经指向正确位置。迁移前可以把 TTL 调低到 300 秒或 600 秒，迁移完成并稳定 24 小时后再恢复到常用值。这样做可以缩短回滚窗口，但不会让全球解析同时生效，所以迁移当天仍要保留旧服务器一段时间。
你可以在本地终端分别验证主域名和 www 子域名：
dig example.com A +short
dig www.example.com A +short
dig example.com MX +short
dig example.com TXT +short
如果返回的 A 记录仍是旧 IP，要先判断是权威 DNS（域名解析系统）还没有改对，还是本地运营商缓存未刷新。可以换公共解析器对比，例如 dig @1.1.1.1 example.com A +short 与 dig @8.8.8.8 example.com A +short。两个公共解析器都返回新 IP，而你本地仍返回旧 IP，多半是本地缓存问题；如果公共解析器也返回旧 IP，就要回到 DNS（域名解析系统）控制台检查记录值。
迁移后还要检查是否存在隐藏的子域名依赖。常见例子包括 api.example.com、cdn.example.com、mail.example.com、autodiscover.example.com。如果这些记录没有跟着更新，首页可能正常，但支付回调、图片加载或邮件客户端自动发现会失败。涉及网站性能和缓存链路时，可以参考 网站优化相关实践 进一步排查首字节时间、缓存命中和回源路径。
第二步：确认 SSL（安全传输协议）证书覆盖新访问路径
DNS（域名解析系统）切到新服务器后，浏览器会把 HTTPS 请求发到新环境。此时 SSL（安全传输协议）证书必须已经安装在新服务器，并且覆盖用户实际访问的域名。只给 example.com 安装证书，但用户访问 www.example.com，浏览器仍会提示证书名称不匹配。
检查 SSL（安全传输协议）时，至少看 4 个点：证书域名是否匹配、证书是否过期、中间证书链是否完整、强制 HTTPS 跳转是否正确。可以用下面命令查看证书返回情况：
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates
curl -I https://example.com
curl -I https://www.example.com
如果 curl -I 返回多次 301/302 跳转，或从 HTTPS 跳回 HTTP，要检查 Web 服务配置、站点后台地址和反向代理规则。WordPress 站点还要确认站点地址已经从旧域名或临时域名改为正式 HTTPS 地址，否则页面资源可能混用 HTTP，引发浏览器的混合内容警告。更多建站环境相关内容可以延伸阅读 WordPress 主机方案 与 虚拟主机方案 的适用场景说明。
SSL（安全传输协议）问题还有一个常见误区：证书在控制面板里显示已签发，不代表公网访问已经使用这张证书。新服务器上可能有多个虚拟主机配置，默认站点证书和目标站点证书并不相同。用 -servername 指定域名检查，能避免只看到默认站点证书而误判。
第三步：把邮件服务单独当成一条链路检查
很多迁移事故不是网站打不开，而是邮件突然丢失。原因通常是 Web 服务迁走了，但 MX 记录仍指向旧邮件服务器；或者邮件服务器也迁走了，但 SPF、DKIM、DMARC 没有同步更新。邮件链路不应该附带在“网站能访问”这个结论里，而要单独验证收信、发信、表单通知和客户端登录。
最小检查范围可以按 4 项执行：
- MX 记录：用
dig example.com MX +short确认收信入口是否仍是计划中的邮件服务器，优先级数值也要保留原设计。 - SPF 记录：用
dig example.com TXT +short查看是否包含新发信服务器 IP，避免外发邮件被收件方判为伪造。 - DKIM 记录：确认选择器记录仍能查询到公钥，例如
dig selector._domainkey.example.com TXT +short。 - 表单邮件：从网站前台提交一次联系表单，并检查收件箱、垃圾箱和服务器邮件日志，记录测试时间点。
如果迁移后网站表单发送失败，要分清是 Web 应用没有发出邮件，还是邮件服务拒收。应用层可以看日志里是否出现 SMTP 连接错误、认证失败或超时；邮件服务层则要看 SPF、DKIM 和反垃圾策略。对于业务邮箱依赖较重的网站，我们建议在 DNS（域名解析系统）切换后保留旧邮箱服务至少 24-48 小时，并设置测试账号持续收发，避免客户询盘在切换期丢失。
如果你正在规划主机环境，可以根据站点规模选择 VPS 主机 或 独立服务器；前者适合希望独立控制运行环境的中小型站点，后者更适合资源占用高、业务系统多、邮件和 Web 服务需要更明确隔离的场景。选择哪一种并不只看 CPU 或内存，还要看迁移时是否方便保留旧环境、是否能快速回滚、是否有足够权限查看邮件和 Web 日志。
第四步：设置观察窗口和回滚条件
迁移完成后不要马上关闭旧服务器。比较稳妥的做法是保留 24-72 小时观察窗口，具体时间取决于 TTL、访问地区、业务高峰和邮件依赖。如果网站有外贸客户，跨时区访问会让问题暴露得更慢；如果有支付、CRM 或邮件营销系统，观察窗口也应该更长。
观察期间可以把问题分成三类处理：访问类看 HTTP 状态码、SSL（安全传输协议）证书和静态资源加载；数据类看订单、表单、评论和后台写入；邮件类看收信、发信、退信和垃圾箱命中。每一类都要有可验证指标，例如首页返回 200、后台登录成功、测试订单写入数据库、联系表单在 5 分钟内送达。
回滚条件也要提前写清楚。比如连续 30 分钟出现大面积 5xx，或核心表单邮件在两轮测试中都无法送达，就暂时把 A 记录切回旧服务器，并保留新环境日志继续排查。回滚不是失败，而是让业务先恢复，再把问题留在可控环境里解决。
总结：迁移完成后的检查顺序
网站迁移后的核心建议是按链路检查，不要只看首页。先确认 DNS（域名解析系统）把用户带到正确服务器，再确认 SSL（安全传输协议）让浏览器安全访问，最后单独验证邮件服务是否还能稳定收发。三条线都通过后，再进入 24-72 小时观察窗口，逐步恢复 TTL、关闭旧环境或调整备份策略。
如果你需要迁移的是业务站、外贸站或 WordPress 站点，可以考虑在迁移前准备一份包含解析、证书、邮件和回滚条件的清单。这样做的价值不在于流程更复杂，而在于每一步都能验证、能回退、能定位责任点。对中小团队来说，一次迁移顺利完成，往往来自切换前的准备和切换后的耐心观察。