域名切流会改变用户访问入口，但请求是否成功还取决于DNS缓存、代理配置、证书、Host路由和后端依赖。稳妥计划需要先验证目标源站，再分阶段引流，并事先写明停止和回退条件。小团队可以用一张时间线记录解析变化、观测指标、操作人和决策结果，避免只凭“首页能打开”判断切换完成。🌐
记录根域名、www、API和管理子域名的A、AAAA、CNAME、TTL、代理模式及当前源站。不同子域名可能走CDN、负载均衡或独立应用，不能假设路径相同。保存证书主体、有效期、SNI要求、健康检查设置和缓存策略，并确认谁能修改DNS、代理及证书。
切流前检查：验证旧源站仍可访问、配置快照可读，且旧端能承接回流请求。确认域名管理权限、变更审批和紧急联系人可用；若记录受托管平台或其他团队管理，提前确认变更流程。
可使用专用测试域名、受控客户端解析或少量内部流量验证目标端。测试时保持正确的Host与SNI，检查证书链、重定向、登录、关键页面、静态资源、API健康状态和错误日志。若请求通过代理，还要核实代理传给源站的Host头与预期一致。
先检查TLS握手和域名匹配，再查看源站访问日志是否收到测试请求。核对页面依赖的CSS、图片和API是否从正确路径返回。避免用会增加浏览量、提交表单或触发业务写入的页面做无意测试；对这类流程使用专门测试账号和明确的清理方案。
根据系统架构选择低风险阶段，例如先切非关键子域名、内部流量或代理支持的少量比例，再逐步扩大。每一阶段记录变更时间、预期流量、解析结果、错误率、响应时间、回源状态、缓存命中和服务器日志。观察窗口应覆盖DNS更新和业务负载变化，不要在没有证据时连续修改多个变量。
一人负责操作、一人负责观察和记录，能减少遗漏。每个阶段结束后由明确的负责人决定继续、暂停或回退；阈值和观察时间应在变更前写入计划。
暂停信号：关键路径持续失败、5xx或延迟明显偏离基线、证书报错、回源日志缺失，或新旧请求行为与预期不符。
出现异常后暂停扩大范围，保存客户端解析结果、请求时间、响应码、代理日志和源站日志。按DNS解析、CDN或代理、TLS与Host、应用服务、数据库和外部依赖逐层检查。一次只改一个主要变量，避免切换解析、证书和缓存后无法判断哪项导致问题。
恢复旧链路后，实际验证用户路径已回到旧端；解析记录改变不代表所有递归缓存立刻更新。可从不同网络或地区检查解析状态，但区分DNS结果与真实请求落点。记录仍受旧TTL或缓存影响的范围。
方案应写明旧记录值、操作入口、回滚责任人、审批方式、操作时限和验证步骤。保持旧源站运行一段约定窗口，并确保防火墙、证书和依赖允许回流请求。若新端已经产生数据库写入或用户提交，需要明确这些数据如何保留、对账或同步，避免回切后丢失状态。
DNS回滚可能受缓存时间影响；代理或CDN回源变更也可能有单独生效过程。不要把“记录改回去”视作回滚完成，必须从外部客户端重新检查解析、响应、日志与业务状态。
切换稳定后，检查不同子域名、地区解析、静态资源、告警、访问日志和账单路径。按约定保留旧源站与配置，直到观察窗口结束且负责人确认无回流需求；随后再清理测试域名或临时规则。归档时间线、异常及处理结果，方便后续变更复用。
提醒：域名切流不是一次DNS修改。解析、代理、证书、源站和数据回滚都要分别验证，旧端可用才有实际回退能力。
把继续条件写成可观测指标，把回滚写成具体动作，再按小范围逐步验证，能让切流的每个判断都有证据。🔁
