发现域名在国内外返回不同 IP，先不要急着修改 DNS 或宣布域名被污染。解析答案、缓存状态和网站是否能正常使用，是三个需要分别核对的问题。正常的服务调度可能产生不同答案；有解析答案的网站，也可能在连接、TLS 或应用阶段失败。
本文帮助网站维护者整理这些线索，并选择下一步检查。它不会把 IP 差异当作 DNS 污染的判断依据；针对域名的污染分类，应查看专门检测返回的结果。
1. DNS Resolve 与 DNS 污染检测回答不同问题
WeaveBit API v2 的 DNS Resolve 用于观察所选检测网络下的解析状态和 A 记录。成功表示该次请求获得了解析结果，不表示网站能打开，也不等于已经完成 DNS 污染检查。DNS 污染检测则提供独立的场景判定，应按其正常、明确异常、无法判定结果处理。
不要把“返回了 IP”写成“没有污染”，也不要把“国内外 IP 不一样”改写成平台已确认异常。这些输出的适用边界见公开结果文档。如果主要问题是单个域名的污染状态，可以从DNS 污染检测入门开始。
2. 正常服务为什么可能返回不同地址
网站可能配置 CDN、负载均衡或地域调度，把用户导向不同服务入口。例如，Cloudflare 官方的 Geo steering 文档说明，服务可以为国家或地区配置不同流量池。这只是一个正常调度能力的例子，不代表所有 CDN 或域名都启用了同样策略。
维护自己的网站时，查看实际的 DNS 和 CDN 配置、CNAME 指向、地域策略以及近期变更记录。预期答案应由你部署的服务配置解释，不是把某次国外查询的 IP 当作永远正确的唯一地址。如果使用外部服务，向提供方核实对应配置，不要仅凭地址的地理标签判断故障。
3. TTL 不是全球更新完成的倒计时
DNS 允许缓存记录，TTL 描述记录可缓存的时间。RFC 1034也说明，分布式 DNS 不保证所有副本同时更新。因此，把 TTL 设置为 300 秒，不等于所有用户一定在五分钟后看到相同的新地址。
还要区分当前记录的 TTL、变更前旧记录的 TTL 和服务方配置发布过程。现在把 TTL 调低，不能追溯性地缩短已缓存的旧记录。DNS 缓存、浏览器资源缓存与 CDN 内容缓存不是同一回事；刷新网页或清除页面资源缓存，也不能证明解析答案已刷新。
迁移前可以按服务方建议提前规划 TTL 和验证窗口，但不要把一个固定等待时长写成全球生效保证。先记录配置与观测，再决定是否需要处理某个具体缓存层。
4. 改设置之前，保存原始现场
至少保留以下信息，后续才能判断变化来自哪里：
- 实际访问的域名和失败网址，区分主域名、
www、API 与静态资源域名。 - 查询或访问时间与时区、用户地区、运营商和接入方式，以及观测来自用户设备还是检测节点。
- 所用查询方式、查询的记录类型、返回状态和地址；若工具提供，再记录 TTL 和所用解析器。
- DNS/CDN 变更时间、旧配置与新配置，以及同期的浏览器错误或业务失败现象。
保留失败网络的第一次记录，再做同条件复测。不要先要求所有用户改 DNS、重启路由器和清空缓存；这些操作可能让现场消失，也让后续无法区分是缓存、网络还是业务配置发生了变化。
5. 按症状选择下一份证据
下面列出的是排查方向，不是 DNS 污染分类规则。不同答案与访问故障可以同时出现，但仅凭这张表不能确定两者存在因果关系。
| 看到的现象 | 优先补充什么 |
|---|---|
| 地址不同，业务均可正常使用 | 核对 DNS/CDN 调度与变更记录，保存观测基线；有污染疑问时单独检测 |
| 有解析答案，但连接或安全连接失败 | 保存具体错误，对实际域名和端口做全量检查，并核对服务端日志 |
| 解析返回错误或超时 | 核对域名拼写、记录配置和查询条件，保存状态，在原网络复测 |
“新 IP 已出现”不等于迁移成功，“旧 IP 仍出现”也不能直接解释为污染。对维护者而言，还要确认对应入口的证书、源站和业务是否已经准备好承接实际请求。
6. 用专门检测回答污染问题，用全量检查访问范围
打开免费 DNS 污染检测，输入纯域名并保存结果与可用的结果时间。正常时继续检查与用户症状相关的阶段；明确异常时保留证据并确认影响；无法判定时不要替它补上“正常”或“被封锁”的结论。页面可能复用已有结果，反复刷新不一定产生新观测。
如果涉及多个业务域名、地区或运营商，可直接用 GFW 全量检测，无需先逐个完成单独的 DNS 检查。它组合 DNS 污染、HTTP Host 与 TLS SNI 三个维度。根据当前节点覆盖选择相关网络，操作和端口说明见全量检测指南。
DNS Resolve 的查询条件只用于解释这类解析观测，不应被当作专门污染检测的内部判断步骤。程序需要接入时，按公开 API 契约区分检测方法、输入与返回字段，不自行把解析地址转换为污染判定。
7. 解析正常后，仍要检查实际业务链路
浏览器访问还会经过连接、TLS、HTTP、重定向和页面依赖。主域名的 DNS 结果正常，不能保证登录接口、脚本或图片所在域名同样可用。找出用户实际失败的请求，再检查相应目标，而不是只盯着首页的地址。
把失败时刻与 CDN、代理和源站日志对齐，确认请求是否到达以及服务端响应。GFW 全量的正常结果也不是浏览器端到端验收；证书配置和功能操作仍需验证。如果问题只发生在部分网络，继续使用地区与运营商对比指南收集同条件证据。
8. 有依据地变更，并验证原问题是否消失
只有在记录或服务配置确实不符合预期时，才针对该项调整；保留变更前后的配置和回退方案。每次改变一个因素，在原网络、原域名和原业务路径复测。需要清理缓存时，说明清理的是哪一层，并把清理后的观察与之前记录分开。
结束排查时，应同时说明解析状态、访问结果和覆盖范围：哪些用户操作恢复、哪些网络仍异常、哪些观测不足。不同 IP 是线索，不是结论；可信的处理路径是先保留证据，再核对服务调度与缓存背景，用对应检测回答对应问题。