延迟和速度解决不同问题
延迟描述数据往返或某阶段等待所需的时间，吞吐描述持续传输的能力。下载大文件速度较高，并不意味着交互请求总能立即响应；反过来，一个小请求很快返回，也不能说明长时间传输不会受到限速或拥塞。理解区别后，才能选择合适的测试。
应用体验还涉及 DNS、连接建立、加密协商和服务器处理等多个阶段。界面中的一个延迟值通常只代表特定测试方法和目标，不应把它解释为所有网站的统一响应时间。Mihomo 的策略标签也不能保证固定低延迟或零丢包。
抖动与丢包需要持续观察
抖动描述延迟变化，丢包则反映测试中的数据未按预期得到响应。无线干扰、拥塞、路由变化以及目标限速都可能影响观察。测量需要一定时间和样本，不能仅凭一次超时就得出长期故障结论，也不能只展示最好的一次结果。
某些设备或目标会限制特定探测协议的响应，因此探测没有返回不一定等同于业务流量丢失。中间节点不响应，也不必然意味着实际连接在该处中断。应结合目标应用请求和其他可观察信息，而不是机械地把探测图上的红色标记当成故障位置。
让测试方式和实际业务相近
ICMP、TCP 和应用层请求测试的对象不同。一个目标不响应 ping，不代表其网页服务不可用；本地端口可以建立 TCP 连接，也不代表远端服务已经成功。选择测试时要说明协议、目标和端口，避免把不同工具的结果直接等同。
- 先描述实际业务：网页、下载还是实时交互。
- 选择与该业务相关的合法测试目标。
- 记录协议、测试时间和网络类型。
- 同时保留实际请求结果，比较异常是否一致出现。
从本地网络到目标逐层比较
先确认设备与接入点之间的连接质量，再比较外部目标。如果只有无线环境波动较大，可在相同设备上使用有线网络对照；如果多个目标都异常，观察是否存在后台流量或运营商问题。不要在一轮比较中同时变更设备、网络、策略和测试工具。
通过代理时还需要确认请求真正经过预期规则与入口。某些探测工具可能使用不同路径，因此工具显示的数值不一定代表应用连接。查看日志能帮助确认流量归属，但日志本身也不一定包含所有阶段的完整时间数据，需按实际工具能力解读。
如何整理有用的诊断记录
保留异常发生的时间范围、持续长度、影响的目标，以及是否可以在相同条件下复现。说明数值来自哪个工具、使用什么协议，比只发一个延迟截图更有帮助。对外提供记录前，遮盖私人地址、账号、令牌和不相关的访问历史。
处理策略应与观察结果对应。局部无线波动优先检查接入环境，单个目标异常优先看服务可达性，解析等待明显则转向 DNS。进一步可阅读速度与本地环境，避免通过无依据的参数调整追求不切实际的固定数值。
阅读后的检查清单
- 知道当前指标对应的协议、目标和测试阶段。
- 已保留一定时间范围的结果与波动条件。
- 结论同时参考真实业务请求与探测信息。
具体选项以所用版本和对应项目文档为准。本文提供一般排查路径，不代表对特定网络的测试结果。