线路怎么测速才有参考价值？指标、步骤与记录模板

测速首先要回答一个具体问题：网页打开慢、会议容易中断，还是下载达不到需求？这三件事需要不同指标。本文提供一套可以自行执行并留存证据的流程，示例表格是空白模板，没有代表本站的实测结果。

先确定你在测哪一段

一条代理连接可以简化为“设备 → 入口 → 中转或跨境段 → 出口 → 目标网站”。不同工具看到的范围不同：

测量	实际看到什么	不能直接说明什么
ping 入口地址	设备到响应 ICMP 的入口地址的往返情况	出口访问网站的速度、完整代理可用性
mtr/traceroute 到入口	可回应探测的入口前逐跳路径	隧道内部路由、回程的完整路径
客户端延迟	该客户端定义的某种探测耗时	跨客户端统一的 RTT，或持续下载速度
显式经代理的 HTTP 请求	该节点到指定目标的完整请求表现	其他网站、其他协议和其他时段的体验
固定文件下载	此时此目标的端到端吞吐	长期带宽保证、线路类型或 UDP 质量

不要把 ping 失败记成“代理不可用”：入口可能不回应 ICMP。反过来，入口延迟很低，也不能证明后半段没有拥塞。

准备条件：一次只比较一个变量

记录设备、系统、客户端和内核版本、所在地区、运营商、宽带或移动网络、有线或 Wi-Fi。尽量靠近路由器或使用有线连接，暂停大下载、云备份和其他占带宽的任务。

为每次测试固定以下条件：

• 同一节点与出口，关闭自动切换；记录规则或全局模式和实际命中的出站。
• 同一测试 URL、文件大小、超时、请求数量和并发数。
• 同一时区与时间格式；先测本地网络基线，再测代理，不把两者混写。
• 同一测试方法；比较 TCP 与 QUIC 节点时写明协议不同，不能把差异全部归因于线路。

安排至少两个平日的空闲与繁忙时段，每个时段保留一组样本。“晚高峰”以你和服务主要用户的实际作息为准；如果采用 20:00–23:00 等窗口，应记录时区，而不是把某一地区的晚上当成全世界统一高峰。

步骤一：确认本地网络没有先出问题

先关闭本次测试的代理接管，确认正常直连网络可用。对路由器和一个可稳定响应的公网目标作短时探测，例如 macOS/Linux：

ping -c 30 192.168.1.1

把地址换成自己路由器的实际地址；Windows 使用 ping -n 30 实际路由器地址。这只是局域网对照，不是代理测速。如果到网关已经明显丢包，先处理 Wi-Fi、网线或路由器，再比较远端节点。目标不响应 ICMP 时，改用正常业务连接验证，不能凭超时判定局域网断开。

接着启动代理并固定节点，用客户端连接记录确认测试流量没有误走直连。测试时只保留必要的接管方式，避免另一个 VPN 改变路径。

步骤二：记录多次完整请求

以下命令通过本地 HTTP/mixed 端口访问 HTTPS 网站。将 7890 换成实际端口，并将示例 URL 换成要比较的同一公开目标。Windows 使用 curl.exe，把 /dev/null 换成 NUL。

curl -q --noproxy localhost --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 -o /dev/null -sS -w 'status=%{http_code},first_byte_s=%{time_starttransfer},total_s=%{time_total},bytes=%{size_download},bytes_per_s=%{speed_download}\n' https://example.com/

--noproxy localhost 覆盖环境中的绕过列表，以上测试使用公开目标，不是 localhost。每个时段重复 20 次，间隔约 2 秒，记录每次结果和错误。不要通过同时跑 20 个下载来测“延迟”，那会把测试本身变成负载。需要观察连接复用时另开一组，不与逐次启动 curl 的新连接样本混合。

读数时注意：

• time_starttransfer 是从操作开始到收到首字节的总耗时，包含握手和服务器处理，不能直接称为纯网络 RTT。
• time_total 是这次完整请求的时间，受响应大小影响；同一 URL 内容变化也会影响结果。
• http_code 要结合预期判断。HTTP 403 说明已收到站点响应，却未达到“能正常使用”的业务目标；curl 不报连接错误也不等于访问成功。
• 使用本地代理时，time_connect 可能只反映连到本地代理端口；本地 time_namelookup 也不等于远端 DNS 耗时，不要据此推导完整线路的 TCP 或 DNS 指标。

