01先确定这次要观察的问题
把“网络不正常”改成可以复现的描述，例如某个应用在某种网络中打开特定页面失败。记录发生时间、应用、目标和接入方式，再决定需要查看什么信息。若没有明确目标，大量连接记录很容易分散注意力。观察前先确认基础网络能用，并保留原配置；测试期间尽量减少其他下载或同步任务，让相关请求更容易从背景活动中识别出来。
02把请求对应到具体时间与目标
一次页面操作可能产生多个请求，广告、资源和后台同步也可能同时发生。不要看到一个失败条目就认定它是页面无法打开的原因。通过时间、域名和操作步骤寻找相关记录，必要时重新进行一次最小操作。不同应用对目标地址的表达可能不同，日志也不一定包含全部请求内容，应在实际可见范围内判断，不把没有显示的信息当作一定没有发生。
03分别观察解析、匹配与连接
先确认目标是否需要域名解析及其结果，再检查命中规则和关联策略，随后看是否建立连接。解析错误、拒绝处理和连接超时属于不同层面，应该分别归类。某个请求完成连接后仍可能收到目标应用错误，不能只凭连接成功判断业务正常。把各阶段的已知事实写下来，可以减少凭感觉修改配置的次数，也能帮助判断下一步应该看哪一类设置。
04理解响应与等待时间
一次访问的等待可能包括名称解析、建立连接、加密协商、服务处理和内容传输。单个总耗时不能直接说明哪个环节最慢，应该结合可见的阶段信息与复测条件判断。短小请求与大文件传输关注的指标也不同，不宜放在同一标准下比较。不要用一次偶然成功或失败推断长期状态；保持目标、网络和操作相同，才有较可靠的对照基础。
05用对照测试验证改动
每次只改变一个因素，例如停用最近增加的模块，或恢复某条规则原来的位置。随后以新请求复测同一目标，记录现象是否随改动出现或消失。切换网络、改变策略并重启应用同时进行，会让结果失去解释空间。如果问题不能稳定复现，先记录发生条件与时间，不急于增加更多设置。完整流程可结合 连接状态检查 逐项执行。
06分享摘要，避免公开完整会话
请求记录可能包含账户标识、私有域名、令牌、参数和个人浏览内容。求助时优先提供平台、网络类型、复现步骤、错误摘要与脱敏配置，删除授权字段和私人资源地址。不要为了观察普通网络问题而开启不必要的数据读取范围。完成排查后整理结论与恢复步骤，涉及加载速度可阅读 速度知识，涉及响应波动可阅读 延迟与丢包。