📍 WDQWDWQD987AAAAA:216.73.217.89
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /468ca0d67bd6.html
📄

子域名解析：怎样判断是否需要回退

判断子域名解析是否需要回退，核心看三件事：旧解析目标是否仍在提供服务、回退后能否恢复业务、以及回退是否会带来新的冲突。只要新解析导致关键访问失败、证书不匹配或邮件中断，而旧记录仍有效，就应优先回退；如果只是个别地区解析慢、缓存未过期，通常先等待或局部修正，不必整体回退。

先确认故障是否真的由解析引起

要查的是：访问失败时的具体表现，以及解析结果与预期是否一致。用 nslookup 子域名 或 dig 子域名 查询 A、AAAA、CNAME 记录，再用在线 DNS 检测工具从多个地区查看返回结果。如果返回的 IP 或目标主机与本次变更一致，且变更前可访问、变更后失败，可以判断解析变更与故障高度相关。若返回结果仍是旧值，问题更可能在缓存、服务器或网络链路，此时回退解析未必有效。

核对旧解析目标是否还能承接流量

要查的是：旧 IP、旧 CNAME 目标、旧服务器是否仍在线，证书是否覆盖该子域名，后端服务是否还在运行。直接访问旧目标地址，检查 HTTP 状态码、证书有效期与页面内容。结果说明：旧目标可用，回退能快速恢复；旧目标已下线或证书过期，回退只会把故障换一个形式，应先修复旧目标或改用其他方案。

区分缓存、TTL 与传播延迟

要查的是：变更前设置的 TTL 值、当前已过去的时间、不同递归解析器的返回差异。TTL 为 300 秒时，多数缓存会在数分钟内更新；TTL 为 86400 秒时，完全传播可能接近一天。如果只有部分网络返回旧值，属于正常传播过程，可继续观察；如果所有网络都返回新值但业务仍失败，说明问题不在传播，而在新目标本身，这时才需要考虑回退。

检查回退会不会引发新的冲突

要查的是：旧记录是否已被其他服务占用、邮件相关记录是否依赖该子域名、CDN 或证书绑定是否已切换。例如子域名同时用于网站和邮件验证时，回退 A 记录可能不影响 MX，但回退 CNAME 可能让验证再次指向旧目标。结果说明：回退前应列出所有依赖该子域名的服务，确认回退不会破坏其他已生效的配置。多人协作时，把这份依赖清单写进交付说明，能减少后续返工。

可执行判断清单

1. 查故障范围：是全部用户还是部分网络；全部失败偏向解析或目标故障，部分失败偏向缓存或链路。
2. 查当前解析：用 dig 对比权威服务器与公共解析器的返回，确认是否已按变更生效。
3. 查旧目标：访问旧 IP 或旧主机，确认服务、证书、端口均可用。
4. 查 TTL：计算变更后经过的时间，判断是否仍在合理传播窗口内。
5. 查依赖：列出该子域名关联的网站、邮件、验证、CDN 等用途，评估回退影响。
6. 做决定：新目标故障且旧目标可用时回退；仅传播延迟时等待；旧目标不可用时先修复再切换。

下一步，把上述六项检查结果记录在同一份变更单里，明确回退触发条件、执行人和观察时间，再决定是否操作解析。