速度是整条链路的结果。延迟、首包时间与持续吞吐量反映不同问题，需要用实际任务验证。
把“慢”描述成可以复现的现象
先写清楚是网页首屏等待、视频缓冲、文件下载慢，还是只有节点测试超时。选择同一目标、同一时间段、同一设备和同一接入方式做比较。测试过程中暂停你自己启动的大型下载，不要在不同网站间随意比较峰值。
延迟测试通常针对某个探测 URL；自动选择组也按指定探测条件判断，并不替代真实任务。网页响应快的节点可能不擅长大文件传输，反之亦然。记录开始时间、持续时间、是否稳定，以及日志中的目标和策略，避免只保留一张瞬间速率截图。
先排除本地网络和设备限制
使用一个通常能够直连的站点做基准测试，再观察同网络下其他设备的普通上网是否也变慢。如果所有路径都慢，先检查无线信号、后台传输、网络登录认证和路由器状态；此时调整代理规则可能没有帮助。若有条件，可在自己允许使用的另一网络上复测。
本地网络正常后，查看设备是否同时运行多个 VPN、加速工具或大量占用资源的任务。只退出自己确认不需要的工具，保留工作所需连接。观察“退出后是否改善”，这种对照比直接重装客户端更有解释力，也不会破坏原有配置。
对比出口，但不要只选最低延迟
保持目标、模式和规则不变，在已有授权配置中测试两个不同节点。只有一个慢，可能指向该出口的负载、路由或目标服务间的链路；全部都慢，则继续看基础网络与共用配置。上午正常、晚间稳定变慢可以作为时间模式记录，但无法仅凭它证明提供方超售。
确认实际请求选择了你测试的节点。自动选择、回退或手动固定策略可能使最终出口与预想不同。观察连接记录中的最终代理，再评估实际任务的稳定性。若服务端限制单连接或目标站点自身繁忙，更低的客户端延迟也不一定提高下载速度。
比较 TUN、系统代理和解析影响
如果浏览器使用系统代理较快而 TUN 较慢，在同节点与同目标条件下分别测试，查看是否出现解析错误、出口接口变化或其他 VPN 路由干扰。先确认配置与规则一致，否则不同结果可能来自不同出站路径，不能归因于 TUN 本身。
网页长时间停在首次连接、进入后却很快，可以进一步检查 DNS 和握手错误。持续传输始终慢则更关注吞吐链路。不要没有证据就修改 MTU、并发参数或连续切换内核。官方内核文档提醒 MTU 会影响特定情况下的速率，一般用户从默认值开始更便于定位。
以实际任务验收，保留有效对照
选定改善方案后，再完成一次常用任务，例如连续浏览几页或下载同一公开文件，检查速率是否稳定、规则是否正确。可以在另一个常用时间段复测。若体验已经满足需求且没有新增错误，就停止继续调参；测试本身会消耗流量，不必追求每次刷新都得到最高数值。
仍慢时整理对照表：网络、运行方式、节点代号、目标类型、时间与结果，不公开真实服务器凭据。节点间差异明确时向提供方反馈；模式差异明确时向客户端项目提供复现步骤。测速结论只适用于这次条件，不应用它承诺任何节点的固定速度。
相关问题
延迟越低，下载速度越快吗？
不必然。延迟与持续吞吐量不是同一指标，目标服务、出口负载和本地带宽都会影响下载速度。
一变慢就更新内核好吗？
先检查能否复现并建立对照。版本升级可能修复特定问题，但应阅读说明、备份配置，保留回退路径。
资料与适用范围
本文以原创步骤解释操作思路，不声称已经在所有设备和版本上实测。菜单名称、默认值与兼容条件可能随版本变化，请结合当前项目说明核对。
需要修正内容？请阅读反馈与纠错，不要公开完整订阅或账户凭据。
