测速正常但用起来慢：自测后的排查清单

先找错位：测的路和用的路不是同一条

测速正常但用起来慢，最常见的原因不是测速“不准”，而是测试时走的路径和实际使用时走的路径不一样：代理模式、出站节点、时段、连接数、传输协议或发起请求的应用发生了错位。排查的核心方法是把测试条件一项一项改成使用条件再复测，哪一项改完之后变慢，问题就在那一层。

本文是 自己动手测速专题 中的排查篇，侧重“自测之后”的对照方法。延迟低但网页慢的指标层原因，已在 延迟低但打开网页慢的常见原因 中拆分；规则与 DNS 的配置细节属于客户端话题，请看 规则分流与故障排查。

八项错位对照清单

序号	测速时的条件	日常使用时的条件	错位后的表现
1	全局模式	规则模式	部分网站走了直连或其他节点
2	手动指定节点	自动选择策略组	实际出站不是测过的节点
3	凌晨或白天	晚高峰	白天正常、晚上变慢
4	多线程吞吐	少量连接的下载或播放	测速高，单个任务慢
5	基于 TCP 的测速	基于 UDP 的视频或会议	UDP 未转发或回退后变慢
6	浏览器测速网页	独立应用	应用未读取系统代理，走了直连
7	有线电脑	无线或手机	本地链路不同
8	国内测速后端或固定测试服务器	境外目标网站与其 CDN	目标侧调度或限速

逐项打勾，先找出你的测试与使用之间存在哪些错位，再进入复测。

复测方法：一次只改一个条件

找到错位后，按下面的顺序复测。每一步只改变一个条件，其他保持不变：

1. 模式对齐：切回日常使用的规则模式，访问慢的网站，同时打开客户端的连接日志，看这个网站命中了哪条规则、走了哪个出站。
2. 节点对齐：如果日常使用自动选择策略组，记下它当时选中的节点，对这个节点单独测速。
3. 时段对齐：在你感觉慢的时段做一轮测速，与平时测速的时段比较。
4. 连接数对齐：用单线程方式测一次吞吐，或直接用实际的下载方式下载一个文件计时。
5. 协议对齐：确认客户端是否转发 UDP，代理模式能否接管该应用的 UDP 流量。
6. 应用对齐：确认慢的应用是否在代理范围内，必要时改用虚拟网卡模式对照一次。
7. 设备对齐：在实际使用的设备和网络上重复测速。
8. 目标对齐：换同类型的其他网站或应用对照，判断是否只针对个别目标。

每一步的结果都写进记录表，格式可沿用 测速记录表模板，在备注里注明“排查复测”和本次改动的条件。

按使用场景看最可能的错位

网页浏览

最常见的是错位 1 和 2：网站命中了直连规则或另一个策略组。其次是首次访问时的域名解析。连接日志通常能直接看出来。

视频播放

常见的是错位 4、5、8：播放器连接数少，测速的多线程结果反映不了；部分视频平台使用基于 UDP 的传输；视频 CDN 的调度与测速后端无关。可以用视频平台自带的统计信息面板观察实际码率与缓冲情况。

独立应用与开发工具

常见的是错位 6：应用不读取系统代理。处理思路可参考 浏览器能用、软件不走代理。

会议与语音

常见的是错位 5：UDP 未被转发或不平稳。测试方法见 视频会议与语音场景如何测 UDP 与抖动。

排查中最常见的三种误判

把一次复测当成定论

对齐某个条件后复测一次，速度变低了，就认定问题在这一层。但单次结果本身就有波动，应当对齐后至少测两到三次，并与未对齐时的结果在同一时段内交替进行，才能确认差异来自这个条件。

同时改了好几个条件

为了省时间，一次把模式、节点和设备都换了，结果变好了却不知道是哪一项起作用。下次再出问题，又要从头排查。每次只改一个条件，看起来慢，实际上更省时间。

忽略本地基准的变化

用了一周之后突然变慢，未必是节点出了问题。家里新增了设备、路由器设置被改动、运营商链路调整，都会改变本地基准。排查开始前，先在关闭代理的状态下测一次直连，与之前的基准对比，方法见 测速前先测本地带宽。如果直连本身也变慢了，问题就不在代理链路上。

什么情况下可以归因到节点

完成全部对齐后，如果同时满足以下条件，才有理由认为问题主要在节点侧：

• 测试条件已与使用条件一致，慢的现象在复测中稳定出现；
• 同地区另一个节点没有同样的问题，或者同一服务的多个节点都有问题；
• 换另一个同类网站或应用对照，仍然偏慢；
• 同时段的本地直连基准正常。

满足这些条件后，可以带着记录（时间、节点名称、复测步骤与结果）向服务方反馈。反馈时提供条件完整的记录，比描述“感觉很慢”更容易得到有效回应。

排查结束后

排查过程中临时改动的模式、规则和代理设置，要逐一恢复，避免残留设置影响日常使用。如果排查发现是规则或 DNS 问题，具体修改方法回到客户端专题处理。使用网络服务时，请遵守所在地法律法规与平台条款。