2026年机场线路带宽自测手册：iperf3 与下载法怎么测出可信吞吐，晚高峰采样脚本与记录表怎么搭

「我这条线路到底有多少带宽？」——这是机场用户问得最多、也答得最乱的一个问题。同一个节点，有人上午跑出 400Mbps，晚上只剩 60Mbps；有人在电脑上测出 300Mbps，换到手机上只有 80Mbps。多数时候不是线路在骗人，而是两边测的根本不是同一件事。

这篇文章只做一件事：把「测出来」这件事做成有可比性、能长期留存的流程。已经明确变慢、需要定位是哪一段坏掉的读者，可以先看分段排障那一套；本文处理的是它前面一步——在还没坏、或者刚换机场的时候，怎么建立一套自己看得懂的测量与记录方法。路径结构的真伪判定（跳数、AS 号、去程回程）属于另一条线，方法在路由追踪与去程回程判读里，本文不重复。

一、你要的不是一个数，而是四个数

「带宽」这个词在实际使用中至少混了四件事，它们由不同的机制决定，也会在不同的场景里咬人。把它们分开测、分开记，后面的判断才有依据。

指标	怎么测	它回答什么问题	最常见的误读
单线程上限	单条连接拉一个大文件（iperf3 单流、curl 单连接下载）	网页、视频、语音会议、SSH 这类「一条流」的日常体验	把单线程的数值当成线路的全部能力
多线程上限	并行 4 到 8 条连接（iperf3 -P 4~8、下载器多线程）	大文件、系统更新、多任务并发的峰值潜力	拿多线程峰值去解释「为什么看视频还是卡」
晚高峰保留率	同时段、同测速点、同线程数，早晚各测一轮	这条线路在最挤的时候还剩几成	用一次峰值当作「我的网速」
稳定性（丢包与抖动）	ping/mtr 取 p95 与丢包率；长连接任务观察是否掉线	通话、游戏、直播推流、长时间下载能不能扛住	只看平均延迟，不看抖动与丢包的尾部

测速工具给你的通常是四个数里最乐观的那一个——多线程峰值。它有用，但只说明「理论上限在哪」，不说明你晚上八点看 4K 会不会转圈。另外三个数必须自己测。

测量纪律三条，先记下来，后面每一步都靠它：一，只记录命令和原始输出，不记「感觉快了很多」；二，每次只改一个变量（换节点就不要再换测速点）；三，每条记录必须带时段，没有时段的数字没有意义。

二、三个不可比变量：不控制它们，任何对比都是错的

为什么网上关于机场速度的争论永远没有结论？因为各人报的数字背后站着三个没被控制住的变量。

变量	它造成多大差异	怎么固定下来
测速点（服务器）	同一城市的不同测速服务器能差出数倍；跨运营商更明显	写死一个 URL 或一个服务器 ID，长期只测它
线程数	单流与 4 流的差距可能从「不合格」变成「很充裕」	记录里写清「单流」还是「4 流」，两者不混着比
时段	晚高峰与凌晨的差距是所有变量里最大的	固定两三个采样窗口（如 09:00、20:30、23:30）

还有一个容易被忽略的隐性变量：测量设备本身。同一份订阅，在台式机有线网上测、在笔记本 Wi-Fi 上测、在路由器侧测，得到的是三条不同的链路。报告结论时必须说清「在哪测的」——这也是后面要先搭基线的原因。最后一个变量经常被误当成速度变量，其实根本不是：出口 IP 的属性（数据中心、原生、住宅）影响的是服务侧怎么看待你——注册、风控、地区内容——而不是吞吐。它真正的用处在账号与解锁场景，例如仙路湾提供原生 IP 与住宅 IP 两档，解决的是注册与多账号环节的待遇问题；把它塞进速度对比里，只会得到没有意义的结论。

三、动手前先搭三条基线

没有基线的测速，本质是在测「你的设备上限」而不是「线路」。三条基线花不了十分钟，但能帮你排掉一半的误判。

3.1 基线一：设备与工具链的上限（回环基线）

先用只走本机回环的传输，量出「测量链本身」能跑多快。这一步不需要网络、不涉及任何机场：

# 造一个 100MB 测试文件（只写一次，之后复用）
python3 -c "import os;open('blob100.bin','wb').write(os.urandom(1048576)*100)"

