子域名解析：发布系统把配置覆盖回旧值时怎样追踪来源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /2b981108ffdf.html
📄
子域名解析：发布系统把配置覆盖回旧值时怎样追踪来源
先给结论：当发布系统把子域名解析配置覆盖回旧值，追踪来源的关键不是反复改回新值，而是先判断覆盖发生在“解析记录层”还是“发布产物层”。前者要查谁持有该子域名的写入权限和自动化任务，后者要查发布流水线里哪一步重新生成了旧配置。两种情况的证据和处置动作完全不同，选错方向会陷入改了又回、回了又改的循环。
先分清两类覆盖：记录被回写，还是文件被重新生成
子域名解析通常涉及两个位置：DNS 服务商处的解析记录，以及你仓库或发布系统里保存的配置文件。覆盖回旧值可能只发生在其中一处，也可能两处同时发生，但触发机制不同。
- 记录层覆盖：DNS 里指向新目标的记录被改回旧 IP 或旧 CNAME。常见原因是另一套自动化脚本、旧账号的定时任务，或仍有人用旧值手工提交。
- 产物层覆盖：仓库里的配置文件本身被回退，发布系统只是忠实执行。此时 DNS 记录没被动过，是发布流程重新生成了旧值。
判断方法：在覆盖发生后立刻对比“DNS 当前值”和“仓库最新提交里的值”。如果两者一致且都是旧的，问题在产物层；如果 DNS 是旧的、仓库是新值，问题在记录层。这一步决定了后面查谁。
条件一：只有 DNS 记录被回写时的追踪动作
适用前提是仓库配置仍是新值，只有解析服务商处的记录变旧。此时把注意力放在写入权限和自动化来源上。
- 查看 DNS 服务商的变更记录或审计日志，确认最近一次写入的时间、来源账号或 API 标识。多数服务商会保留操作记录，这是最直接的证据。
- 核对是否还有第二套发布流程、旧 CI 任务或第三方集成持有该子域名的写入令牌。一个子域名被两个系统同时管理，是回写的高发原因。
- 临时收紧权限：暂停可疑的自动化任务，只保留一条人工写入路径，再观察是否仍被覆盖。
实施动作的结果会直接影响下一步：如果暂停某个任务后不再回退，来源基本锁定，接下来是迁移或废弃该任务；如果仍然回退，说明还有未发现的写入方，需要继续从审计日志里找时间规律，而不是继续猜测。
条件二：发布产物本身就是旧值时的追踪动作
适用前提是 DNS 记录与仓库配置一致，且都是旧值。这说明覆盖发生在代码或构建阶段，DNS 只是被动结果。
- 用版本历史定位是哪一次提交把配置改回旧值，重点看合并请求、自动格式化工具或模板渲染步骤。
- 检查构建流程是否从某个“默认模板”或上游数据源重新生成配置。如果新值只写在生成产物里、没写进模板，下次构建就会退回旧值。
- 把新值写进源头模板或变量，而不是只改生成后的文件，然后重新触发一次完整发布。
这里有个容易忽略的例外：如果发布系统带缓存或分阶段推送，旧值可能来自尚未刷新的中间层，而不是真的被重新生成。此时清缓存或等待推送完成后复查，比继续改配置更有效。
一个假设例子：用时间线缩小范围
假设某子域名每天早上指向新地址、下午退回旧地址。可以假设这是定时任务造成的，但不要直接下结论。做法是把三次覆盖的时间点、当时 DNS 值和仓库提交号列成一条时间线。如果回退总发生在某个固定时刻，且该时刻附近有自动化任务运行记录，记录层覆盖的可能性上升；如果回退总发生在某次合并之后，且合并提交里包含旧配置，产物层覆盖的可能性上升。这个对比只用来说明排查方法，不代表真实项目结果。
追踪时容易误判的几种现象
- 变更日志为空不等于没人改，可能是通过 API 或未开启审计的通道写入。
- 缓存未刷新会让人误以为配置被覆盖，实际源头仍是新值。
- 某次抓取或请求量归零，不能单独证明覆盖已被修复，也可能只是抓取节奏变化。
- 把 HTTPS 或站点地图当成保护手段没有依据，它们不阻止配置被回写，也不保证收录结果。
追踪的终点是找到“谁在什么条件下写入旧值”，而不是让当前值看起来正确。只有定位到写入方或生成源头，才能避免下一次覆盖，也才能决定是收紧权限、修改模板，还是废弃多余的自动化流程。
