VPN测速实测对比，先要保证测的是同一件事。固定设备、接入网络、客户端模式和测速目标，再比较不同时段的延迟与吞吐表现。最后打开实际要用的网站或应用验证。孤立的峰值截图，不能代替日常体验。
本文提供的是可复用的测试方法，不是线路成绩榜，也没有发布未经验证的测速结果。你可以用它比较自己的候选线路，判断问题更像来自本地网络、代理路径，还是目标服务。
先确定测速目标：下载、网页还是视频
下载大文件，主要关心持续吞吐是否稳定；浏览网页，更容易感受到连接建立、域名解析和请求往返的等待；视频会议还要关注抖动、丢包以及上传表现。先写下用途，才能知道哪些指标值得优先看。
常见误区是用客户端下载峰值评判所有场景。测速工具可能并行建立多条连接，尽量占满可用带宽；实际应用却可能使用较少连接，或者受服务端限速影响。测速很高而文件下载一般，并不必然说明结果造假，也可能只是测试负载不同。
另一个误区是把节点名称里的地区当作完整路径。地区标签通常帮助识别出口，但不能单独说明入口位置、运营商互联、回程路径或拥塞情况。对比时应保留客户端显示的完整线路名称，同时记录目标服务器，而不是只写“日本线路”。
工具与指标：延迟不等于下载速度
选择能显示测试服务器、下载、上传和延迟信息的测速工具。若工具支持手动选服务器，应固定目标；若只能自动选择，就把自动分配的服务器记下来。不同目标的结果可以帮助排查，但不宜直接合并成线路排名。
| 指标 | 反映什么 | 主要用途 | 常见误读 |
|---|---|---|---|
| 空闲延迟 | 低负载时，到指定目标的往返耗时 | 初步判断交互等待 | 延迟低就一定下载快 |
| 负载延迟 | 上传或下载进行时的往返耗时 | 观察带宽占用时是否明显卡顿 | 忽略本地路由器排队的影响 |
| 抖动 | 延迟随测试样本变化的程度 | 会议、语音等实时应用 | 只看平均延迟，不看波动 |
| 丢包 | 特定探测方式下未收到响应的情况 | 结合应用表现排查不稳定 | 把探测限速当成业务流量丢失 |
| 下载与上传吞吐 | 测试期间实际传输数据的速率 | 文件传输、云端同步、视频上传 | 把瞬时峰值当成持续能力 |
客户端里的“延迟测试”也要看说明。它可能测到入口，也可能通过代理请求某个网址，还可能只检查连接是否能建立。不同客户端、不同探测地址的数字，不应直接横向比较。系统的 ping 通常使用 ICMP，也未必经过应用代理路径。
工具的单位必须保留。带宽界面常用 Mbps，下载软件可能显示 MB/s，它们不是同一种单位。记录时照抄工具原始单位，避免凭视觉比较数字大小。无法确认工具如何计算抖动或丢包时，优先在同一工具内做相对比较。
固定测试环境，再做线路对比
先测本地网络状态，再接入候选线路。未连接服务时的测试可以帮助识别接入网络问题，但不能简单称作“线路性能上限”：直连和代理可能走不同路径，目标内容分发节点也可能不同。
- 清理背景流量。暂停云盘同步、系统更新和其他下载，确认共享网络中没有明显的大流量任务。不要为了测试长期关闭系统安全功能。
- 固定接入方式。有条件时使用有线网络；使用 Wi-Fi 时保持位置和接入点不变。不要把有线结果与信号不稳定时的无线结果混为一组。
- 记录客户端环境。写下系统、客户端版本、所选线路、分流模式，以及是否启用 TUN 等网络接管功能。保持配置不变，先只切换线路。
- 固定测试目标。选择同一测速服务器，确认测试流量确实经过所选线路。切换线路后等待连接稳定，再启动测试。
- 重复并保留原始结果。轮换候选线路的测试顺序，减少先后时间造成的偏差。保留低值和失败记录，不只挑最好看的结果。
- 回到实际应用。打开常用网页、播放目标内容或进行文件传输，观察首屏等待、持续传输与中断情况。
测速会消耗真实流量，并可能在测试期间占满接入带宽。使用按流量计费的服务时，先查看余量；不要让自动测试长时间循环，也不要在正在进行的重要通话中启动满速测试。
若需要分享记录，删除订阅地址、访问令牌和账户信息。测速截图只需保留测试条件与结果，不需要展示整个客户端配置。订阅链接可能直接提供配置获取权限，不适合放进公开表格或讨论区。
时段与目标：把晚高峰纳入实测
测试时间应覆盖自己真正使用服务的时段。白天测得顺畅，不足以推断晚上也一样；某个工作日晚间表现一般，也不足以宣布线路长期不可用。给每次记录加上日期、当地时间与时区，跨时段比较才有依据。
尽量把候选线路安排在相近时间测试，并在不同日期复核。若测试过程中接入网络发生变化，应另开记录，不要继续归为同一组。汇总时可以看中位数和波动范围，但应保留原始样本，避免平均值掩盖反复中断。
目标服务器也会改变结论。测速节点本身可能繁忙，与出口之间的互联也可能拥塞；自动选点还可能随出口地区变化。固定目标适合做受控对比，允许自动选点则更接近工具的默认体验，两种方法都能用，但记录里要分开。
实际网站还会按出口地址和 DNS 结果分配内容节点。因此，“同一个网址”不一定代表“同一个服务器”。需要进一步排查时，可以记录应用报告的目标节点或连接信息；拿不到这些信息，就把结论限定为当次访问体验，不推断整条国际路径。
高分却卡顿：分流、DNS 与路径排查
先确认测速流量和业务流量是否走同一条路径。规则模式可能让测速网站直连，却让目标应用走代理；也可能反过来。系统代理通常只影响遵循代理设置的应用，不能据此推断所有程序都已被接管。TUN 模式的覆盖范围也取决于客户端、路由和排除规则。
DNS 影响域名解析和内容节点选择。若解析请求走了非预期路径，可能暴露查询给非预期解析器，或得到不适合当前出口的节点。排查时查看客户端 DNS 设置、规则日志，以及浏览器的加密 DNS 是否另有配置；不要把更换 DNS 当作必然提速的方法。
公共 DNS 检测页面能提供线索，但不能单凭解析器地区就判定泄漏。解析服务可能使用分布式节点，地址归属信息也可能不准。应结合预期配置判断请求交给了谁，再检查是否符合自己的隐私需求。调整后也要确认 IPv4 与 IPv6 的业务路径没有遗漏。
协议名称同样不能替代测试。Shadowsocks、VMess、Trojan、VLESS 的实际表现还取决于传输方式、加密配置、客户端实现和路径；Hysteria2、TUIC 基于 QUIC，遇到 UDP 受限或网络策略变化时，表现也可能不同。比较协议时，应尽量固定出口与目标；做不到，就只能评价整套配置。
IEPL 专线、中转与直连描述的是路径组织方式，不是测速成绩。专线段之外仍有本地接入和出口到目标的路径，中转也不天然等于慢。VPNGot 的具体线路信息应以服务器页面和面板展示为准，不从线路标签推导未公布的带宽保证。
记录模板与选线结论
不必为了比较线路搭建复杂系统。普通文本或本地表格就足够，关键是让后来看到记录的人知道条件是否一致。下面的模板不预填成绩，避免把示例数字误当成服务表现。
测试日期、当地时间与时区：
设备系统、客户端与版本：
接入网络、连接方式：
线路完整名称：
分流模式、DNS 与 TUN 状态：
测速工具、目标服务器：
空闲延迟、负载延迟、抖动：
丢包结果与探测方式：
下载、上传及原始单位：
实际应用体验：
异常、失败与环境变化：- ✅ 工具、目标和接入环境一致，才能把结果放在同一组比较。
- ✅ 保留常用时段的表现，优先看持续可用与波动，而不是最高峰值。
- ✅ 测速与实际应用都经过预期线路，并记录规则或模式变化。
- ❌ 不把单次超时直接判为线路失效，也不把客户端探测延迟当成所有应用延迟。
- ❌ 不公开订阅链接，不用包含凭据的完整配置充当测速证据。
选线结论：在固定条件下，优先选择常用时段表现稳定、实际应用等待较少的线路。下载峰值适合补充判断，不适合作为唯一排名依据。若所有候选线路同时变差，先复查本地网络和目标服务，再考虑调整配置。
线路体验会随接入网络、目标服务和时段变化，保留测试方法比保存一张成绩截图更有用。需要协助时，可通过面板工单提交经过脱敏的测试条件、异常时间和客户端日志片段，让排查从可复现的问题开始。