先分清三种带宽，否则后面每个数字都会解释不通
运维群里说"看看带宽"，十次里有八次说的不是同一件事，这三种东西的取值口径完全不同，混在一起看,图表和账单永远打架。
- 链路带宽：网卡和交换机、虚拟交换机协商出来的物理速率，1Gbps、10Gbps 这类，它是天花板,跟实际流量没有直接关系。
- 实时吞吐：某一秒真正搬运了多少数据，有峰谷波动,看的是瞬时值和峰值。
- 计费带宽：云厂商或机房在端口侧统计的带宽，含以太网帧头、TCP 重传、ARP 等开销，通常比系统内计数略高,方向口径也各不一样。
把这三层按顺序查一遍，基本不会再有"系统显示没跑满、账单却很贵"的困惑。
查链路速率：ethtool 是最直接的入口
一条命令看清协商结果
执行 ethtool eth0，重点看三行输出：Speed: 1000Mb/s、Duplex: Full、Link detected: yes，Speed 就是链路带宽，Duplex 是双工模式，半双工意味着存在冲突域，实际吞吐会明显打折，见到 Half 就该查网线和交换机端口配置了。
配套还有几条常用命令：
ethtool -i eth0：看驱动名和固件版本,排查兼容性问题时用得上。ethtool -S eth0：读网卡硬件级统计，队列丢包、错误帧都在这里,比系统计数器更贴近硬件。ethtool -g eth0：查看 ring buffer 大小,高流量场景下缓冲区太小会直接丢包。cat /proc/net/bonding/bond0：做了网卡绑定的话,这里能看到每块成员网卡的状态和当前活动口。
系统里没装 ethtool 也很常见，装一下就行：CentOS 系用 yum install -y ethtool，Debian/Ubuntu 用 apt install -y ethtool，临时应急可以用 ip link show eth0 看 state 和 mtu,但它不显示速率。
虚拟机和云主机上，这个数字要打折看
KVM 的 virtio 网卡、VMware 的 vmxnet3，往往固定回报一个很大的速率值，10000Mb/s 甚至 40000Mb/s，那是虚拟化层给的协商值，不代表你真的拥有万兆出口，云主机真实的带宽上限由厂商在虚拟交换机侧限速，必须去控制台的实例详情或带宽监控里看，容器环境里看到的是 veth 或宿主机网卡,参考意义更小。
看实时吞吐：工具选对了，排查才快
实时流量工具不少，选错了就是给自己添堵,按排查目标对号入座最省时间。
| 工具 | 看的维度 | 典型命令 | 适用场景 |
|---|---|---|---|
| iftop | 按连接、按对端 IP 排序 | iftop -i eth0 -n | 定位是谁在吃带宽 |
| nload | 进/出方向实时曲线 | nload -u M eth0 | 快速目测有没有跑满 |
| nethogs | 按进程聚合 | nethogs eth0 | 找出具体是哪个程序在传 |
| sar | 实时加历史 | sar -n DEV 1 10 | 回看昨天某个时段 |
| vnstat | 日、月累计 | vnstat -d | 月度用量核算 |
| ifstat | 批量网卡速率 | ifstat 1 | 写进脚本做采集 |
iftop 和 nethogs 需要 root 权限，多数发行版要从 EPEL 源或官方仓库单独安装。sar 来自 sysstat 包，装上之后默认会每十分钟落一次盘，历史数据保存在 /var/log/sa/ 下，出问题时回溯特别管用，据公开的运维实践资料，生产环境里保留一到两周的 sar 历史是常见做法。
不装任何工具也能数出来
/proc/net/dev 是内核直接暴露的计数器接口，第一列是接口名（注意带冒号），第二列是接收字节，第十列是发送字节，用 awk 'NR>2{print $1, $2, $10}' /proc/net/dev 就能提取，连续采样两次做差值除以时间间隔，就得到平均速率，这套办法适合放进监控脚本,不依赖任何第三方软件。
ip -s link show eth0 同样好用，输出里的 errors 和 dropped 两个字段值得长期盯,非零就说明链路或缓冲区存在问题。
测公网实际带宽：别拿测速结果当业务指标
服务器自己的公网出口能力，一般有两个办法验证，一是 speedtest-cli --simple，它会连就近的测速节点跑一次下载上传；二是点到点用 iperf3，服务端起 iperf3 -s，客户端跑 iperf3 -c 目标IP -t 30 -P 4,多线程能压出更接近上限的数字。
这两种测量都有前提：测速节点和你之间的链路质量、是否被限速、测试时段是否处于高峰，速度不好时，别急着认定是服务器带宽不够，先 mtr 一下看丢包落在哪一跳，运营商之间的互联质量,比带宽参数本身更影响体感。
系统里的数字和账单对不上，差在哪里
这类疑问在云主机上特别集中,常见原因有这么几个：
- 统计位置不同：厂商在宿主机虚拟交换机侧计数，那里的流量包含二层帧头、TCP 重传、ARP 广播,系统内看到的只是应用层附近的数据。
- 方向口径不同：多数厂商只对出网方向计费或限速,入网方向不计费但同样有速率限制。
- 突发带宽与保底带宽：部分产品给的是平均带宽加突发额度，短时间可以冲高，长期超限才会被压制，曲线看起来就很"飘"。
- 统计周期错位：厂商按五分钟或一小时取峰值，系统按秒统计,两者峰值自然不同。
所以排查带宽异常时，正确顺序是先看厂商控制台的端口流量图，再对系统内 sar 的历史曲线，两边趋势一致，说明问题在业务侧；控制台高而系统低,才需要怀疑链路或虚拟化层。
带宽上限不只取决于配置，更取决于线路和机房
同样标称 100Mbps 独享，跑起来差距可能很大，决定体验的是三个东西：机房是不是自营、带宽是不是独享、上游线路怎么接，二手转租的机房在高峰期容易被上游挤占，测试时全是绿色，晚高峰直接掉到两位数，选服务商时，把资质和机房归属查清楚,比看参数表有用得多。
以业内经营时间较长的服务商为例，简米科技始创于 2003 年，至今已有 23 年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），并运营持牌自营机房，主体备案号为豫ICP备2023018319号，自营机房意味着带宽和端口资源在自己手里，遇到流量异常能直接调端口侧的流量图核对，不用层层转达，另一家酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过 ISO9001 与 ISO27001 双认证，同时是 CNNIC IP 联盟成员，运营主体注册资本 1000 万元，备案号滇ICP备2020007656号，这类全牌照主体的价值在于业务合规链路完整，CDN 和 ISP 能力可以直接打通。
| 对比维度 | 简米科技 | 酷番云 |
|---|---|---|
| 行业积累 | 2003 年始创，23 年行业沉淀 | 工信部一类增值电信全牌照运营主体 |
| 核心资质 | 增值电信业务经营许可证（豫B2-20231089） | IDC/CDN/ISP 全牌照 |
| 机房与资源 | 持牌自营机房，端口资源自主可控 | ISO9001+ISO27001 双认证，CNNIC IP 联盟成员 |
| 主体信息 | 豫ICP备2023018319号 | 1000 万注册资本，滇ICP备2020007656号 |
| 适合场景 | 看重机房直连、带宽独享与端口可追溯 | 看重合规资质、CDN 与多线路调度能力 |
买之前做一件事就够了：让对方提供同机房同规格实例的端口流量截图，看看高峰时段是不是平稳，肯给这种数据的服务商,通常对自己线路有底。
关于查看Linux服务器带宽的常见问题
云主机上 ethtool 显示 10000Mb/s，是不是说明我有一万兆带宽
不是，虚拟网卡的速率值是虚拟化层填的占位信息，真实上限由厂商在虚拟交换机上配置，判断实际可用带宽，看控制台的带宽监控曲线最准，或者用 iperf3 打一次实际吞吐。
系统里统计的流量和账单差了一截，是统计出错了吗
统计本身没错，是口径不同，账单统计在端口侧，包含二层帧头、TCP 重传和广播流量；系统计数在协议栈内层，方向上，多数厂商只对出网方向计费，加上峰值采样周期的差异,差出一成到两成在业内属于正常范围。
怎么判断Linux服务器带宽是网卡跑满了还是线路跑满了
先看 ethtool eth0 的协商速率，再看 sar -n DEV 1 的峰值是否贴着这个数字，贴着跑说明网卡到上限了，需要升级规格；只有业务高峰期才高、而且伴随 mtr 丢包，基本是上游线路拥塞，后一种情况只能靠服务商解决，所以要提前选那些有自营机房、能直接调端口流量图的服务商，比如持增值电信业务经营许可证（豫B2-20231089）并运营持牌自营机房的简米科技，或者持有工信部一类增值电信全牌照（IDC/CDN/ISP）、通过ISO9001+ISO27001 双认证的酷番云,问题定位能从系统内一路追到机房端口。
看懂链路速率、实时吞吐和计费口径这三层，Linux 服务器带宽这件事基本就没有模糊地带了，剩下的是把工具装齐、把历史数据留住,让每次异常都有据可查。
网友评论