如果命令无法连到本地端口，先查内核与端口；代理认证、DNS、TLS 报错应分别记录，不要全部合并成“慢”。

按同一口径保存 20 次样本

需要留存记录时，可用下面的单连接采样脚本。先把目标和端口改为自己的测试条件，并在连接列表确认出站；脚本只保存测量记录，不会选择节点。-q 必须放在 curl 的第一个参数位置，用于跳过默认 curl 配置文件，避免里面已有的重试或其他设置改变本组方法。curl 配置文件与参数

macOS / Linux 在终端运行：

test_url='https://example.com/'
sample_log="proxy-samples-$(date +%Y%m%d-%H%M%S).csv"
error_log="$sample_log.errors.txt"
printf 'sample,time_utc,exit_code,http,first_byte_s,total_s\n' > "$sample_log"
sample_id=1
while [ "$sample_id" -le 20 ]; do
  sample_stamp=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  printf 'sample=%s\n' "$sample_id" >> "$error_log"
  request_metrics=$(curl -q --noproxy localhost --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --silent --show-error --output /dev/null --write-out '%{http_code},%{time_starttransfer},%{time_total}' "$test_url" 2>> "$error_log")
  request_exit=$?
  printf '%s,%s,%s,%s\n' "$sample_id" "$sample_stamp" "$request_exit" "$request_metrics" >> "$sample_log"
  sample_id=$((sample_id + 1))
  sleep 2
done
printf '记录文件：%s\n' "$sample_log"

Windows 在 PowerShell 运行下面这组，不要粘贴到 cmd：

$testUrl = 'https://example.com/'
$sampleLog = "proxy-samples-{0}.csv" -f (Get-Date -Format 'yyyyMMdd-HHmmss')
$errorLog = "$sampleLog.errors.txt"
'sample,time_utc,exit_code,http,first_byte_s,total_s' | Set-Content -Path $sampleLog -Encoding utf8
1..20 | ForEach-Object {
  $sampleId = $_
  $stamp = (Get-Date).ToUniversalTime().ToString('yyyy-MM-ddTHH:mm:ssZ')
  "sample=$sampleId" | Out-File -FilePath $errorLog -Append
  $requestMetrics = & curl.exe -q --noproxy localhost --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 30 --silent --show-error --output NUL --write-out '%{http_code},%{time_starttransfer},%{time_total}' $testUrl 2>> $errorLog
  $requestExit = $LASTEXITCODE
  "$sampleId,$stamp,$requestExit,$requestMetrics" | Add-Content -Path $sampleLog -Encoding utf8
  Start-Sleep -Seconds 2
}
$sampleLog

两个版本都会在当前目录生成一份 CSV 和一份带样本编号的错误文件；时间记录每次请求开始时的 UTC，Z 表示 UTC。单次耗时较长时，整组可能需要数分钟，可按 Ctrl+C 中止并保留已写入的行。换节点后另跑一组，连同节点代号保存，不把两组混成同一条线路。

exit_code 为 0 只说明 curl 没有报告传输错误，仍要核对 http 是否符合任务预期。非零退出码、http=000、已收到部分数据后超时的记录都应保留；不要把其较短耗时纳入成功样本的中位数或 P95。这组脚本没有自动跟随重定向，3xx 只代表收到跳转响应；需要测最终页面时，对所有节点统一加入 --location 并另记测试口径。

步骤三：单独测持续下载

小网页主要用于观察请求是否成功和启动速度，文件太小时不能代表持续吞吐。准备自己有权访问、体积固定且已知大小的测试文件，选不会动态生成内容的地址。先从 10–20 MB 起步，再按需要增大；每次测速都会消耗套餐流量，部分节点还有倍率。

复用上面的 curl 参数，将 URL 换成测试文件，并单独记录 bytes、total_s 和 bytes_per_s。设置足以完成该文件的 --max-time，各节点使用相同值。先做三次单连接测试；若业务确实使用多连接下载，再另列一组相同并发的测试，不把两组结果放在同一列。

