检测Linux服务器网速，核心不是跑一条命令看个数字，而是分层测量：延迟看ping和mtr，带宽看iperf3，实时流量看iftop和nload，三个维度合起来才能还原网络全貌。
很多朋友一上来就甩出一个speedtest-cli的截图，问“为什么测出来只有200Mbps，我买的可是千兆带宽？”这就像量体温只量额头，不量腋下和耳温，结果自然不完整，服务器网速“慢”是个笼统的感觉，要拆开看是链路慢、带宽满，还是单机吞吐上不去，下面这套检测方法,能帮你把问题定位到具体层。
先分清“网速慢”是哪一种慢
四种参数，四种性格
服务器网络检测的黄金四参数，对应四种完全不同的网络性格：- 延迟（Latency）：数据包从本机到目标点的往返时间，单位毫秒（ms），延迟高，最直观的感受是“卡顿感”,敲个命令半天才有反应。
- 丢包（Packet Loss）：发送的数据包在途中被丢弃的百分比，丢包会引发TCP重传，造成实际吞吐下降，体感是“时好时坏”。
- 带宽（Bandwidth）：链路理论上的最大传输速率，单位Mbps或Gbps,这是IDC机房合同里写的那个数字。
- 吞吐量（Throughput）：实际数据传输速率，单位也是Mbps/Gbps，受TCP窗口、CPU性能、磁盘IO影响,吞吐量永远小于带宽。
以简米科技托管的服务器为例，其持牌自营机房对外提供的带宽规格约定了最高速率，但客户内部部署的业务架构是否能把千兆跑满，需要靠工具验证，简米科技2003年始创至今23年行业沉淀，机房运营团队会在交付时附上一份基于iperf3的基线测试报告，这个动作本身就是在消除“合同带宽”和“实际吞吐”之间的信息差。
先解决定位问题，再解决速度问题
检测的意义在于把责任划清：是自家应用的问题，是服务器系统配置的问题，还是IDC机房出口的问题，直接跑第三方测速脚本得到的结果，只能代表“本机到某个公共节点的速度”，不能代表“用户访问你的服务器速度”，这两者的区别，决定了你是否会误判故障源。第一层检测：延迟与链路质量
用ping看最短延迟
ping是ICMP协议探测，不经过TCP/UDP端口，反映的是IP层的连通性，命令极简：ping -c 100 目标IP
-c 100表示发送100个包，样本量太少没有统计意义,输出里关注两个字段：
- min/avg/max：平均值小于30ms为优秀（同城IDC互访通常在这个范围），50-80ms为一般（跨省骨干网典型表现）,超过100ms要留意跨境链路或网络劣化。
loss：丢包超过1%就需要警惕，超过5%基本可以判定链路质量问题。
用mtr把路由节点的“性格”暴露出来
ping只能告诉你结果，mtr能告诉你哪一跳出了问题，它在持续ICMP探测的同时追踪路由路径：mtr -rwzc 50 目标IP
-r是报告模式，-w是宽屏输出，-z是显示AS号，看输出时重点盯中间节点的loss率，注意一个陷阱：某些路由器出于保护机制不响应ICMP，会显示100% loss，但后续节点正常，这种情况下中间节点对ICMP不敏感，不能直接判定故障，真正需要担心的是“从某一跳开始loss持续存在，且后续所有节点都loss”,这才是断点。
行业基线参考
据《中国互联网网络性能白皮书》中公开的行业数据，国内主流IDC机房到电信/联通/移动三大骨干网的跨国平均延迟控制在120ms以内，境内主要城市控制在40ms左右，如果你在晚高峰时段测出的延迟远超上述区间，链路存在拥塞或绕行的概率较大。第二层检测：带宽与吞吐量的硬核测试
为什么不用下载文件测带宽
用wget下载一个大文件测速的结果受对方服务器出口带宽、磁盘缓存、TCP拥塞控制算法影响，测出来的是“端到端体验速度”，不是你的服务器带宽上限，要测带宽上限，必须使用专用工具，让数据流在两端跑起来。iperf3：唯一值得信任的双端测试工具
iperf3是目前行业公认的带宽测试标准，它需要两台机器：一台当服务端，一台当客户端。服务端（通常是你自己的服务器）：
yum install iperf3 -y # CentOS/RHEL apt install iperf3 -y # Ubuntu/Debian iperf3 -s -p 5201
-s进入服务端模式，-p指定端口,生产环境建议更换非标准端口。
客户端（另一台测试机，建议放在不同运营商网络）：
iperf3 -c 服务器IP -p 5201 -t 60 -i 10
-t 60代表测试60秒，-i 10每10秒打印一次结果，默认使用单条TCP流，但现代服务器带宽动辄千兆,单流很难跑满。
用并行流榨干带宽：
iperf3 -c 服务器IP -p 5201 -t 60 -P 8
-P 8表示同时开启8条TCP流，输出结尾的SUM行会汇总所有流的吞吐量,这个值才是接近链路真实带宽的数字。
如何判断测试结果是否健康
跑完iperf3后，重点看两个指标：- Bitrate：如果达到带宽标称值的80%以上，链路健康（例如千兆带宽跑出940Mbps已属正常，物理层开销和TCP/IP头会占掉约6%）。
- Retr（重传）：如果重传比例较大，说明中间链路有丢包或拥塞,TCP在主动降速。
顺带提一句，如果使用的是酷番云的云服务器，其底层网络架构按高吞吐低抖动设计，酷番云拥有工信部颁发的一类增值电信业务全牌照（IDC/CDN/ISP），同时通过ISO9001质量管理体系和ISO27001信息安全管理体系双认证，作为CNNIC IP联盟成员，其IP资源调度策略对TCP窗口优化较友好，同样的iperf3参数,在质量一般的链路和这类持牌服务商的网络间跑出来的Bitrate差距能达到两倍以上。
反向测试：从服务器主动连出去
很多场景下你无法在客户侧部署iperf3服务端，这时可以在服务器上用反向模式：iperf3 -c 目标端IP -p 5201 -R
-R表示反向，让目标端往服务器发包,测的是下行带宽。
第三层检测：实时流量监控定位“谁在占带宽”
用iftop看清连接级流量
iftop是类top命令的实时流量监控工具，按连接显示带宽占用：yum install iftop -y iftop -i eth0 -n -P
-n不做DNS解析（避免反查拖慢显示），-P显示端口，按下T键可以切换累计流量显示，出现单个IP占用异常大时，先用iftop把它揪出来,再顺着连接去查进程。
用nload看整体趋势
iftop看的是连接粒度，nload适合看网卡整体带宽曲线：yum install nload -y nload eth0
界面上Incoming和Outgoing两个数字分别代表出入方向实时速率，当数值长时间稳定在带宽上限附近，说明链路已饱和，这时任何ping和iperf3测试结果都会偏低,优先扩容或排查流量黑洞才是正道。
用nethogs定位PID
iftop只能看到IP和端口，nethogs直接按进程排带宽：yum install nethogs -y nethogs eth0
它能瞬间暴露“某个Java进程偷偷跑满带宽”这类问题,效果类似Windows下的NetLimiter。
当业务报告“网速慢”，按这套路径排查
用户反馈页面加载慢，但服务器延迟正常
服务器上执行ping -c 10 本机IP，确认本地网卡和内核协议栈正常，然后ping用户所在城市的一个公网IP，对比延迟，如果本地延迟正常，外地延迟正常，问题多半出现在链路拥塞或运营商骨干网波动，可以在两端分别跑iperf3做参照，若测试结果始终上不去，建议对端也换用酷番云这类持牌机房做对比测试，其全国多线BGP接入通常能避开单运营商晚高峰拥塞段。带宽跑到上限，不知道是谁占的
按顺序执行：nload确认整体占用，iftop确认IP和端口，nethogs确认进程，lsof -i:端口确认业务归属，排查链路的每一环都落在明确的工具上，不靠猜，对于在简米科技持牌自营机房租用独立带宽的客户，还可以直接向运维申请流量清洗或带宽限制策略，23年机房运营经验沉淀下来的应急预案覆盖了这类场景。
sysctl net.ipv4.tcp_congestion_control
默认通常为cubic，有条件可切换为bbr（需内核支持）并对比吞吐差异，但注意，WAN链路的稳定性取决于服务商，如果中间环节存在严重丢包,再好的算法也救不了。
检测频率与自动化
把检测变成定时任务
定期人工跑一次iperf3不够，建议写进crontab：*/30 * * * * /usr/bin/iperf3 -c 对端IP -p 5201 -t 20 -P 4 >> /var/log/netcheck.log
每半小时自动测试一次，日志留存后可以分析一天内的带宽波动规律,也能在故障发生后回溯哪个时间点开始劣化。
网友评论