# 起一个只监听回环的静态服务
python3 -m http.server 18081 --bind 127.0.0.1 &

# 量一遍本机传输链（%{speed_download} 单位是字节/秒）
curl -s -o /dev/null -w '%{speed_download} B/s  %{time_total} s\n' http://127.0.0.1:18081/blob100.bin

在一台 i5-8265U（8 逻辑核）、7.8GB 内存的笔记本上，这条回环基线跑出两次读数：2381 MB/s（约 19.0Gbps）与 2846 MB/s（约 22.8Gbps）。含义很直接：测量链的上限在万兆以上，所以后面测出的任何一个两位数 Mbps，都不可能是本机 CPU、磁盘或 curl 造成的。如果你的回环基线只有一两百 Mbps，先解决设备问题（单核跑满、无线驱动、虚拟化开销），否则后面所有数字都没意义。

注意这是回环基线，不含任何网络路径，它只是你的「仪器量程」，不要拿它当「我的网速」。

3.2 基线二：不挂代理的家宽直连基线

第二个基线是用同样的命令、同样的测速点，在不挂代理的情况下测一遍。它有两个作用：一是算出你这条宽带的实际可用值（很多 500M 宽带的实测单流只有 200 到 300Mbps），二是给后面「代理后掉了多少」提供分母。直连基线不达标时，先怀疑宽带、光猫、路由器与 Wi-Fi，而不是机场。

3.3 基线三：对照探针——证明你的工具能区分「测不到」和「慢」

这一步常被跳过，但它决定你的数据能不能信。用 RFC 5737 保留地址做探针，这些地址在公网上永远不会有人应答，所以正确的输出必然是「全不通」：

ping -c 3 -W 2 192.0.2.1        # RFC 5737 保留地址，不应有任何回应
ping -c 3 -W 2 198.51.100.7
mtr -rwzc 5 192.0.2.1

实测输出：两个保留地址都是 3 packets transmitted, 0 received, 100% packet loss；mtr 前 3 跳延迟 1.7 / 2.3 / 3.8 ms，从第 4 跳起 100% 丢包。这正是「本地链路正常、目标不可达」的标准形态。

为什么值得跑：如果保留地址居然「通了」，说明你的流量被某个代理或网关接管并伪造了回应，那么后面所有测速数字都不可信；反过来，当你在真实测速里看到 100% 丢包或超时，跑一遍对照探针就能立刻区分「目标真的不可达」还是「工具环境坏了」。

3.4 对照订阅样本

三份基线之外，再准备一份对照订阅样本：留一份你已知可用、额度足够的订阅，测新线路时拿它跑同一套命令，可以在怀疑「节点坏了」和「测量方法有问题」之间做二分。用入门档就够——例如瑶瑶领先的小流量档（¥9.9/月、384GB）这类额度明确、价格低的入门套餐，适合当长期跑脚本的对照，不用担心测量本身吃掉太多流量。

四、iperf3：默认值里有三个坑

iperf3 是这条赛道上最权威的吞吐测量工具，但它的默认参数是为「典型应用表现」设计的，直接跑会得到偏低的结论。以下事实取自 iperf3 官方手册（3.22 版）：

坑一：默认只跑 10 秒，而且包含 TCP 慢启动。-t 默认 10 秒；官方专门提供了 -O, --omit n（先热身 n 秒，把这段的统计丢掉）来跳过慢启动期。不热身就直接看 10 秒的平均值，等于把最差的起步阶段算进了成绩。
坑二：UDP 模式默认限速 1Mbit/s，TCP 不限速。官方对 -b 的说明是「default 1 Mbit/sec for UDP, unlimited for TCP/SCTP」；而且「有多条流（-P）时，限速是对每条流分别生效」。所以 UDP 测出 1Mbps 不是线路问题，是参数问题；要压满必须显式 -b，或用 -b 0 解除限制。
坑三：单流测到的低值，不等于线路差。官方对 -P 的原文是「Using multiple streams may result in higher throughput than a single stream, in cases where network throughput is CPU-limited」——当吞吐受 CPU 限制时，多流会明显高于单流。另外从 3.16 起，每条流会各自起一个线程。反过来我们也该记住：多流高、单流低，说明瓶颈在你的单流窗口或单核处理能力上，而不是线路本身。

