speedtest测公网出口带宽，iperf3测内网真实链路吞吐；前者看服务器到speedtest节点的下载/上传能力，后者通过客户端-服务端直连测试tcp/udp带宽、丢包、延迟等指标。
speedtest 和 iperf3 是 Linux 上测带宽最常用的两个工具，但它们解决的问题完全不同。别一上来就跑 speedtest —— 它测的是你服务器到公网 Speedtest 服务器的路径性能，和你实际业务流量（比如两台内网服务器传文件）完全不是一回事。
用 speedtest 测公网出口能力，但要注意它不反映真实业务链路
如果你要确认服务器是否“连得上外网”、运营商给的带宽是否达标，或者排查公网访问慢是不是出口问题，speedtest 是最快入口。
- 官方 CLI（推荐）：下载
ookla-speedtest，不是旧版speedtest-cli；后者已停止维护，结果偏差大 - 执行
speedtest后会自动选服务器，但这个“最优”只是 ping 最低，未必适合你的业务地理位置（比如你在广州，它可能选了上海节点，而你用户全在成都） - 想手动指定节点？先运行
speedtest --servers查 ID，再用speedtest --server-id=12345强制测试 - 注意单位：
Download: 95.2 Mbit/s是 Mbps，不是 MB/s；除以 8 才是理论最大文件下载速度（约 11.9 MB/s）
常见误判：看到下载只有 50Mbps 就断定“带宽缩水”，但可能只是测试节点远、中间路由绕行、或被 QoS 限速——speedtest 本身不告诉你丢包或抖动，这些才是 TCP 性能杀手。
用 iperf3 测真实业务链路吞吐量，必须两端都装
当你怀疑“内网传文件慢”“数据库主从同步卡”“对象存储上传掉速”，就得用 iperf3 直接打穿链路。它不走公网，不经过 CDN 或 DNS，测的就是两台机器之间裸连能跑多快。
- 服务端启动：
iperf3 -s（默认监听5201端口）；如需后台常驻，加-D；换端口用-p 5202 - 客户端发起：
iperf3 -c 192.168.1.100（填服务端内网 IP） - 关键参数组合：
-
-t 30：测满 30 秒，避免短时抖动干扰 -
-P 4：开 4 个并行流，模拟多线程下载/上传行为（单流往往跑不满千兆网卡） -
-R：反向测试，让服务端发、客户端收，专门看上行能力（比如你做视频推流服务器） -
-u -b 100M：UDP 模式下压测 100Mbps，同时看丢包率和 jitter（TCP 隐藏了这些问题）
-
防火墙必须放行对应端口（5201 或你自定义的），且两端路由可达；如果测出来只有理论值的 60%，优先查 ethtool eth0 看网卡是否协商成千兆全双工，而不是百兆半双工。
iperf3 输出里真正要看的三行指标
别只盯着 “936 Mbits/sec” 这个数字。一次测试输出里，这三行决定你能不能放心上线：
-
[ID] Interval Transfer Bitrate下面的sender行：客户端发出的数据速率（你主动发了多少） - 同一行的
receiver行：服务端实际收到的速率（有没有被中间设备限速或丢包） - 如果用
-u（UDP），最后一行会有0% packet loss和jitter；哪怕丢包率只有0.2%，TCP 实际吞吐量可能直接腰斩
一个典型陷阱：客户端显示 940 Mbits/sec，服务端只收到 480 Mbits/sec —— 这说明链路中某处（交换机、安全组、虚拟网卡驱动）存在隐性限速或缓冲区溢出，speedtest 根本发现不了。
别忘了先排除基础层问题：网卡、驱动、MTU
所有带宽测试前，花 2 分钟确认底层没硬伤：
- 运行
ethtool eth0，检查Speed是不是你预期的值（1000Mb/s），Link detected是yes，Duplex是Full - 查看中断分布：
cat /proc/interrupts | grep eth0，如果所有中断都挤在 CPU0 上，多队列网卡可能没启用，会成为瓶颈 - MTU 默认是 1500，但某些云厂商（如阿里云 VPC）要求设为
1500，AWS ENA 网卡建议9001；错配会导致分片、重传，吞吐骤降 - 用
ping -s 1472 -M do 192.168.1.100测试路径 MTU（1472 + 28 字节 IP+ICMP 头 = 1500），不通就逐步减小，找到真实上限
很多所谓“带宽异常”，最后发现是网卡驱动没更新、MTU 错配、或交换机端口被限速到 100Mbps —— 这些问题 speedtest 和 iperf3 都不会主动告诉你，得自己动手筛。
