“中国移动打不开，电信却正常”是一条有用的线索，但还不是故障原因。城市、接入方式、检测时间、访问的子域名和实际业务都可能不同。排查的目标是找出异常出现在哪些网络、哪个阶段，再把证据交给合适的处理方，而不是给某一家运营商下整体结论。
本文侧重地区与运营商对比。如果所有大陆用户都无法访问，可先阅读网站国内打不开、国外正常的排查指南；如果已经知道需要多网络检查，可以直接使用 GFW 全量检测。
1. 把一句投诉变成可复现的问题
先确认“打不开”指什么：域名无法解析、连接等待后超时、浏览器报告安全连接失败，还是首页能开但登录、图片或接口失败。记录实际失败的完整网址；检测时使用其中的纯域名，业务路径则留在排查记录中。不要把 example.com 与 www.example.com 当作同一个目标。
请用户提供城市、运营商、手机流量或固定宽带、发生时间和错误提示。若可行，在同一台设备上分别通过原网络和另一网络复现，避免同时更换设备、浏览器和网络。截图应遮盖账号、令牌和个人资料，不需要收集用户的登录密码。
2. 先保留可比较的基线
确定一个失败目标，固定协议和端口，并在相近时间比较网络。上午的移动结果与晚上的电信结果可能对应不同的服务状态；一个检查 HTTPS，另一个只打开 HTTP，也不构成同条件对照。每条记录都应包含时间与时区、目标、端口、地区、运营商以及观测来源。
开始时不要同时更换 DNS、清空所有缓存、切换 CDN 和改防火墙。先保存原网络的失败现象，再逐项验证假设。若用户只能间歇访问，记录失败与成功的时间，比只记一次“现在能打开”更有价值。
3. 从 DNS 初查转向所需网络的全量检测
对单个域名，免费 DNS 污染检测是方便的初查入口。正常结果不能排除 HTTP、TLS 或应用层问题；明确异常值得保存并继续确认影响范围；无法判定时先核对输入和结果时间，再复测。三类结果的后续操作见DNS 污染检测入门。
当问题明确涉及多个地区或运营商时，使用 GFW 全量检测，选择与受影响客户有关的当前可用节点。它组合 DNS 污染、HTTP Host 和 TLS SNI 三个维度，不是完整浏览器测试。无需为了流程完整，先把每个域名再单独测一遍 DNS。实际操作见GFW 全量检测指南。
公开节点页帮助了解覆盖范围，创建任务时仍应以 Console 或 API 的可用列表为准。API 接入使用当前返回的 node_id，不要根据旧名称或旧报告猜代码；节点选择和目标参数见公开接口文档。
4. 建立一个小而有用的地区与运营商矩阵
优先加入受影响城市的移动网络，以及同城可用的电信或联通对照；再补充另一个客户集中的地区。若没有对应节点，明确写“缺少观测”，不要用别的城市冒充。覆盖选择应回答真实客户的问题，不必一开始就把所有节点塞进报告。
下面是虚构示例，不是真实平台结果或节点覆盖承诺。全部行使用 www.example.com，HTTP 端口 80、TLS 端口 443，时间均为同一天 UTC+8；表中只列 HTTP/TLS 观测，DNS 与汇总结果应另行保留。
| 地区与网络 | 检测时间 | HTTP 观测 | TLS 观测 |
|---|---|---|---|
| 城市甲 · 移动 | 10:00 | 合法响应 | 握手超时，无法判定 |
| 城市甲 · 电信 | 10:02 | 合法响应 | 握手成功 |
| 城市乙 · 移动 | 10:04 | 合法响应 | 握手成功 |
这个例子支持继续调查城市甲移动侧的 TLS 访问现象，不支持“全国移动都被封锁”。复测时保留第一轮目标与端口，继续查看同一组合，而不是换成一个新矩阵后丢掉原证据。
5. 读失败阶段，不把超时写成封锁
逐节点查看维度和原始状态，再看汇总。如果前置步骤没有完成，后续未测试就不是后续明确失败。正常、明确异常、无法判定以及尚未获得结果必须分别记录；不要删除无法判定项后只展示一个“正常率”。
HTTP 收到合法响应不保证业务页面返回 200；TLS 握手成功也不代表证书和完整页面体验已经通过。reset 等明确异常需要结合上下文继续定位，超时则不能直接指定责任方。具体字段和状态边界以结果解读文档为准。
6. 节点与真实用户不一致时，补齐终端证据
检测节点提供其网络和时刻下的观测，不能保证覆盖每一条家庭宽带、手机网络或企业出口。即使同一城市、同一运营商，用户使用的接入方式、设备和服务路径也可能不同。节点正常而用户仍失败时，不应据此关闭工单。
回到受影响设备，记录浏览器错误、实际失败的请求域名、发生阶段，以及是否只有某个功能异常。若首页可访问但登录失败，检查登录/API 依赖；若仅部分资源失败，列出资源域名。不要让主域名的正常结果替代这些目标的检查。
7. 把网络观察与服务端日志放在同一时间线上
按失败时间核对 CDN、反向代理、源站和安全策略日志：请求有没有到达、落到哪个服务、返回了什么状态，是否近期调整了地域限制、限速、WAF 或源站配置。没有看到业务请求，本身不能证明某个特定网络设备拦截了它；日志采集范围也可能有限。
向 CDN、主机商或运营商反馈时，提供脱敏的目标、端口、地区、运营商、时间窗口、重复现象和相关状态。把“观测到什么”与“怀疑什么”分开，说明尚未覆盖的网络，通常比一句“你们线路有问题”更有助于推进处理。
8. 用原条件验证恢复，再决定持续监控
经过有依据的配置修复或服务方处理后，用原目标、端口和相关网络复测，并请受影响用户验证原先失败的操作。保留变更前后记录；上一轮异常、这一轮无法判定，不应报告为恢复。若出口或节点可用性改变，也一并注明。
对重复出现的问题，可在 Console 为客户主要网络配置 GFW 全量监控；需要自行归档时再用 API 保存批次结果。一次节点检查不能承诺永久可用，监控范围也应随客户分布调整。
简而言之：先把投诉变成同条件证据，再选择相关地区与运营商做全量检查，最后结合真实用户和服务端日志定位。运营商差异是排查入口，不是已经完成的责任判定。