测公网带宽应指定低延迟国内节点（如上海电信id 5135）并用–csv记录，避免默认服务器路径绕行；测内网用iperf3需服务端加-d守护、客户端加-r测下行；查物理速率用ethtool而非nload；解析数据优先用–json+ jq，注意时区与硬件瓶颈。
测公网带宽：用 speedtest-cli，但别信默认节点
默认自动选的服务器经常离你物理距离近，但网络路径绕、中转多，测出来下载只有标称的一半。这不是你宽带缩水，是测试“偏科”了。
- 先列出中国境内延迟较低的节点：
speedtest-cli --list | grep -i "shanghai|beijing|guangzhou"，重点关注Latency列（低于 30ms 更可靠） - 指定服务器测速，比如上海电信节点 ID 是
5135：speedtest-cli --server=5135 --simple，--simple只输出三行，适合脚本采集 - 避免高峰时段单次测试——建议加
--csv输出到日志，配合crontab每小时跑一次：0 * * * * /usr/bin/speedtest-cli --server=5135 --csv >> /var/log/speedtest.csv - 注意 Python 版本兼容性：新系统（如 ubuntu 24.04）默认 Python 3.12，而旧版
speedtest-cli不支持；优先用官方安装脚本：curl -s https://install.speedtest.net/app/cli/install.deb.sh | sudo bash
测内网/跨机带宽：iperf3 必须分清服务端和客户端角色
iperf3 -s 启动的是监听进程，不是“后台服务”；一旦终端断开或用户退出，服务就停了——这是最常被忽略导致测试失败的原因。
- 服务端务必加
-D守护运行：iperf3 -s -D -p 5201，否则 ssh 断连即失效 - 客户端测试时，默认测的是“客户端→服务端”的上行（发送）带宽；要测下行（接收），必须加
-R参数：iperf3 -c 192.168.1.100 -R -t 20 - 别盲目加
-b（限速）参数：它只控制发包速率，不反映真实链路能力；想压满带宽，直接去掉-b，让 iperf3 自适应 - udp 测试需双方显式声明：
iperf3 -s -u+iperf3 -c 192.168.1.100 -u -b 100M，否则默认走 TCP
看实时网卡速率：别只盯 nload，先确认物理协商速度
nload eth0 显示的是当前流量，但如果你的千兆网卡实际只协商到了 100Mbps，再怎么优化应用也跑不满 1G——这个底层状态得先看清。
- 查真实协商速率：
ethtool eth0 | grep "Speed|Duplex"，输出Speed: 1000Mb/s才算真正千兆 -
nload -m能同时监控多网卡，按左右方向键切换；但注意它不区分 TCP/UDP 或进程来源，纯看总量 - 如果怀疑某进程偷跑带宽，换
nethogs：nethogs -d 2（每 2 秒刷新），它能直接定位到rsync、dockerd这类具体进程 - 虚拟机或云主机常见陷阱：网卡型号显示为
virtio_net，此时ethtool的 Speed 字段可能为空或无效，应以ip -s link show eth0中的bytes增长率为准
自动化采集时：CSV 和 JSON 输出格式差异影响解析稳定性
speedtest-cli --csv 输出是逗号分隔，但字段里可能含逗号（比如服务器名称 “Shanghai, China”），直接用 shell cut -d, -f5 会错位；而 --json 虽然结构清晰，但部分旧版本不支持。
- 安全做法是强制用
--csv-header加表头，再用awk -F, '$1 ~ /^"[0-9]/ {print $4","$5","$6}'提取 ping/download/upload -
iperf3 -c ... --json输出是标准 JSON，可用jq '.end.sum.bits_per_second / 1000000'提取 Mbps 值，比文本解析可靠得多 - 注意时区问题：
speedtest-cli --csv时间戳是本地时区，而日志轮转或 grafana 展示常用 UTC——时间对不齐会导致趋势图出现“断崖”
真实带宽瓶颈往往不在工具本身，而在你没意识到的环节：服务端是否被防火墙限速、中间交换机是否开启流控、甚至网线是不是超五类却标称六类。测之前，先用 ping -c 5 192.168.1.1 看局域网丢包，比直接跑 speedtest 有用得多。