知识库 · TOPIC-05

Provider 故障还是本地网络故障？用证据分开判断

**简短结论：**至少比较两类相互独立的信息：本地协议测量与 Provider 官方状态；条件允许时，再增加一条受控的备用网络。单次超时、绿色状态页或社区帖子都不能独立证明根因。

四类信息不要混写

• **Observed：**带时间戳的本地 DNS、TCP、TLS、HTTPS、WebSocket、IPv4/IPv6、接口或路由结果。
• **Provider-reported：**Provider 官方状态组件与事故时间线。
• **Inferred：**由前两类证据共同支持的解释。
• **Unknown：**未测量、无法安全测量或证据不足的部分。

OpenAI 状态页明确说明，其可用性数据是聚合指标，个体体验可能因套餐和功能而异。反过来，一次本地失败也不能证明全局事故。

推荐排查顺序

1. 记录失败动作、时间和原始提示。
2. 查看官方状态页中准确的产品组件。
3. 按层执行有边界的本地检查：DNS、TCP、TLS，再到经过批准的应用协议；IPv4 与 IPv6 分开记录。
4. 若安全可行，在一个可信备用网络上重复同样操作。不要同时改 DNS、代理、客户端版本和网络。
5. 对比结果。若多个无关 Provider 只在本地同时失败，而官方状态正常，“共同本地/上游路径”是更强的推断，仍不是直接证明。若官方报告事故且多个网络都复现，则 Provider 影响更可信，但两类故障也可能叠加。

常见误判

Ping 成功不等于 TLS 或应用协议成功；能打开首页不等于原生 Agent 长连接正常；401/403 是 HTTP 响应，不是连接超时；绿色状态页不是针对个人路径的保证；一个 Wi-Fi 上失败也不自动等于 Provider 故障。

Tivor 如何表达

Tivor 报告应把“本地路径”和“Provider 官方状态”并排展示，而不是合成一个看似权威的总灯号。浏览器拿不到的证据保持“不完整”；检测后端本身失败时，也不能归罪于用户网络。

建议动作与验证

只做一个可逆改变：切换到可信备用网络，然后复现同一工作流并运行同样的有边界检查。若故障跨网络跟随 Provider 且与官方事故吻合，等待后再验证；若只跟随某条路径，则逐层调查那条路径。