下面这张表把上面三个坑对应的参数，以及其余几个常用参数的默认行为一起列了出来——写命令前扫一眼，能省掉一次返工：

参数	默认行为	不处理会怎样	建议写法
-t / -O	跑 10 秒，含慢启动	平均值被起步阶段拉低	`-t 30 -O 5` 先热身 5 秒
-b（UDP）	1Mbit/s，且按流分别限制	误判为「线路只有 1M」	明确给目标值，或 `-b 0`
-P 线程数	1 条流	把「单核/单流上限」当成线路上限	单流与 `-P 4` 各跑一轮，都记
-R 方向	默认客户端发送（测上传）	拿上传值讨论下载体验	测下载必须加 `-R`
--get-server-output	不返回服务端输出	只有单侧视角，看不到对端统计	加上它对比两端；注意只有完整跑完才有
-J / --json-stream	人类可读输出	结果没法入库做长期曲线	自动化采集时用 `-J`

服务端还有两个事实值得知道：一是默认端口是 5201，控制连接与数据连接是分开的两条（-R 会把数据方向反过来）；二是服务端有 -1, --one-off（处理完一个客户端就退出）和 --server-bitrate-limit（服务端侧限速）。这意味着——公共 iperf 服务器上的限速，测出来的是「人家给你的配额」，不是任何线路的真实能力；而自己临时开服务端时，-1 能省去忘记关端口的麻烦。

最后一个常见坑：用「公网随机 iperf 服务器」测机场。你测的是「机场出口 → 那台公网服务器 → 回家」这条完整路径，结果里既有你的宽带、也有那台服务器的共享带宽。要做对照，更有意义的是固定同一个目标（同一个测速点、同一个大文件地址），只切换机场出口——例如用多地区节点齐全的自由猫，在同一测速点分别走它的不同地区节点，就能看出「同一家机场的地区差异」有多少（它走自家客户端，适合作客户端侧对照，不适合放进软路由或透明代理做路由器侧测量）。

五、没有服务端的三种替代测法

iperf3 需要两端可控，日常采集用起来太重。三种替代方案各自够用，但要清楚它们的偏差在哪。

5.1 curl 下载法（推荐做长期采样）

找一个长期稳定的大文件地址，用 curl 只取字节、不落盘，直接从 write-out 变量读速率：

curl -s -o /dev/null --max-time 30 \
  -w '%{speed_download} %{time_total} %{size_download}\n' \
  https://example.com/bigfile.bin

%{speed_download} 的单位是字节/秒，乘 8 才是 Mbps，这一步换算错的人不少。另外要留意：--max-time 30 截断时，%{speed_download} 统计的是已传部分除以实际用时，仍然有效，但要保证 %{size_download} 不为 0，否则那条记录是无效采样。

关键一步：用已知上限校验你的测量链。curl 的 --limit-rate 可以人为限速，这就给了你一个「已知上限」来验证读数是否可信。实测：--limit-rate 5M 回读到 5,367,376 B/s（约 42.9Mbps），--limit-rate 20M 回读到 21,457,704 B/s（约 171.7Mbps）——读数比标称高 2% 到 7%，属正常范围，说明这条测量链在已知上限下是可信的。如果哪天回读值比标称高一倍或低一半，那说明中间有东西在接管流量（代理、加速器、企业网关），此时任何测速结论都要先打问号。

5.2 Ookla Speedtest CLI

官方定位是「在命令行测量下载、上传、延迟与丢包，支持脚本化采集趋势，输出 CSV、JSONL 或 JSON」。安装方式是各平台的官方仓库，比网页版更适合进脚本。它的主要偏差是：测速服务器由客户端挑选，「同一城市不同服务器」本身就可能造成数倍差距——所以用它做长期记录时，务必固定服务器，不要每次让它自动选。

5.3 浏览器/下载器多线程下载

最接近真实体感，尤其是下载器开 8 到 16 连接时。偏差在于源站与 CDN 的限速——大厂 CDN 通常很快，小站可能单连接限 5MB/s，这时候你测的是源站而不是线路。

下面这张表把四种方法放在一起对比（iperf3 也列进来做对照），选法很简单：做长期采样用 curl 下载法，做一次性峰值对比用 Speedtest CLI 或下载器。

