VPN速度实测对比，先要回答“测到了哪条路径”，再看数字大小。工具可选浏览器测速、实际文件下载和连续延迟检测；时段应覆盖早间、午间与晚间，尤其保留自己常用的晚高峰样本。只测一次峰值，不能判断线路是否适合长期使用。
先固定测速条件，再比较线路
一次访问会经过设备、本地网络、运营商、代理入口、跨区域传输路径和目标服务器。任何环节拥塞，都可能压低结果。测速站显示的带宽是这次测试条件下的端到端表现，不等于服务商为某条线路标注的容量，也不是所有网站都能达到的速度。
先在不启用代理时记录本地网络基线，判断无线信号、宽带或后台任务是否已经构成瓶颈。直连无法访问某个国际目标时，不必强求同目标基线；可以用可访问的本地测速目标确认接入网络状态，但不要把不同目标的结果直接解释为“代理损耗”。
- ✅ 固定设备、接入网络和客户端版本；条件允许时使用有线连接，减少无线环境变化。
- ✅ 暂停云盘同步、系统更新及其他大流量任务，记录是否有其他设备共用网络。
- ✅ 固定测速服务器、测试模式和代理规则，避免工具每次自动更换目标。
- ✅ 从客户端连接记录核验测速域名命中的规则、实际出口与所选线路。
- ✅ 记录失败、超时与中断，不只保留跑得最快的截图。
比较线路时尽量只改变所选节点。如果同时更换协议、设备和测速目标，结果即使明显变好，也难以知道真正原因。自动选择节点或故障切换功能可能在测试中改变出口，应记录实际使用的线路，而不是只记策略组名称。
工具选择：吞吐、延迟与真实任务
不同工具回答不同问题。浏览器测速适合快速检查带宽，连续探测适合观察响应波动，实际下载则更接近日常任务。至少交叉使用不同类型的工具，避免把测速站自身的线路优势当成普遍表现。
| 工具类型 | 主要观察项 | 适用场景 | 解释边界 |
|---|---|---|---|
| Speedtest 等浏览器测速 | 下载、上传、延迟 | 固定服务器后比较线路吞吐 | 自动选服及并发模式会改变结果 |
| FAST 等内容网络测速 | 到特定内容网络的吞吐、负载延迟 | 观察相关内容分发路径 | 不能代表所有视频平台与区域 |
| 可信来源的实际文件下载 | 持续速率、停顿、完成情况 | 验证下载与大文件传输体验 | 源站限速、缓存和磁盘也会影响结果 |
| ping 与客户端延迟检测 | 往返延迟、波动、探测失败 | 辅助定位本地或线路响应问题 | 探测协议、目标和代理路径可能不同 |
| 自有服务器上的 iperf3 | 受控端点间的传输表现 | 有运维条件时做定向排查 | 服务端容量与流量路径仍需核验 |
测速站常用多个并发连接来填满带宽，真实文件下载却可能受单连接性能限制。因此，“测速很快、下载偏慢”不一定是结果造假，也可能来自连接模式或源站差异。对比时应分别记录，不要把它们混成同一项成绩。
早中晚实测：重点看自己的使用时段
早间、午间和晚间的意义在于采样不同网络负载，而不是某个时刻天然具有代表性。晚高峰既可能挤在家庭宽带侧，也可能出现在运营商互联、服务入口或国际出口。离峰速度好，只说明当时条件较好，不能替代晚间验证。
- 选定自己常用的线路和固定目标，先记录测试时间、本地接入方式及代理模式。
- 在早间、午间与晚间重复相同流程，测试过程中避免同时运行其他测速工具。
- 同一时段轮换线路，后续测试调换顺序，减少临时负载变化带来的顺序偏差。
- 连续跨日保留记录，遇到异常再复测；不要把异常样本删掉后只报告平均表现。
- 最后回到实际业务，验证视频播放、网页加载或文件下载是否同样稳定。
测试次数增加后，可以看中位数、表现范围和失败情况，而不是只挑最大值。记录里同时写明成功样本与失败样本的总量，否则一条经常连不上的线路，也可能因为仅留下少量成功结果而显得很快。
不必一开始就写复杂脚本。用电子表格保留日期时段、网络环境、线路、协议、目标、带宽、延迟、中断和业务体验即可。测速可能消耗较多流量，流量预算有限时，应优先覆盖常用时段和候选线路，而不是持续循环跑满带宽。
指标解读：带宽快不等于响应稳
下载带宽与上传带宽
下载带宽主要影响大文件获取和视频缓冲，上传带宽则关系到文件发送、云端备份和会议上行。测速站常以 Mbps 展示结果，下载软件可能显示 MB/s；前者按比特计量，后者按字节计量，数值不能直接比较。实际应用还会受到协议开销与服务端策略影响。
空闲延迟、负载延迟与抖动
空闲时响应快，不代表下载时仍然灵敏。带宽被占满后，如果负载延迟明显上升，网页交互、语音和远程操作仍可能卡顿。抖动描述延迟随时间的变化，但不同工具的计算口径可能不同，跨工具比较前应确认定义；稳定性判断更适合使用同一工具的连续记录。
丢包、超时与重传
持续丢包可能触发重传，拖累有效吞吐。不过，探测包未收到回复，也可能是目标限制或忽略该类请求，不能直接推定业务流量同样丢失。若连续探测异常且实际传输也停顿，证据才更充分。单次超时只能记作待核验现象，不能立刻定位到某一段线路。
分流与 DNS：确认测到的是代理路径
常见误差是测速网站走了直连，而目标应用走代理。规则模式可能根据域名、地址和应用分配流量；浏览器测速与独立下载程序也可能不遵循相同的系统代理设置。应在客户端连接记录中查找测速请求，并配合网络检测核对出口信息，不能只看客户端是否显示已连接。
排查时可以在理解客户端功能的前提下，暂时使用统一出口策略进行对照，再恢复日常规则。但“全局模式”不一定接管所有程序，命令行工具尤其需要核验；TUN 模式的覆盖范围也取决于路由、权限和配置。测试环境发生改变后，要在记录中明确标注。
DNS 解析会影响首次访问耗时与内容分发节点选择。DNS 查询走向与业务出口不一致，是需要核验的信号，但不能仅凭解析器所在地就认定泄漏。应结合客户端 DNS 策略、查询路径及检测结果判断；同样，出口地址改变也不能单独证明 DNS 路径符合预期。
如果测速站正常、特定网站却慢，先检查该网站命中的规则、DNS 结果和连接错误，再尝试固定出口复测。不要一次修改大量规则，否则很难判断改善来自哪个改动。订阅链接可能含有访问凭据，排查截图与记录应遮蔽链接和账号信息。
线路与协议：名称不能代替测量
直连、中转和 IEPL 专线描述的是传输路径组织方式。直连通常指客户端直接连接境外服务端；中转通过入口转发；IEPL 专线侧重专用传输段。即便采用专线，家庭网络、服务入口与目标网站仍可能成为瓶颈，不能把线路类型当作端到端表现的保证。
Shadowsocks、VMess、Trojan、VLESS 是不同的代理协议体系，Hysteria2 与 TUIC 使用基于 QUIC 的传输。实际表现取决于客户端实现、配置、设备负载、网络对 UDP 的处理及服务端条件。协议名称无法直接推导出“最快”，使用相同协议的不同线路也可能差异明显。
跨平台比较还要考虑接管方式：桌面端可能使用系统代理或 TUN，移动端常通过系统提供的网络扩展接管流量。同一订阅导入不同客户端后，规则、DNS 和协议支持未必一致。若目的是比较线路，应先固定平台与客户端；安装和导入问题可参照使用教程核对。
形成结论：保留条件，也保留失败
可靠的结论应写成“在这台设备、这个网络和这些时段下，某线路对某任务表现更合适”，而不是笼统宣布某服务永远最快。记录测量范围，保留失败样本，并标明未测试的地区、平台和应用，后续遇到变化时才有可比较的依据。
如果所有线路同时变慢，优先排查本地网络和共同目标；只有某条线路异常，再检查其入口与出口；只有某个应用异常，则先核验分流、解析和服务端限制。按照影响范围逐步缩小问题，比频繁切换节点更容易得到可复现的答案。
最终保留适合常用任务的主用线路与备用线路，并定期在常用时段复核。测速是选择与排障工具，不是体验本身；当实际任务持续顺畅、失败情况清楚可解释时，继续追逐更高的截图峰值通常没有必要。