网站域名解析上线切换：记录核对、证书与回滚顺序
先确认切换对象：不是所有“上线”都只改一条解析
网站从测试环境切到正式域名，常被概括为“改一下解析”。实际操作中，域名解析、HTTPS证书、CDN回源、跳转规则和邮件记录往往同时受影响。若只改A记录，而证书未覆盖带www的域名，或CDN仍指向旧源站，就会出现部分地区能打开、部分地区报错的情况。
判断依据不是“新服务器已经部署好”，而是三条链路都明确：用户访问的域名由哪家权威DNS负责；请求最终落到哪个源站或CDN；证书是否覆盖所有对外域名。把这三条写成一张清单，再决定切换顺序。
第一步：盘点账号、记录和依赖
先不要修改记录，先导出当前DNS配置，保留截图或区域文件。重点核对：
- 域名注册商与权威DNS服务商是否一致，登录账号是否可用，是否开启二次验证；
- A、AAAA、CNAME、MX、TXT、CAA等记录分别指向哪里，哪些用于网站，哪些用于邮箱、验证或子业务；
- 当前TTL值。TTL较长时，全球缓存不会立刻失效，应提前调整并等待旧缓存过期；
- 新源站IP或CNAME、CDN加速域名、回源协议，以及防火墙白名单；
- 证书覆盖的域名清单，包括裸域、www、接口域名和后台域名。
这一步最容易漏掉的是“非网站记录”。把MX和TXT一并改掉，可能网站正常、邮件却中断；把验证用TXT删掉，也可能影响第三方平台的所有权校验。切换单上应标明“保留不改”的记录。
第二步：在旧站仍可访问时完成新环境预检
正式改解析前，先用测试域名、Hosts绑定或带解析参数的请求访问新环境。不要等DNS切过去后才发现首页能开、表单不能提交。预检至少覆盖：
- 裸域和www是否都能访问，是否只保留一个主域名并正确跳转；
- HTTP到HTTPS的跳转是否只发生一次，避免在CDN、负载均衡和源站同时配置导致循环；
- 证书链是否完整，域名是否匹配，到期时间是否足够，中间证书是否部署；
- 登录、搜索、表单、支付回调、文件上传等关键路径是否可用；
- 页面中引用的图片、脚本、字体是否都使用HTTPS，避免混合内容拦截；
- 若使用CDN，缓存规则、回源Host和证书部署是否已经生效。
预检通过后再缩短TTL。通常提前一天左右把网站相关记录的TTL调低，并等待原TTL周期过去；但不同服务商的最小值和套餐限制不同，不能把“调低TTL”当成即时生效开关。
第三步：按依赖顺序切换，不要一次全改
建议先处理证书和源站，再改网站解析，最后处理跳转与缓存。顺序大致如下：
- 在新源站或CDN部署证书，确认HTTPS可访问；
- 修改网站相关的A、AAAA或CNAME记录，一次只改一组，保留旧记录值备查；
- 观察权威DNS是否已返回新值，再用多个公共解析器验证；
- 确认访问正常后，再启用HTTP到HTTPS跳转；
- 清理CDN缓存，检查页面资源和接口请求；
- 稳定运行一段时间后，再考虑开启HSTS等更强策略。
HSTS不要提前开。如果证书或跳转尚未稳定，浏览器记住强制HTTPS策略后，回滚会更麻烦。涉及includeSubDomains时更要谨慎，因为它会影响所有子域名。
第四步：上线后的验证要覆盖“人、搜索引擎和程序”
页面能打开只是最低标准。验证时可以从三类访问者出发：
- 普通访客：首页、栏目页、详情页、搜索页、表单提交和下载是否正常；移动端是否出现资源加载失败。
- 搜索引擎：robots.txt、站点地图、canonical和旧链接跳转是否指向最终域名，避免http、www、裸域多套地址并存。
- 程序调用：APP接口、小程序请求域名、第三方回调地址、Webhook白名单是否已加入新域名，证书是否被客户端信任。
同时检查DNS的MX记录是否仍在、邮件能否收发，服务器日志里是否有大量404、502或证书错误。若接入监控，至少观察一个业务高峰，而不是切换后十分钟就结束。
回滚不是“改回去”这么简单
切换前应约定回滚条件：核心页面持续无法访问、证书大面积报错、登录或提交主流程中断、关键接口不可用。出现这些情况时，优先恢复旧解析值，再排查新环境；不要在生产域名上反复试配置。
回滚时注意三点：旧源站和旧证书不要立即释放；CDN缓存要同步清理；若已经启用HSTS，需评估浏览器缓存影响。DNS回滚同样受TTL和递归缓存影响，因此“改回旧记录”不等于所有用户立刻恢复。
适用边界：复杂场景要单独做切换方案
上述顺序适用于常规企业官网、内容站和一般业务站点的域名切换。若涉及DNSSEC、CAA、邮件系统、大量子域名、跨境访问、多活架构或强合规要求，不能只靠一张解析清单处理，应分别做安全、邮件和流量调度评估。对于无法停机的重要系统，还应准备灰度流量和更长的观察期。
把切换当成一次有准备、可验证、可回退的交付动作，而不是一条记录的修改，才能减少“网站上线了，但部分用户打不开”的返工。