方法	需要什么	能测什么	最大偏差来源
iperf3	两端可控（自己开服务端或对方提供）	净吞吐，含 UDP 丢包与重传	公共服务器限速、未热身、参数默认值
curl 下载法	一个稳定的大文件地址	单连接真实吞吐，适合长期采样	源站/CDN 限速、中间接管
Speedtest CLI	官方客户端	多连接峰值 + 延迟 + 丢包	测速服务器自动挑选
下载器多线程	一份大文件	最接近日常体感的峰值	源站限速、磁盘写入

六、单线程和多线程差的到底是什么

这个差异不是玄学，主要是两件事：窗口大小与 CPU。

先看窗口。单条 TCP 连接的吞吐上限约为「在途字节数 ÷ 往返延迟」，在途字节数又受本机缓冲区限制。这是一台普通 Linux 笔记本的实际取值（sysctl 直接读，不是猜的）：

net.ipv4.tcp_rmem = 4096  131072  33554432      # 接收缓冲，最大值 32MiB
net.ipv4.tcp_wmem = 4096  16384   4194304       # 发送缓冲，最大值 4MiB

按这两个上限，在 200ms 往返延迟（跨境线路的常见量级）下单流的理论上限是：发送方向 4194304 字节 × 8 ÷ 0.2 秒 ≈ 167.8Mbps；接收方向 33554432 × 8 ÷ 0.2 ≈ 1342Mbps。这解释了为什么很多人单流卡在 150 到 200Mbps 上不去——先看自己的缓冲区，而不是先骂机场；也解释了为什么把 -P 开到 4 或 8 以后数字会跳一截。

再看 CPU。走代理后，每一个字节都要经过加密或协议封装，这是纯 CPU 的活。单核跑满时，吞吐就不再由线路决定。判断方法很土但有效：测速时开着 top 或 mpstat -P ALL 1，如果某个核心长期贴着 100%，那台机器就是瓶颈。老 CPU 上这种情形很常见，用 iperf3 官方的 -Z（零拷贝）能显著降低 CPU 占用，但官方也明说 -Z 和 -A（绑核）属于「极端最优情况」的开关——只在排查 CPU 瓶颈时用，不要在日常结论里用它。

结论一句话：单线程数值对应你的日常体验（网页、视频、语音），多线程数值对应峰值潜力（大文件、多任务）。两个数都要记，混着用就会得出相反的结论。

如果确认瓶颈就是在本机 CPU，有两个处置方向：一是换更省 CPU 的协议与客户端设置（降低加密封装开销、开启多路复用）；二是把客户端从电脑挪到路由器侧，让转发压力由路由器承担。这也是很多人做长期采样时偏好能在路由器上跑标准订阅的机场的原因——例如官方支持 OpenWrt、订阅可以直接导入 PassWall 与 OpenClash 的SS-ID，把客户端挪过去以后，本机 CPU 这个变量就不存在了，测出来的数字更接近线路本身。

七、代理链路上特有的五个偏差源

同样的线路、同样的测速点，挂了代理以后数字还会再变一次。原因集中在这五处，逐条都有办法排除。

偏差源	典型表现	怎么排除
协议封装与加密开销	同一目标直连与代理差值稳定在某个百分比	先记直连基线，把差值本身当成正常损耗
客户端转发占用 CPU	多线程能上去、单线程上不去；某核贴 100%	top/mpstat 观察，或把客户端挪到路由器侧
接管方式不同	TUN、系统代理、浏览器插件三种方式读数不同	固定一种接管方式，不混用
分流规则没命中	以为在测代理，其实走了直连	测前后各查一次出口 IP，确认确实变了
限速条款而非带宽	每到固定用量后掉到固定值	区分「额度（GB）」与「速率（Mbps）」，口径详见流量计费陷阱那篇

第三、第四两条最容易被忽略，也最容易造成假结论：一次测试里如果规则把测速域名判进了直连，你测出来的就是家宽而不是机场，数字会好看得离谱。养成习惯——每次测速前后各查一次出口 IP，两次一致且不是家宽出口，这条记录才算数。

第二条（CPU）的排除办法与处置方向，上一节末尾已经给了。

八、晚高峰采样：脚本、CSV 与百分位口径

单次测速只能证明「那一刻」，要判断一条线路值不值，需要连续采样。下面这个脚本可以直接用，每 10 分钟记录一条，方便你晚上挂着跑去睡觉：

