VPN测速实测对比的核心是固定条件，而不是寻找最高分。先建立本地网络基线，再用相同设备、相同目标和相同测试方式比较线路，最后到真正使用的应用里验证。单张下载速度截图，无法说明视频会议是否稳定，也无法说明晚高峰能否正常使用。

关键指标：下载速度之外看什么

一条访问路径包含本地接入、线路入口、出口和目标服务器。测速结果描述的是这条完整路径在测试期间的表现，不是某个节点永久固定的能力。先分清指标，才能判断该换线路，还是该检查无线网络。

常见测速指标与使用体验的对应关系
指标 含义 主要观察点 容易误读的地方
往返延迟 请求发出到响应返回的耗时，通常以 ms 表示。 会议交互、远程桌面、网页请求。 延迟低，不代表大文件下载一定快。
抖动 连续延迟样本的变化程度。 语音是否断续，画面是否忽快忽慢。 不同工具算法可能不同，不能直接横比。
丢包 测试报文未按工具规则收到响应的情况。 持续丢失是否伴随卡顿、重传或掉线。 设备可能限制探测报文，需结合应用验证。
下载与上传吞吐量 单位时间实际传输的数据量，常以 Mbps 表示。 下载文件、上传附件、发送会议画面。 测速峰值不等于整个传输过程的持续速度。
负载下延迟 上传或下载占用网络时测得的响应耗时。 传文件时，其他交互是否明显变慢。 空闲时延迟正常，繁忙时仍可能出现排队。

记录速度时保留单位。测速网页常用 Mbps，下载软件可能显示 MB/s，不能只比较前面的数值。也不要把客户端列表中的“延迟”直接当作业务延迟：有的客户端测试服务器连接，有的访问指定网址，两者的目标与请求过程并不相同。

工具选择：先确认测的路径

浏览器测速适合观察整条访问路径的吞吐量。可选择 Speedtest 或其他能显示测试目标的工具，但要手动固定同一个服务器。自动选服可能随出口改变，导致换线路时连测试终点也换了，结果就混入了目标距离和服务器负载差异。

系统自带的 ping 适合检查基础网络的往返响应，但它通常发送 ICMP 报文。仅开启系统代理时，这类报文一般不会进入应用代理；开启 TUN 后是否被接管，也取决于客户端实现。因此，终端里显示的低延迟不一定来自当前代理线路。客户端的 HTTP 探测更接近网页请求，但仍应确认探测目标与分流规则。

需要研究持续吞吐量时，可以使用 iperf3，不过应连接自己有权使用的服务端。公共服务端的拥塞和限制会影响结果，不适合作为线路能力的唯一依据。日常用户没有必要搭建专门环境：固定浏览器测速目标，再观察实际会议或文件传输，通常更容易复现。

测速前确认测试请求确实经过所选线路。结合客户端连接记录中的匹配规则、出口地址和测试目标判断，不要只看客户端是否显示已连接。连接记录可能包含访问目标，分享前应遮盖敏感信息。

建立基线：排除本地网络干扰

先暂停云盘同步、系统更新和后台下载。保持设备位置与接入方式不变；条件允许时使用有线网络，避免无线信号变化。测试期间不要同时运行多个测速页面，否则它们会争用带宽，测到的是相互竞争后的结果。

关闭代理后，选择本地网络能够直接访问的目标，观察基础延迟和持续传输是否正常。若直连本身也反复卡顿，应先检查路由器、无线干扰和接入网络。这里的基线用于识别本地问题，并不意味着国内直连测速与国际代理测速可以直接评判胜负：两者经过的路径不同。

  • ✅ 记录设备、操作系统、客户端版本与接入方式，后续比较保持一致。
  • ✅ 确认套餐状态、剩余流量和订阅更新正常，避免把状态异常当成线路性能问题。
  • ✅ 记录系统代理或 TUN 模式、分流规则及当前节点，确认测速流量的实际去向。
  • ✅ 关闭其他占用网络的任务，测完当前项目再开始下一项。
  • ❌ 不用不同设备、不同无线位置或不同测速服务器的截图直接排名。

订阅链接是客户端获取配置的凭据，不是测速网址。导入后先更新配置，再选择线路；不要把完整订阅链接交给陌生测速页面，也不要将它放进公开截图。客户端下载和订阅导入方式可在使用教程中核对。

