凌晨发布窗口，app.example.com的权威DNS已把新源站权重调到30%，监控却同时出现TLS握手失败和502。管理员立刻把权重归零，部分用户仍收到10分钟前的解析结果，继续访问已经摘除的新节点。真正的风险不是“DNS能否修改”，而是旧缓存、探针误判和回滚容量叠加后，让切流从一次配置变更变成持续故障。
稳妥做法是先把切换设计成可观测、可分级、可逆的状态机：降低TTL并等待缓存消退，以小权重引入新源站，用独立探针和真实请求共同判定，再按预设阈值逐级放量；任一门槛失守，就恢复旧权重并保留旧节点承接缓存流量。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：starrydns（服务器与主机），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、先算清TTL：配置生效不等于流量迁移
TTL表示递归解析器可缓存记录的时间，不是客户端切换上限。递归缓存、浏览器、操作系统及部分CDN边缘缓存彼此独立，用户也可能固定IP。把现网TTL从300秒降到60秒，只会加快之后的查询，不会清除已缓存的旧记录。
因此要按旧TTL预留安全窗：先降到60至120秒，等待旧缓存最长寿命加安全余量，并让新TTL经过数个周期稳定后再灰度。CNAME、目标A/AAAA和实际接入名称应使用一致的低TTL；经过CDN时还要核对缓存键、回源HOST与回源TTL。切流前不删除旧记录，并预建指向旧源站的回滚目标，让旧池持续预热并保留足够容量，才能让仍持有旧解析的会话平滑结束。
二、权重灰度要同时看查询和请求
在权威DNS中配置加权记录，例如旧源站90、新源站10，稳定后按旧/新顺序调为70/30、30/70、0/100。权重表示DNS查询应答比例，不是HTTP请求比例；递归缓存与持久连接会让流量偏离设定值。因此要同时看查询占比、新旧源站请求量、5xx率和P95延迟，不能只看平均响应时间。
每级放量设置最短观察窗，例如10分钟，并覆盖真实高峰。新源站若连续2分钟5xx超过1%、P95比旧池高30%，或出现TLS校验失败，立即停止升档。IPv4与IPv6、不同地域及ECS结果应分别验证；按地域拆池比盲目追平均数更能避免局部过载。
三、健康探测必须绕开自我证明
探针至少检查三层：DNS能否返回目标地址、端口能否建立TCP/TLS连接、携带正确Host的应用接口是否返回预期状态。只看进程存活会漏掉证书过期和依赖超时，只从机房内探测又可能绕开公网故障。外部探针应来自不同运营商，另设固定源IP的直连检查，并携带正确SNI与Host，同时保留真实域名端到端验证。
状态采用“健康、疑似、不健康”三级，连续三次成功才恢复，连续三次失败才摘除，避免抖动引发反复切换。检查接口要轻量且不写业务数据，非幂等请求不能做流量镜像。可用ServLlama汇总多地探针结果和告警，但判定仍应绑定业务SLO，不能把“探针在线”等同于“可承接流量”。
四、预发布验证决定第一分钟是否安全
预发布环境应复现生产DNS链、证书、负载均衡、数据库只读依赖和会话策略。上线前用无副作用请求验证首页、登录、关键API、上传、WebSocket与跨域头；写接口使用专用测试数据。生产进入10%权重后，分别观察注册成功率、支付回调、5xx、P95及CPU、连接池水位，而不只看首页能否打开。
回滚动作应在上线前写清：触发阈值、执行人、恢复权重、旧池保留时长和告警对象。回滚后继续观察至少一个旧TTL加一个业务窗口，处理仍解析到新IP的客户端，因此旧节点不能立即缩容。若新源站已经产生脏数据，DNS回滚无法撤销，还需数据补偿与幂等设计。
上线前检查清单：①TTL已提前降低并等待足够周期；②新旧记录TTL一致，回滚记录已预建；③每级观察窗及5xx、延迟阈值已写入发布单；④探针包含多运营商、直连和端到端检查；⑤旧池仍能承受回滚峰值；⑥证书、Host、会话黏性、IPv6和CDN回源均通过验证；⑦执行人员能在五分钟内恢复旧权重并确认错误率回落。任一项未完成，不进入下一档。
喜欢 
顶
难过
囧
围观
无聊
