海外监控显示绿色，中国大陆用户却反馈打不开，这两条信息未必互相矛盾。监控可能只确认海外某个观察点能读取健康检查接口；用户却在另一张网络上访问登录页及其依赖。先对齐观察范围，才知道应该补充检测，还是处理已经发现的故障。
本篇关注监控设计和不同观测之间的核对，而不是罗列所有“网站打不开”的原因。需要从最初症状开始排查时，可读访问异常指南。现有海外监控仍有价值，增加中国大陆观察是补齐范围，不是否定其他工具。
1. 先写清楚绿色指标证明了什么
查看监控的实际目标、方法、端口、成功条件、观察位置与最后执行时间。读取 /health 返回预期状态，和浏览器完成登录，属于不同的成功条件。仪表盘上的“最近正常”也可能早于当前故障，必须区分观测时间、结果查看时间和通知到达时间。
把观察定义写成一句话，例如：“从指定海外节点，检查某主机的 HTTPS 健康接口”。确认是否跟随跳转、是否访问真实业务依赖，以及故障期间是否仍在执行。不要把一个有限指标改名成“全球所有用户可用”。
2. 为用户反馈与检测保留同一套对照字段
对每条观察记录实际目标域名、服务端口、观察网络、带时区的时间、方法、结果类别和新鲜度。用户反馈再补充失败步骤、浏览器错误，以及移动网络、宽带、代理或企业网关等条件。工具未公开某个字段时标为未知，不自行补出看似精确的配置。
同一域名仍可能使用不同路径、端口或依赖。域名协议检查与业务 URL 不能当成相同请求，HTTP 与 HTTPS 也不能混算。内部诊断需要的路径应保存在受控系统中；对外交流时只提供去除查询令牌、账户标识后的路径模板。
3. 分层设计监控，而不是寻找一个万能指标
| 观察层 | 能补充的证据 | 仍需要什么 |
|---|---|---|
| 海外可用性监控 | 所选位置与方法的服务状态 | 实际中国大陆网络的观察 |
| 中国大陆域名检测 | 相应方法、时间与覆盖范围内的网络结果 | 用户终端与应用流程验证 |
| 受影响浏览器 | 真实页面、接口和资源的失败步骤 | 同时间的服务端与网络记录 |
| 应用和基础设施日志 | 请求处理、错误与配置变更 | 未到达服务端的请求及其他网络证据 |
为关键业务分别保留这些证据的负责人。首页、认证和 API 是不同目标；一个层次的正常不应覆盖其他层次的异常。WeaveBit 的域名检测不登录账户、执行脚本或检查全部资源，也不替代浏览器证书信任验证、IPv6 或 QUIC/HTTP/3 专项验证。
4. 先用原配置复查，再扩大观察范围
发现结果不同，先重复原来的目标、端口、方法和节点配置，并记录新的时间。不要一边更换目标和网络，一边把结果当成“已经恢复”。若服务在两次观察之间发布代码、变更 DNS/CDN 或访问策略，也应记录，否则无法区分时间变化和配置差异。
随后再增加与受影响用户地区、运营商相关的 GFW 节点作为单独对照。覆盖信息可查看当前公开列表，实际可选节点以创建任务时的 Console 或 API 为准；不承诺等同用户家中的网络或覆盖全国所有住宅线路。报告应写实际覆盖范围，而不是把一个节点异常扩展成所有国内用户不可用。
5. 按尚未回答的问题补充 WeaveBit 检测
只想先了解一个获准域名的 DNS 污染结果时，可用免费 DNS 初查。正常表示本次没有报告该类异常，不表示网页业务正常；无法判定则保留待确认，不归入正常或封锁。
若需要多域名或更广的 HTTP、HTTPS 相关观测，可以直接选择 GFW 全量，不要求先逐个做 DNS 初查。全量包含 DNS 污染、HTTP Host、TLS SNI 三维及汇总，不是全部七种方法。GFW 任务按相关网络选节点，DNS 污染检测不需要用户选节点。查看全量操作指南与结果文档，保留公开返回的分项与状态，不自行猜测平台判定过程。
6. 工具结论不同，不用多数票决定事实
先问它们是否检查了同一目标、端口、方法、网络和时间，再看“正常”各自定义。一个工具的连接成功、另一个工具的网页成功，以及用户的登录成功，本就不是同一个结论。即使都叫中国节点，也不代表出口和终端条件相同。
以下是虚构对照，不是真实客户事件：两项检查都使用同一域名，但一项记录上午的 TCP 连接成功，另一项记录下午的 TLS 超时。即使界面分别显示“正常”和“无法判定”，它们也没有在同一时间回答同一个问题。团队应保留原记录，再用一致的端口、方法和接近的时间分别复查两张网络，而不是用多数票宣布某个工具错误。
若目标已一致但结果仍不同，记录可见差异，按原配置复查并交给相应负责人；未获有效观测的一侧保留未知。只有 HTTP 响应、超时或 reset 的标签，都不足以独立确定责任方和根因。
7. 检查监控本身，而不只检查被监控网站
确认任务仍启用、最近执行时间持续更新、目标清单未过期，相关节点仍可用。Console 持续监控还应检查余额、实际消耗和通知配置。没有告警可能只是没有新观察或通知未到达，不能直接作为没有故障的证据。
关键依赖可按责任与重要性分组，频率以当前 Console 选项、预算和响应能力来安排，不在故障中随意扩大范围。参考监控与告警指南；需要自己的调度和存储时使用公开 API 文档，不要把 API 批次当成自动持续监控。
8. 用可行动的记录交接，并单独验证恢复
最小记录包括：受影响步骤、域名与端口、时间和时区、用户网络、各观察的方法与范围、正常/异常/无法判定、最后有效执行时间、原配置复查、近期变更、负责人和下一步。信息不足时写“待确认”，不要为了统计把未知归为正常。
只手工分享复核后的必要字段；去掉 Cookie、Authorization、密钥、查询令牌、个人身份和订单信息，不附原始 HAR、请求体、完整日志或请求回放命令。隐私检查与技术检查同样是交接的一部分。
恢复确认应同时参考相同配置下的新观察与受影响业务的实际体验，并注明已确认的范围。从Console 入口补齐关键域名监控后，继续保留海外监控和应用验证；目标是让不同观察回答各自的问题，而不是追求一张永远绿色的仪表盘。