一个域名没有报告 DNS 污染，并不代表它在中国大陆的 HTTP 或 HTTPS 连接一定正常。用户仍可能遇到连接重置、握手失败，或者只有部分网络可以连接。WeaveBit 的 GFW 全量域名检测把 DNS 污染、HTTP Host、TLS SNI 三个维度放在同一项任务里，便于先定位值得继续检查的环节，再比较不同节点的结果。
这里的“全量”是这三个维度及汇总，不是全部七种 API 检测方法，也不是用浏览器完整加载网页。本篇介绍怎样整理目标、选择节点、执行批量检查以及复查异常。如果你只想先确认一个域名的 DNS 污染结果，可以从免费 DNS 污染检测开始。
先明确要回答的问题
检测前先写下一句业务问题，例如：“登录域名在主要客户使用的中国大陆网络上是否出现异常？”这比直接选择所有节点更有用。一个网站可能同时使用主站、登录、API、静态资源等多个域名；只检查首页域名，不能替代对这些依赖的检查。
把有权限检测的域名整理成清单，标明用途与负责人。输入应为纯域名，例如 www.example.com 或 api.example.com，而不是 https://www.example.com/login。去掉协议、路径、端口和重复项。国际化域名可能以小写 ASCII Punycode 返回，因此保留输入与规范化目标之间的对应关系。
如果问题涉及某个登录流程、接口参数或网页脚本，仍需配合业务日志和浏览器排障；GFW 域名检测不会登录账户、执行 JavaScript 或检查页面内容。
三个分项和汇总分别看什么
| 项目 | 查看重点 | 不要据此推断 |
|---|---|---|
| DNS 污染 | 服务返回的污染判定与结果状态 | 没有报告污染不等于 HTTP、TLS 或网页业务正常 |
| HTTP Host | 带目标 Host 的 HTTP 请求状态 | 获得合法响应不保证返回 200，也不保证网页内容正确 |
| TLS SNI | 带目标 SNI 的 TLS 握手状态 | 握手成功不保证登录、API 请求或完整证书审计通过 |
| 汇总 | 先筛选需要关注的目标，再展开分项 | 汇总不能替代分项、节点和检测时间 |
提供域名后，读取服务返回的公开结果，具体状态见结果文档。不要自行把超时、未知或无法判定改写成“正常”或“已封锁”。
选择适合你的执行入口
需要平台按计划持续检查并发送通知时，进入Console 监控入口，创建 GFW 全量任务。Console 当前提供 DNS 污染与 GFW 全量两种监控任务，每个任务最多 200 个域名。根据实际业务拆分任务，例如把登录与 API 域名放入较重要的任务，把其他域名单独管理。
需要一次性批量检查，或把检测嵌入自己的系统时，使用 API v2 的 gfw_full_domain_check。每次预估或创建可提交 1–1000 个目标。API 批次与 Console 定时监控不是同一种任务；API 不会因为创建了一个批次就自动替你持续监控。完整操作见DNS 与 GFW 批量 API 指南。
按用户网络选节点，不只按数量选
先看客户主要来自哪些地区、使用哪些运营商，再查看当前节点覆盖。优先选与这些用户环境相关的可用节点。如果不知道用户网络，可以先选具有代表性的节点获取初步范围，再按实际反馈补充；不要把一个节点的结果推广到整个中国大陆。
对同一批目标进行比较时，尽量保持目标、端口、节点组合和检查时间接近。发现某个节点异常后，可以用相同配置复查，再增加相关网络的节点作对照。增加节点会改变观测范围，也可能改变费用；更多节点不是对所有终端环境的覆盖保证。
API 接入时，通过 /task/get_nodes 获取当前节点代码，使用 node_id 而不是显示名称。父节点会展开为当前可用子节点，节点可用性也会变化，因此创建前应重新核对选择并预估费用。单独的 DNS 污染 API 请求则不传 nodes。
GFW 全量 API 的 HTTP 与 TLS 端口默认分别为 80 和 443。如服务使用其他端口，在对应目标对象中填写 http_port、tls_port，不要把端口附在域名后。使用相同端口复查，才能进行有意义的比较。
在 Console 中建立一项可复查的任务
- 登录 Console，确认余额，并选择 GFW 全量监控任务。
- 填写去重后的域名清单，检查是否把 URL、端口或其他字符误填进域名。
- 选择与客户网络相关的节点；按当前任务编辑页的选项配置频率，兼顾发现速度与预算。
- 如需告警，先确认联系人与通知设置，再保存任务。
- 等待任务产生结果，查看汇总后展开目标、节点和各检测分项；同时检查任务是否持续执行。
不要为了获得一个“绿色结果”反复更换节点。保留最初异常的时间与配置，才能区分结果变化和观测环境变化。任务的持续监控与告警处理方法见Console 监控操作指南。
从汇总走到下一步排查
先找到异常或无法判定的目标，再看是哪一项、哪些节点出现问题。例如，DNS 没有报告污染但 TLS 项异常时，下一步应检查 TLS 连接相关的信息，而不是把 DNS 检测当成完整可用性证明。HTTP 项与 TLS 项不同，也不能简单解释成网站整体被封锁。
把检测时间、目标、节点、分项状态和用户反馈放在一起。只有某个网络出现异常时，优先确认影响范围；多个节点反复出现同类异常时，再结合服务端、CDN、证书或访问控制记录排查。超时本身不能说明责任方，服务端策略也可能影响连接。
正常结果表示这次观测没有报告相应异常，不是所有中国用户永久可以访问。若用户仍打不开，继续检查实际使用的依赖域名、终端网络和应用流程。
复查时保留配置，恢复时保留证据
收到异常后先用同目标、同节点、同端口配置复查，记录新的时间；需要扩大范围时，再单独增加节点并标注变化。若仍有无法判定项，保留“待确认”，不要为了统计方便把它归到正常或异常。
结果转为正常后，也应确认最近结果与受影响用户的业务体验。你可以在自己的故障记录中标记“已恢复”或“待进一步确认”，同时保留最初异常与复查结果。用 API 执行的批次还需在返回的 expires_at 前保存结果，不能依赖临时批次长期留存。
开始前可查看当前价格；实施自动化时使用公开 API 契约。把一次检查做成有目标、有网络范围、有时间和有后续动作的记录，才比一个孤立的“是否被墙”标签更有价值。