先把失败动作写成一句话

描述问题时，说明哪台设备、哪个应用、执行什么动作以及停在哪一步。浏览器无法打开页面，与页面打开后上传失败，涉及的范围不同。记录发生时间和最早的关键错误，比只写“网络坏了”更有用。不要急于把所有异常归因于机场，也不必一次收集大量日志；先形成一条能复现、又不包含账号秘密的简短说明。

应用是否真的发出了请求

有些问题发生在网络之前，例如应用配置错误、文件格式不符或本地权限不足。先看界面和日志是否显示预期请求已开始，确认地址与操作对象没有填错。若应用使用自己的代理设置，系统代理正常并不能证明它会采用相同路径。把应用层入口检查清楚，能够避免在请求根本没有离开应用时，反复更换远端节点。

请求有没有进入客户端入口

下一步确认客户端是否运行、当前模式是否接管对应流量，以及应用使用的监听地址和端口是否匹配。仅看到客户端显示连接状态，不等于所有进程都经过它。可通过适当的连接记录核对请求是否出现。若记录中没有目标请求，先查前半段；若已经出现，再看命中的规则与策略。这样能把未接管和接管后失败分成不同问题。

名称解析与远端连接各自核对

域名无法解析、得到不符合预期的地址、无法建立传输连接和身份校验失败，都可能阻止后续访问，但它们的处理方式不同。保留具体错误，不要把全部统称为超时。Fake-IP 等模式还可能使用临时映射，不能仅看到特殊地址就认定解析错误。每次修改一个相关条件，并知道怎样恢复原状态，避免同时清缓存、换 DNS 和换节点后失去线索。

目标返回了响应还要看业务含义

收到 HTTP 状态或应用提示，说明已经到达某个能够返回信息的环节，但不自动证明整个业务成功。认证、授权、频率限制或目标服务异常，都需要按提示范围分析。还应辨认响应来自目标、代理还是中间组件。不要因为某个网页可打开，就宣布所有任务可用；也不要因为业务拒绝就断言连接路径完全不通。

把证据整理成下一步而非结论口号

有效记录应能回答：已确认哪些层正常，哪一层仍有问题，以及下一次只需要改变什么。求助时提供必要错误文字和去掉私人信息的配置片段，避免公开完整订阅与令牌。一次恢复不一定解释根因，可以如实保留未知。排查的目的，是缩小范围并恢复自己的任务，不是用最少证据证明某个服务永久正常或永久失效。

延伸阅读：看到“超时”先别重装：沿着连接路径找断点 · 一段好日志，比十次换节点更有用。