平时与晚高峰的实测步骤

选择自己通常使用服务的时段，而不是只在空闲时测试。晚高峰没有适用于所有地区和运营商的固定边界，应以本地实际繁忙时段为准。平时与繁忙时段采用相同流程，才能观察线路在负载变化时的表现。

  1. 固定测试条件。记下测速目标、接入网络、客户端模式与节点，确认没有后台传输。
  2. 先观察空闲响应。记录延迟变化与异常中断，不只保留最低值。若工具展示丢包，注明使用的探测方式。
  3. 再测试吞吐量。分别记录下载、上传和负载下延迟，留意速度是否能够持续，而非仅有短暂冲高。
  4. 切换候选线路。保持目标不变，按同样流程测试。后续再反向调整测试顺序，降低时间变化带来的偏差。
  5. 复测异常。遇到明显失常时，先检查本地基线，再重复同一项目。保留异常记录，不只挑选最好看的结果。
  6. 回到业务应用。打开日常使用的会议、协作文档或视频平台，观察交互、缓冲和连续使用情况。

记录表至少保留日期时段、运营商、接入方式、节点、目标服务器、测试模式、各项指标和实际体验。重复测量后，可以比较中间水平与波动范围，而不是单次最大值。测速会消耗流量，尤其是大吞吐量测试；没有必要为了刷新峰值反复运行。

读懂结果：按场景而非单项排名

视频会议优先看响应是否连续、上传是否稳定，以及繁忙时段是否出现明显抖动。远程桌面更依赖交互延迟。大文件下载关心持续吞吐量与失败重试。视频观看还受到平台分配的内容服务器、账号状态及缓存影响，不能用测速网页的下载成绩替代播放验证。

若下载快但网页首屏慢，检查 DNS 解析、连接建立和分流。DNS 用于把域名解析为地址；解析器选择与解析请求路径可能影响结果。所谓 DNS 泄漏，是解析请求走了非预期路径，既涉及隐私边界，也可能影响访问体验。它不能仅凭网页加载慢来判断，应结合客户端 DNS 设置与实际解析路径核对。

若测速正常但某个应用卡顿，查看该应用是否走了不同规则。浏览器可能使用系统代理，其他应用却未使用；TUN 能接管更多流量，但仍受路由、排除项与客户端实现影响。排查时逐项修改并复测，避免同时更换 DNS、协议和节点，最后无法知道哪项起了作用。

选线结论：优先保留在常用时段波动较小、实际应用可用的线路。峰值较高但频繁停顿的结果，不应仅凭下载成绩排在稳定线路前面。结论应注明测试网络、目标和时段，不延伸为所有用户都适用的排名。

线路与协议：结果能说明多少

直连通常是本地网络直接访问出口服务器；中转是在路径中增加转发环节，表现取决于入口、转发网络及出口。IEPL 专线描述的是线路传输组织方式，不是应用协议，也不等于用户设备到目标网站的每一段都使用专线。即使中间传输较稳定，本地接入和出口到目标的路径仍可能成为瓶颈。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2 和 TUIC 的传输机制与实现不同，不能脱离客户端、服务器配置和接入网络，给出固定速度排名。Hysteria2 与 TUIC 基于 QUIC，依赖 UDP 路径；若当前网络对 UDP 存在限制，表现可能改变。其他协议同样受到具体传输配置、设备处理能力和服务器负载影响。

比较协议时，应尽量固定出口与目标，并注明仍无法控制的条件。不同平台的系统网络接口、后台策略和客户端实现也会产生差异。桌面电脑的结果可以用于筛选候选线路，但移动设备仍需在自身网络下验证，不能直接照搬结论。

保存记录：让问题可以复现

最终记录应同时包含测试条件、原始结果和实际症状。例如写清“同一接入网络下，繁忙时段会议上传画面停顿，换线路后缓解”，比只说“速度不行”更有排查价值。若不同线路同时变差，而且直连基线也异常，应先检查共同经过的本地网络。

需要协助时，通过联系渠道提交客户端版本、发生时段、线路名称和已尝试的检查步骤。截图中遮盖订阅凭据、账号资料与访问内容。更多排查顺序见问题诊断。客观测速的目标不是证明某条线路永远最快，而是找到适合当前网络和实际任务、并能持续复查的选择。