先分清延迟数字和实际卡顿
客户端显示的延迟低，只能说明它完成那次探测用了较短时间。探测请求很小，连续下载却要传输大量数据，所以“响应快”和“传得多”可以同时表现得很不一样。延迟数字也未必测向你正在访问的网站。
先描述实际问题：是视频一直缓冲、大文件下载慢，还是网页第一次打开慢？再打开另一个原本能正常使用的网站。如果只有一个目标慢，先围绕这个目标比较；所有目标都慢，再检查节点和本地网络。
固定条件，做一组能比较的测试
先暂停下载、云同步等占用带宽的任务。在同一设备、同一网络上，选定一个确实卡顿的页面或视频，只切换节点 A 和节点 B，分别观察加载或缓冲情况。记录时间和目标地址，确认请求确实经过刚选的节点。
如果测速工具会自动更换服务器，应手动选同一个服务器；否则，测量目标和节点一起变了，就无法判断差异来自哪里。测速结果也只能描述到该测试服务器的表现，不能代替所有网站的实际体验。
需要区分上传、下载和延迟时，可参考 M-Lab NDT 的测量说明。它测量单流传输容量，并会收集 IP 地址和测量结果、公开相关数据。使用前先接受这种数据处理方式；不接受时，直接比较自己的实际访问任务即可。
不必反复跑满速。先给测试设定可接受的用量范围，得到足以选用节点的结果就停。流量很少时，优先比较原本要打开的页面，避免为了查卡顿又产生一笔大额测速流量。
根据对照结果缩小问题范围
| 观察到什么 | 接着做什么 | 暂时能说明什么 |
|---|---|---|
| 同一目标在 A 慢、B 正常 | 先用 B 完成任务，保留两次记录 | 差异与节点或相应路径有关，还不能直接断定服务器过载 |
| 两个节点访问同一目标都慢，其他目标正常 | 记录目标地址，换个时段复查一次 | 应继续查目标网站及到它的路径 |
| 原本可直连的网站在关闭代理后也慢 | 保持该网站直连，换手机热点比较一次 | 本地网络或运营商路径值得继续检查 |
| 同一设备换热点后恢复正常 | 回到原网络，检查 Wi-Fi 信号和带宽占用 | 两条接入网络有差异，不能仅凭一次测试锁定路由器故障 |
直连对照只适用于本来就能直连的普通页面。需要代理才能访问的目标，关闭代理后打不开，并不能证明你的家庭网络有问题。
每次只改一个条件。切节点、换网络、改协议和重启客户端同时做，即便恢复了，也难以知道哪一步有效；下次再出问题时又得从头猜。
保留什么证据，什么时候停止改设置
留下一份简短记录即可：测试时间、设备与网络、目标地址、节点名称，以及发生了什么。比如写“同一视频在 A 连续缓冲，切 B 后正常”，比只报“延迟 30 毫秒”更有助于排查。示例只是记录方法，不是本站测速成绩。
发给客服时，隐藏订阅链接、账户标识和其他个人信息。保留原配置和已知可用节点；如果任务已经能正常完成，就停止试改。需要进一步排查时，根据已有对照结果选下一步，不把关闭防火墙、跳过证书验证或重装全部配置当作通用提速手段。