速度换算要统一：curl 的 speed_download 是字节/秒，换算十进制 Mbps 可用 字节/秒 × 8 ÷ 1,000,000。软件显示的 MB/s、MiB/s 和运营商标注的 Mbps 不能直接比较。

下载吞吐低可能来自目标限速、出口到目标的路径、客户端 CPU 或协议参数。换第二个独立目标对照后再推断；只有一个目标慢时，不能直接断言整条线路带宽不足。Hysteria2 等还有带宽与拥塞控制参数，也需要保持与服务方配置一致。

步骤四：有异常再看逐跳路径

先暂停 TUN 等流量接管，明确这一项是从本地直连探测入口；否则系统路由可能把探测导向另一条路径。已安装 mtr 的 macOS/Linux 可对你有权测试的入口作有限采样：

mtr --report --report-cycles 50 --no-dns node.example.com

node.example.com 是占位地址，需要换成实际入口。mtr 可能需要系统权限；未安装时可以跳过，使用系统自带的 traceroute 或 Windows tracert 观察有限路径。此项主要用于定位，不是完成整套体验测试的前提。

读图时看终点与后续跳是否一起恶化。如果某个中间跳不回应或丢包高，而后续与终点正常，可能只是路由器限速回应探测包；不要把那一跳单独标为故障。若终点也限制 ICMP，应结合 TCP 连接和真实请求。路径可能存在负载均衡且往返不对称，mtr 不能揭示全部原因，更不能证明内部专线类型。

可以直接复制的记录模板

每一行代表同一节点、同一目标、同一方法的一组样本；下载测试另写一行。

字段	本次填写
日期、起止时间、时区	待填写
地区、运营商、接入方式	待填写
设备、客户端、内核版本	待填写
节点代号、协议、入口/出口、倍率	待填写；分享时隐藏认证信息
模式、实际出站、测试目标	待填写
方法、总次数、间隔、超时、并发	待填写
预期业务成功次数 / 总次数	待填写
连接/DNS/TLS/HTTP 失败情况	待填写
成功请求首字节时间中位数 / P95	待填写；统一用毫秒
下载字节、时间、平均 Mbps	待填写；注明文件与连接数
ICMP 丢包与样本数（如有）	待填写；注明目标与方法
实际业务体验与异常	待填写

成功率为“符合预期的请求次数 ÷ 总次数”。延迟统计可以针对成功样本，但要同时保留失败数。将成功耗时从小到大排序，中位数代表中间水平；P95 可采用最近秩法，取第 向上取整(0.95 × 样本数) 个值，并在报告中固定算法。

20 个样本的 P95 只是一个粗略观察，容易受个别值影响；需要长期比较时应跨天增加样本，而不是给少量数据附上过度精确的结论。若要描述抖动，请明确采用相邻 RTT 差、标准差还是其他算法，不把不同定义的数值混比。

如何判读并决定下一步

观察结果	更值得优先排查的方向	下一步
到本地网关也不稳	本地无线、设备或路由器	修复本地基线后复测
低峰正常、繁忙时段多目标一起恶化	共享带宽、跨网路径或服务负载	保留跨天记录，对照同地区备用节点
只有单一目标慢	目标限速、出口互联或站点策略	换独立目标，保留目标维度
中位数低但 P95 高、频繁超时	偶发拥塞或不稳定连接	看失败阶段和连续业务中断，不能只选最低延迟
下载快但会议卡	延迟波动、UDP 路径或接管差异	按应用验证 UDP、丢包和出站
入口 ping 好、代理 HTTP 差	入口后的路径、出口、DNS 或服务处理	查真实请求日志并换出口对照

选择能稳定满足自身业务的一组线路，并保留独立故障路径的备用节点。测速结论只适用于所记录的网络、目标与时段；“本次测试可用”不等于年度稳定性结论，也不等于线路标签已被独立核验。

如果已有持续的高延迟或丢包，继续按 高延迟与丢包排查 缩小范围；若是在挑选服务，把这些记录带入 机场选择标准，再结合套餐、流量与售后作决定。