换主机切换当天要验哪几项，解析、证书和邮件都不能漏

更换主机切换当天要验证哪几项，解析、证书和邮件该怎么核？按访问链路排顺序验，而不是按后台功能表逐项点：先确认域名解析真的指向了新主机，再确认新地址上证书完整可用，然后验页面能否正常渲染（伪静态地址与规则是否匹配）、旧地址是否按永久跳转落到新地址，最后验写入侧——表单提交、评论留言、接口调用能不能落库。解析、证书、邮件这三项最常被漏，是因为它们不在站点程序里，而在主机与域名的边界上。

切换前：把备份和解析有效期先安排好

两件事必须在切换之前完成，当天补都做不了。

第一件是完整备份。备份与恢复支持数据连同静态文件一起备份和恢复，迁移场景必须包含附件与生成文件，只备数据库的恢复会留下图片缺失的半截状态。第三方迁移清单在这点上口径一致：备份要做，而且要做两份。

第二件是把解析记录的有效期提前调低。常规建议是在切换前 24 到 48 小时把 TTL 降到 300 秒，这样切换时旧记录的残留时间被压到最短；如果在切换当天才改，未过期缓存会把一部分访客继续送到旧主机，看起来像「切换失败」。

第三件是按部署方式把新环境提前拉起。使用 Docker 镜像部署的站点，新主机上按同一镜像运行、数据卷挂回即可；使用宝塔面板或 aaPanel 一键部署的站点，还要核对运行目录、监听端口与重写模块是否等价。部署方式不同，当天要验的项没有变化，但出问题的位置通常就在这层差异里。

切换当天：按访问链路逐项验

证书这一项要单独强调：新主机上的证书不止「有没有装」，还包括证书链是否完整、是否覆盖带 www 与不带的两种写法。链条缺失时桌面浏览器可能正常，移动端与接口客户端会直接报错。

伪静态规则与 301 跳转的核对顺序

主机迁移最常见的隐性故障不是内容丢了，而是地址规则没跟上。伪静态规则管理里的规则定义要随站点一起迁移，否则同一个页面既能以规范地址访问又能以参数地址访问，检索端会看到两份副本。核对顺序是：先看新主机上规则是否生效，再看站内生成的地址是否与实际可访问地址一致。

如果迁移同时换了地址写法，就要在旧地址一侧配 301 跳转。第三方清单的写法建议同样直接：用永久跳转，不要用临时跳转——临时状态长期不撤会让新旧两套地址并存。同理，旧主机账号不要当天退掉，常规做法是切换后保留至少一周，用来承接仍有缓存解析送来的访客，也作为回滚落点。

切换后一周：旧账号与日志观察

这一周看三件事：可用性记录、服务端日志、流量分布。可用性看有没有间歇性失败；日志看异常状态码集中在哪类地址；流量分布看是否仍有明显比例请求打到旧主机——若有，说明解析残留或外链仍指向旧地址。

邮件是典型的「当天看不出问题、一周后才爆」的项。发送身份相关的记录（SPF、DKIM、DMARC 三类）常跟着主机迁移一起被漏掉，因为它们在域名解析里而不是站点后台。验证方式不是看有没有配置，而是实际发出一封邮件并检查投递结果与身份校验是否通过。

验收清单

一、解析已全量指向新主机，多地域复核一致。二、新地址证书与证书链完整，两种域名写法都可访问。三、伪静态规则生效，规范地址与实际地址一致。四、旧地址按永久跳转落到新页。五、表单、留言、评论与接口写入均正常入库。六、邮件可正常投递，发送身份记录校验通过。七、旧主机账号保留一周以上，回滚路径已实测过一次。

常见问题

切换当天能不能先改解析再备份？ 不建议。备份必须在切换前完成，切换后出现异常时若无可用还原点，回滚就变成重建。

验证时页面显示旧内容怎么办？ 先分清是解析残留还是缓存未清。多次查询解析确认指向，再清页面缓存，两件事的处理位置不同。

旧主机账号提前退掉有风险吗？ 有。残留解析与外链仍会把请求送到旧地址，提前停用会直接变成不可访问，也失去回滚落点。

邮件没换服务商要不要管？ 要。即使邮件服务不变，域名侧的身份记录与解析仍受主机迁移影响，仍需实际发送验证一次。