VPN速度实测对比，先固定测试条件，再看结果。测速工具里的最高下载速度，不能直接回答视频是否卡顿、语音是否断续、文件传输能否持续。更有用的结论是：在自己的网络和使用时段里，哪条线路能稳定完成目标任务。
本文不提供虚构的测速排行。下面的方法用于自己采样，比较线路、客户端设置和本地网络。每次只调整一个变量，把失败和异常也留下，结果才有复查价值。
先确定测速对象与指标
一次访问通常经过本地设备、无线或有线网络、运营商接入、代理入口、出口，再到目标服务器。任一环节拥塞，都可能让最终结果变差。因此，“某条线路慢”只是现象，不是定位完成后的结论。
先写下实际用途。网页和交互式应用在意请求响应；视频更依赖持续吞吐与缓冲；语音、远程桌面则对抖动和丢包敏感。脱离用途比较峰值带宽，容易把不适合自己的线路排到前面。
| 指标 | 主要反映什么 | 判读时注意 |
|---|---|---|
| 往返延迟 | 请求往返目标的时间 | 必须确认目标与测量方式；入口延迟不等于完整代理链路延迟 |
| 抖动 | 延迟随采样变化的程度 | 工具计算方法可能不同，不宜直接跨工具排名 |
| 丢包 | 探测报文未收到响应的情况 | 探测可能被限速或过滤，需要结合业务连接验证 |
| 持续吞吐 | 一段传输过程中的有效速度 | 观察能否保持，不只截取起始峰值 |
| 负载下延迟 | 下载或上传时的交互响应 | 空闲时很快，不代表传输占满链路后仍然流畅 |
工具怎么选，结果怎么读
浏览器测速：适合比较吞吐
浏览器测速工具适合快速观察上传、下载及部分延迟指标。它们可能自动选择服务器，也可能并发建立连接。每次自动选到不同服务器，结果便混入了目标端差异。能够手动选择时，固定同一个测试端，并记录服务器名称。
并发测速更接近链路的聚合能力，不等于单个文件下载速度。下载站点可能限制单连接速度，浏览器缓存、服务器负载也会改变结果。比较时使用相同工具与模式，不要把不同工具的最高读数拼成一张排行榜。
客户端延迟：先看探测定义
客户端里的“延迟”可能是到入口的连接耗时，也可能是经代理访问指定网址的响应时间。名称相同，测量路径未必相同。查看客户端说明或探测设置，记录探测地址；如果无法确认，就把它当作该客户端内部的选线参考。
系统的 ping 通常使用 ICMP，而不少代理只转发应用层流量。即使浏览器已经走代理，终端里的探测也可能仍然直连。中间路由设备不响应探测，同样不能单独证明业务数据正在丢失。
实际应用：验证最终体验
选一个常用网站、一次真实文件传输和自己的交互任务。观察页面首屏、传输是否停顿、会话是否重连。开发者工具的网络面板可辅助区分 DNS、连接建立和服务器等待，但缓存与连接复用会影响分段显示；对比时保持相同操作方式。
固定环境，按步骤采样
可复现不等于实验室环境，而是让别人知道这次结果是怎样得到的。保持设备、客户端版本、分流模式、目标服务器和测试顺序一致，通常比增加截图数量更有用。
- 记录本地条件。写明运营商、接入方式、设备与系统、客户端版本。优先使用稳定的有线连接；使用无线网络时，保持位置和连接频段一致。
- 排除后台争用。暂停云盘同步、系统更新及其他大流量任务。留意同一网络里的其他设备，避免把家庭网络争用误判成线路拥塞。
- 建立直连基线。选择本地可正常访问的固定测试端，检查本地网络是否已经异常。它只能作为接入环境参考，不能与不同远端服务器的结果直接算作代理损耗。
- 确认实际代理路径。选择候选线路，检查测试域名命中的规则和客户端连接记录。浏览器测速没有进入预期代理时，结果不能归到该线路名下。
- 固定远端目标。使用同一测试端、同一模式，保存完整结果。记录空闲延迟、负载下变化、持续吞吐以及中断情况，而非只记下载最高值。
- 复测并验证业务。在不同使用时段重复流程，随后打开目标应用。测试结束后恢复日常设置，避免临时全局代理影响后续工作。
遇到异常先保留记录，再排查。只删除慢的样本，会把不稳定线路误写成稳定线路。如果某次测试明确受到后台更新干扰，可以标注为受干扰样本，但应留下原因。
时段与出口如何公平对比
至少覆盖自己常用的忙碌时段与相对空闲时段。不要用空闲时段测出的线路甲，对比忙碌时段的线路乙。条件允许时交替测试候选线路，避免固定顺序让后测线路总是碰到更拥挤的网络。
地区相同不代表路径相同。不同入口、运营商互联和出口上游，都可能改变体验。先在相同目标地区内比较，再检查其他地区是否更符合目标服务需求；离自己近，不必然意味着到目标服务器的完整路径更短。
IEPL 专线通常强调专用承载段；中转通过中间服务器转发；直连通常不经过服务方额外设置的中转层。这些名称描述路径组织方式，不能直接换算成测速名次。专线也要看入口和出口负载，直连同样可能在合适的网络条件下表现良好。
记录时同时写地区、线路名称和线路类型，不要只写“日本”或“香港”。若客户端自动切换出口，需核对实际使用的线路；比较期间频繁自动切换，会让样本失去明确归属。
协议、DNS 与分流的干扰
协议会影响传输开销、拥塞处理和设备负载，但不能脱离实现讨论谁永远更快。Shadowsocks、VMess、Trojan、VLESS 属于不同代理方案，实际传输还受承载方式和配置影响；Hysteria2 与 TUIC 使用基于 QUIC 的传输，其表现也依赖 UDP 路径质量和具体实现。
这些是通用技术背景，不代表 VPN29 提供全部协议。对比协议前，应确认服务和客户端确实支持，并尽量保持出口与目标一致。如果换协议时也换了服务器，就只能比较整套方案，不能把差异全部归因于协议。
浏览器、系统代理和虚拟网卡模式的覆盖范围也不同。部分应用不读取系统代理；命令行工具可能需要单独设置代理环境。检查客户端连接记录，比仅凭托盘图标判断“所有流量已代理”更可靠。
DNS 查询走向与业务连接走向需要分别确认。查询意外发往本地解析器，可能造成隐私暴露或得到不适合当前出口的解析结果，但不能仅凭解析器所在地区断言发生泄漏。还要结合预期配置、浏览器加密 DNS 设置及客户端 DNS 策略判断。
遇到网页首次打开慢、后续加载正常，可以检查解析与连接建立阶段；遇到测速正常但某个应用慢，应先核对该应用的分流规则。不要为一次测速随意关闭证书校验或安装来源不明的证书。
把结果写成可复查的结论
建议每条记录包含：日期与时段、本地网络、客户端及模式、线路名称、协议或配置标识、测试端、各项指标、实际应用表现。单位也要保留：测速工具常用 Mbps，文件下载常用 MB/s，二者不是同一单位，不能只比较数字大小。
汇总时同时保留典型表现和波动范围。有原始样本时，可以用中位数辅助描述日常水平，再单独标出失败和明显恶化的情况。样本有限就直接注明，不要推导成长期可用率或所有地区通用的承诺。
- ✅ 相同测试工具、服务器与模式，结果才进入同一组比较。
- ✅ 先确认规则命中与实际出口，再给测试结果贴线路标签。
- ✅ 下载、上传和交互体验分别记录，保留慢样本与失败原因。
- ❌ 不把单次峰值、入口延迟或地区名称当作最终选线结论。
- ❌ 不公开订阅链接、账户凭据或包含访问令牌的客户端截图。
选线结论：优先选择在常用时段能够持续完成目标任务、波动较小且路径可确认的线路。峰值更高但经常中断，不一定更适合日常使用。保留另一条经过验证的候选线路，比追逐一次最高读数更实用。
如果所有线路同时变慢，先检查本地网络和设备；只有某个出口异常，再比较其他出口；只有某个目标服务异常，则继续检查规则、解析和目标端限制。按这个顺序排查，才能减少盲目换线路。客户端与导入方式可查阅使用教程，地区与线路信息以节点页面和客户端实际列表为准。