#!/usr/bin/env bash
# peak-watch.sh —— 定期记录单连接吞吐，追加到 CSV
# 用法: ./peak-watch.sh <大文件URL> [输出CSV]
URL="$1"; OUT="${2:-peak.csv}"
[ -f "$OUT" ] || echo "ts,epoch,speed_Bps,time_s,size_B" > "$OUT"
while true; do
  read -r sp tm sz < <(curl -s -o /dev/null --max-time 30 \
      -w '%{speed_download} %{time_total} %{size_download}' "$URL")
  printf '%s,%s,%s,%s,%s\n' "$(date '+%F %T')" "$(date +%s)" "$sp" "$tm" "$sz" >> "$OUT"
  sleep 600
done

隔天早上用下面这段统计出三个百分位（P10 / P50 / P95）。百分位口径必须写清楚，这里用的是「最近秩」定义：把 N 个采样升序排列，第 k 个采样即为 P(k/N)。

awk -F, 'NR>1 && $3>0 {print $3}' peak.csv | sort -n | awk '
function idx(p, n,   i) { i = int(n*p); if (i < 1) i = 1; if (i > n) i = n; return i }
{ v[NR]=$1 }
END {
  if (NR==0) { print "无有效采样"; exit }
  n = NR
  printf "n=%d  P10=%.1f MB/s  P50=%.1f MB/s  P95=%.1f MB/s  max=%.1f MB/s\n",
    n, v[idx(0.10,n)]/1e6, v[idx(0.50,n)]/1e6, v[idx(0.95,n)]/1e6, v[n]/1e6
}'

这段脚本本身值得先验一遍：函数必须定义在 awk 程序的顶层，写进 END 块里会直接 syntax error 退出，一个数据都算不出来。用五条假采样试跑，输出为 n=5 P10=1.9 MB/s P50=3.1 MB/s P95=9.4 MB/s max=12.5 MB/s，说明取值顺序与下标都没错。

为什么不用平均值：平均值会被少数几个高峰拉回来，看起来「还行」，而你实际感受到的是那些掉下去的时刻。对速率来说，真正有用的三个数是——P95 代表峰值（前 5% 的时刻才有这个水平），P50 代表日常中位体验，P10 代表「最差的那些时刻有多差」，也就是 10% 的采样比它更慢。报告结论时把三个数一起给，别人才能复现你的判断。

采样还有两个操作细节：一是采样间隔不要拉长到小时级，晚高峰的拥堵是有起落节奏的，10 到 15 分钟一次才能看出形态；二是跨国采样会持续消耗流量，做个简单的预算——单次采样按 30 秒、30Mbps 估算约 112MB，一晚上 60 次约 6.7GB，长期跑建议用额度充足的对照订阅，或者把单次时长压到 15 秒。

九、把数字变成结论：四条判据与超售的估算边界

数据齐了之后，用四条判据下结论。这几条都是经验口径，不是行业标准，但它们比「感觉快不快」稳定得多。

判据一：单线程保留率 = 晚高峰 P50 ÷ 空闲时段 P50。经验分档是：0.7 以上基本无感；0.4 到 0.7 能明显感到变慢，视频会降码率；0.4 以下会影响视频会议与实时类应用。注意一定要用同线程数的数据去比，拿晚高峰单流比空闲时段多流，会得到一个虚假的糟糕结论。

判据二：丢包与抖动看尾部。晚高峰 p95 延迟抖动超过空闲时段的三倍，或者丢包率稳定超过 1%，就说明链路进入了拥塞状态。抖动比平均延迟更能提前预警——通话卡顿往往在平均延迟还「正常」的时候就已经开始了。

判据三：看曲线形态，区分「限速」与「拥塞」。阶梯式下跌——到某个时间点一次性掉到某个固定值并稳定住，是限速或超售的典型特征，因为限速值是配置出来的常数；平滑下滑——随上网人数逐渐推进而连续下降，更像公网出口拥塞。前者是供应商策略问题，后者是大盘问题，处置方式完全不同。

判据四：多线程峰值 ÷ 套餐标注值。多数套餐标注的带宽是节点或端口的理论上限，不是保证值。常态下多线程峰值能达到标注值的五成以上，可以认为兑现了大部分承诺；长期只有两成以下，就属于需要换的信号。

