VPN速度实测怎么做：自己客观测速的方法、工具与时段

想知道VPN速度实测怎么做，先接受一个前提：单次测速只是一个样本，不是结论。同一条线路，上午和晚高峰可能给出完全不同的数字；换一个工具、换一个测速服务器，结果又会差出一截。要判断一条线路能不能满足自己的使用场景，需要固定变量、分时段重复，并且同时看延迟、抖动、丢包和吞吐四项指标。下面这套流程不需要专业知识，用系统自带命令和几个常见工具就能跑完。

先分清四个指标：延迟、抖动、丢包、吞吐

测速页面上最显眼的那个数字只是吞吐，它回答不了「为什么看视频会卡」。四项指标各有分工，缺一项都可能误判：

• 延迟（RTT）：一个数据包从设备到目标服务器再返回所需的时间，单位毫秒。挂上代理后，这段往返包含「设备 → 出口节点 → 目标」两段，天然比直连大一些，所以只在同一目标、同一工具之间横向比较。
• 抖动：连续多个包延迟的波动幅度。视频卡不卡、语音断不断，抖动比平均延迟更关键——平均延迟不高但抖动大，体感会比稳定略高的延迟更差。
• 丢包：发出的数据包里没有到达的比例。少量丢包就会触发重传，吞吐随之下降；基于 QUIC 的协议对丢包的处理方式与 TCP 不同，表现也不一样。
• 吞吐：单位时间内实际传输的数据量。要区分单线程与多线程：单线程更接近单个文件下载、单个视频流的体验，多线程更接近测速网站的跑分。

测速前先固定变量：设备、协议与连接方式

测速结果里最容易混进来的不是线路差异，而是你自己的变量。同一个节点，换台设备、换个协议、换成无线，数字可能差出一大截。测试之前，先把下面几项固定住：

• 设备与网络：同一台设备、同一条网络，优先有线；用无线时固定频段与位置，中途不换。
• 后台流量：关闭系统更新、网盘同步与云备份，其他设备暂停大流量任务。
• 协议：Shadowsocks、VMess、VLESS、Trojan 走 TCP；Hysteria2、TUIC 基于 QUIC 走 UDP。同一节点上不同协议的表现可能不同，国际链路出现丢包时差异更明显。比较节点时，不要一边换节点一边换协议。
• 多路复用（mux）：把多条连接复用进一条 TCP 连接，遇到丢包时容易受队头阻塞影响，单线程吞吐会偏低。要么统一关闭，要么统一开启，别混着比。
• 规则模式：分流模式下，如果测速目标命中了直连规则，你测到的其实是直连速度。测试前确认目标走的是代理。

常用工具与它们各自适合测什么

工具不在于多，而在于每一项指标都有对应的测法。下面这些覆盖了从延迟到吞吐的检查项，选两三个组合使用就够：

时段怎么选：晚高峰与空闲时段各测几轮

跨境链路的负载有明显的时段特征。工作日 20:00–23:00 通常是晚高峰，国际出口最拥挤，延迟抬升、丢包更容易出现；上午 9:00–11:00 与下午 14:00–16:00 相对空闲，数字更接近线路本身的上限。每个时段至少测 3 轮，每轮间隔几分钟取中位数，并且至少跨两天——工作日与周末各测一轮。只测一次得到的好数字，说明不了任何事。

一套可复用的测速流程

先把测前清单过一遍，再按顺序执行。整轮测试建议控制在 15 分钟以内，避免拖到时段边界上：

• ✅ 用网线，或固定在 5GHz 频段，测试全程不换位置、不切网络。
• ✅ 关闭系统更新、网盘同步、云备份与正在进行的下载任务。
• ✅ 整轮测试只用同一节点、同一协议、同一 mux 设置。
• ✅ 确认规则模式与测速目标，别让「直连」混进代理结果里。
• ❌ 不要在公共 Wi-Fi 或手机热点上做对比，这类链路本身就有额外限制。
• ❌ 不要把一次测出的最高值当成线路水平。

1. 测基线：不挂代理，对同一个测速服务器跑一轮，记下延迟与吞吐。
2. 连接节点后连续 ping 100 个包，记录延迟区间与丢包情况。
3. 跑一次 mtr（或 tracert），观察国际段是否持续丢包。
4. 用同一个测速服务器跑多线程吞吐，再用单线程下载跑一次，两个数字都记下来。
5. 回到真实场景：打开常用的视频或网盘，实际传输 1–2 分钟，观察是否降码率。
6. 晚高峰重复第 2–5 步，把两轮结果放在一起对比。
7. 连续记录 3 天，用中位数而不是最高值作为该节点的代表数字。

# Windows：连续发送 100 个包
ping -n 100 1.1.1.1

# macOS / Linux：同样的包数
ping -c 100 1.1.1.1

# 单次请求的耗时与下载速度，重复多次取中位数
curl -o /dev/null -s -w "%{time_total} %{speed_download}\n" https://example.com/file

结果怎么读：别被单次峰值误导

几个常见的「数字虚高」来源，遇到时要在记录里备注，而不是直接采信：

• TCP 慢启动与突发额度：连接刚建立时速度还在爬升，测得太短容易截到爬升段或短暂的突发段。
• 缓存命中：反复测同一个地址，可能命中 CDN 缓存，数字好看但不代表出口带宽。
• 测速服务器位置：测速点与节点同城同机房时，测到的更接近机房内网速度，而不是你访问目标网站的速度。
• 单线程与多线程的差距：多线程跑得满、单线程跑不动，说明瓶颈在单条连接的调度上，下载大文件时最容易察觉。

常见误区与换节点的判断

还有一个常被忽略的点：如果测速数字正常，但打开网页的第一步特别慢，先排查 DNS。部分客户端提供「远程解析 / 本地解析」选项，本地解析会让域名解析走本地网络，既可能拖慢首次访问，也会造成解析请求没走隧道（也就是常说的 DNS 泄漏）。这类问题不会体现在吞吐数字上，要单独确认。

出现下面这些情况，再考虑换节点，而不是凭一次测速就下结论：

• 晚高峰连续多天出现丢包，且 ping 与 mtr 都能复现；
• 单线程吞吐长期低于目标场景所需，而多线程吞吐正常；
• 抖动明显，视频频繁降码率、语音断续。