IP反查域名，小流量灰度为何会暴露全量发布的例外
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /7cc8d87e07cd.html
📄
IP反查域名，小流量灰度为何会暴露全量发布的例外
灰度只覆盖一部分 IP 时，反查结果正常，不代表全量发布后所有 IP 都正常。最容易被漏掉的例外，通常来自灰度没有命中的 IP 段、共享出口或未同步的解析记录。你应先保留灰度证据，再决定改写规则还是退出本次发布。
灰度通过但全量异常，先分清三种原因
小流量灰度验证的是被选中的那部分 IP 与域名对应关系，而全量发布面对的是完整地址集合。两者不一致时，原因通常落在三类：
- 覆盖范围不同：灰度只挑了少数 IP，全量里还有未验证的地址段，这些段的反查记录可能缺失或指向旧域名。
- 共享出口：同一出口 IP 被多个域名共用，灰度期间只看到其中一个域名的解析，全量时其他域名也出现，反查结果自然变多。
- 记录未同步：反向解析记录（PTR）与正向解析更新节奏不同，灰度窗口太短，没等到同步完成就放行。
判断依据是：把灰度命中的 IP 列表和全量 IP 列表做差集，再对差集里的地址单独做一次反查。如果异常只出现在差集里，问题在覆盖范围；如果差集和交集都异常，问题更可能在共享出口或同步延迟。这一步不需要完整权限，只要能导出两份 IP 清单即可。
保留、改写还是退出：各自的适用前提
发现例外后，不要默认回滚。三个方向的适用条件不同：
- 保留：例外 IP 数量少、且不影响目标域名的正向解析。前提是你能确认这些 IP 不属于本次发布要覆盖的范围。保留后应把它们记录为例外清单，下一步只监测这些地址，而不是重跑全量。
- 改写：反查规则本身写得太宽，把共享出口里的其他域名也纳入。前提是你能区分哪些域名属于本次发布、哪些只是同 IP 邻居。改写后重新跑一次差集，确认例外被排除。
- 退出：例外集中在核心 IP 段，且正向解析也受影响。前提是灰度没有覆盖这些段，你无法在发布窗口内验证。退出后先补一轮针对这些段的小流量灰度，再决定是否重发。
一个假设例子：某次发布涉及 200 个 IP，灰度只选了其中 20 个。全量后反查发现另外 30 个 IP 仍指向旧域名。此时保留不成立，因为旧域名仍在响应；改写也不成立，因为规则没有错；退出更合适，因为灰度从未覆盖这 30 个地址。补跑一轮只针对这 30 个 IP 的灰度，观察 PTR 是否更新，再决定重发范围。
缺少权限时，仍可执行的最小动作
没有完整 DNS 权限或日志权限时，仍能做两件事：
- 用公开的反查接口对全量 IP 逐个查询，把结果与灰度结果比对，输出差集清单。这个动作只依赖公开解析，不需要写权限。
- 对差集里的每个 IP，记录它当前反查到的域名、查询时间、以及是否属于本次发布范围。时间戳用来区分“从未更新”和“更新滞后”。
这两步的结果直接决定下一步：如果差集里大部分 IP 的反查域名与目标一致，只是时间戳较新，说明是同步延迟，可以继续观察；如果差集里出现完全无关的域名，说明覆盖范围判断有误，应回到退出或改写。
这些现象不能单独证明处理正确
反查请求量下降、抓取量归零，都不等于例外已经解决。请求量下降还可能是因为查询方换了接口、缓存生效、或监测任务本身停了。要区分这些解释，需要同时看正向解析是否恢复、差集 IP 是否减少、以及查询时间戳是否推进。只有三者同时变化，才能说明例外在收敛。
另外，robots.txt 限制抓取不等于索引被移除，站点地图提交也不保证收录。如果例外涉及搜索引擎对旧域名的处理，这些手段都不能替代对反向解析记录本身的核查。不同搜索引擎对反查结果的使用方式不同，需要分别确认，不能用一个平台的表现推断另一个。
灰度通过只说明被选中的那部分 IP 在观察窗口内没有暴露问题。全量发布后，先把差集找出来，再根据例外是集中在未覆盖段还是共享出口，选择保留、改写或退出。动作的结果会直接改变下一步：差集缩小就继续监测，差集不变就补灰度，差集扩大就退出并重新划定发布范围。