关于「超售」还有一条要讲清边界的估算：同出口可容纳的并发用户数上界 ≈ 出口总带宽 ÷ 单用户晚高峰峰值。举例，一个 10Gbps 的出口，用户晚高峰单点峰值按 50Mbps 算，理论上界约 200 人；如果同档套餐卖出了几百份且都在线，挤是必然的。必须强调这是估算模型——机场的真实出口带宽和在线用户数是黑盒，你只能反推，不能确证。反推的价值在于判断「这条线路的拥挤是结构性的还是偶发的」：如果每天同一时段阶梯式下跌，结构性问题换时间也躲不掉。

另外要避免把两件事混为一谈：出口 IP 的属性影响的是「服务侧怎么看待你」——账号风控、地区内容、验证码频率——而不是峰值带宽，这一点在第二节已经交代过。如果你测出来的问题是晚高峰掉速，那么换出口 IP 类型不会提速，那是线路与超售的账。

十、四个最常见的误判

误判	为什么错	正确做法
用 Wi-Fi 下的数字评价线路	无线协商速率、干扰与信号强度都是隐藏上限	换有线测一次，作为正式结论的依据
拿国内测速点测机场	测的是你到国内测速点的速度，与跨境线路无关	测速点放在境外，或测境外大文件
单线程不达标就换机场	窗口、CPU、封装都会压低单流数值	先跑三条基线，再跑多线程对照
拿一次峰值当日常水平	峰值是最好那 5% 的时刻	用 P50 与 P10 描述日常，峰值另记

把这四条反过来看，其实就是一套完整的自检顺序：换有线 → 固定境外测速点 → 排除设备与参数 → 用百分位而不是峰值下结论。

十一、常见问题

Q1：没有 iperf3 服务端怎么办？三个选择：用 curl 下载法（不需要服务端，最省事）；用 Speedtest CLI；如果自己有 VPS，用 iperf3 -s -1 临时开一个一次性服务端，测完自动退出，不用记着关端口。

Q2：手机上怎么测？安卓可以用 Termux 跑同一套 curl 命令，或用官方的 Speedtest App。注意两点：手机 Wi-Fi 与后台限制会带来额外变量；息屏后系统可能限制后台网络活动，采样脚本在手机上跑要开「不受电池优化限制」，否则数据会有大片空洞。

Q3：测速时要关掉其它设备吗？要。同一出口被家人占用时，读数无法归因到线路，尤其是上行与晚高峰场景。至少要在记录里备注「同时有其它设备在用」。

Q4：为什么同一个节点上午 400M、晚上 80M？最常见的两个原因：出口超售（结构性问题，见判据三的阶梯形态）与跨境公网拥塞（大盘问题）。区分方法是看曲线形态；两者都躲不开时，才是考虑换线路或加中转的时机。

Q5：套餐标「1000Mbps」是什么意思？多数情况下是节点或端口的理论上限，不是保证值。用判据四校验：常态多线程峰值能到标注值五成以上，就算兑现得不错。

Q6：测出来的数偏低，一定要换机场吗？不一定。先按顺序排除：回环基线（设备行不行）→ 直连基线（宽带到不到）→ 对照探针（工具可不可信）→ 出口 IP 是否真的变了（测的是不是代理）→ 多线程对照（是不是单流上限）。这五步走完仍然低，才是线路的问题。

十二、一页速查

十分钟流程，按顺序执行：一，跑回环基线，确认仪器量程；二，跑对照探针，确认工具可信；三，记录直连基线（同测速点）；四，挂代理后跑单流与多流各一轮，记下出口 IP；五，晚上按 10 分钟间隔跑采样脚本，隔天算 P10/P50/P95。

记录表建议八列：时间、时段标签（空闲/晚高峰）、路径（直连/某节点）、线程数、速率、丢包或抖动、出口 IP、备注（是否多设备共用）。八列里最容易漏的是时段标签与出口 IP，而这两列恰恰是后面做归因的关键。

最后一句：这套方法的价值不在于测出某个漂亮数字，而在于当你想换机场、想投诉、想判断涨价是否合理时，手里有一份自己攒的、口径一致的记录。测速工具给你的是最好看的那个数，剩下的三个数得自己攒。