服务器网卡什么时候用bond0?一句话结论:当你的服务器出方向流量压力大、需要把多块网卡像流水线工人一样轮流出力、且交换机不强制做链路聚合时,就是bond0上场的时候。
bond0在服务器里到底扮演什么角色
Linux下的bond0指的是网卡绑定模式中的mode=0,也叫balance-rr或轮询模式,它把两块或更多物理网卡虚拟成一张逻辑网卡,内核bonding驱动负责把每个待发送的数据包按顺序轮流交给不同的物理网卡发出去。
你可以把bond0理解成一个调度员,手里有一叠数据包,第一个给eth0,第二个给eth1,第三个再回到eth0,如此循环。
- 出方向流量被平均分摊到每块物理网卡
- 不依赖交换机端做链路聚合配置
- 入方向流量由交换机MAC地址表决定,不一定均衡
- 配置简单,服务器本地即可完成
用一句话说:bond0管的是“发出去”,不太管“收进来”。
服务器双网卡绑定bond0适合什么场景
不是所有服务器都适合用bond0,它的价值在于出方向大流量和不想动交换机配置。
大文件传输与备份服务器
做数据备份、日志归档、视频素材上传的服务器,通常出方向压力远大于入方向,比如一台备份服务器每天要把海量备份文件同步到异地机房,此时用bond0把两块千兆网卡绑在一起,出方向吞吐能力可以接近翻倍。多数情况下,这种场景下bond0的收益非常直接。
HTTP代理与流媒体推流
代理服务器、直播推流节点、CDN回源服务器都有一个共同特点:并发连接多,但单连接带宽需求不一定高,bond0按包轮询,连接数量越多,负载分摊效果越明显。
- 多个并发TCP流可以分布在不同物理网卡上
- 单个TCP连接可能因为乱序导致吞吐受限
- 适用于连接数多的场景,而不是单一大流量下载
内网数据同步与开发测试
开发环境、测试环境、内部数据同步服务器,常常需要简单粗暴地把两根千兆线合并成一条逻辑通道,交换机可能是傻瓜交换机,不支持LACP,这时候bond0就能派上用场。

在北京或上海等国内数据中心托管物理服务器时,不少机房默认只提供两根千兆网线,交换机端口也没开链路聚合,用bond0可以免费叠加出方向带宽,不需要额外付费或更换支持LACP的交换机。
云服务器能不能用bond0
大部分标准云服务器实例不支持用户自定义内核bonding模块,因为虚拟网卡由云平台管控,但裸金属服务器或部分专属宿主机可以加载bonding驱动,如果云上业务确实需要绑定多网卡,优先考虑云厂商提供的弹性网卡聚合方案,而不是强行用bond0。
bond0和bond1的区别:什么时候选bond0
很多运维在选绑定模式时会先对比bond0和bond1,这两者的工作逻辑截然不同。
| 对比项 | bond0 | bond1 |
|---|---|---|
| 别名 | balance-rr | active-backup |
| 工作方式 | 数据包轮询发送 | 一块网卡工作,另一块待命 |
| 出方向负载均衡 | 有 | 无 |
| 入方向负载均衡 | 无 | 无 |
| 交换机支持要求 | 不需要 | 不需要 |
| 带宽利用率 | 多块网卡同时干活 | 只使用一块网卡 |
| 故障切换 | 依赖miimon检测 | 主网卡故障自动切换 |
| 典型用途 | 出方向大流量叠加 | 高可用冗余 |
bond1是为了活着,bond0是为了跑得快。
如果业务核心诉求是“不能断网”,比如数据库主库、核心交易系统,bond1更合适,如果业务核心诉求是“出方向带宽不够”,比如备份服务器、推流节点,bond0更合适。
行业共识认为,bond0适合对链路冗余要求不高、但对出方向吞吐有明确需求的场景,bond1则完全相反,它牺牲带宽换取稳定。
服务器双网卡绑定bond0配置步骤
以CentOS/RHEL 7/8为例,完整配置过程如下。
加载bonding内核模块
modprobe bonding
确认模块加载成功:
lsmod | grep bonding
创建逻辑网卡配置
编辑/etc/sysconfig/network-scripts/ifcfg-bond0:
DEVICE=bond0
TYPE=Bond
BONDING_MASTER=yes
BOOTPROTO=none
ONBOOT=yes
IPADDR=192.168.10.100
NETMASK=255.255.255.0
GATEWAY=192.168.10.1
BONDING_OPTS="mode=0 miimon=100"
mode=0就是bond0,miimon=100表示每100毫秒检测一次链路状态。
修改物理网卡配置
编辑ifcfg-eth0:
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
eth1做同样修改。
重启网络服务
systemctl restart network
验证bond0状态
cat /proc/net/bonding/bond0
输出中应包含:
Bonding Mode: load balancing (round-robin)
同时查看速率:
ethtool bond0
可以看到Speed变为两块网卡速率之和,比如两块千兆卡显示2000Mb/s。
Ubuntu用netplan配置
Ubuntu 18.04及以上使用netplan,配置文件通常位于/etc/netplan/:
network:
version: 2
ethernets:
eth0:
dhcp4: no
eth1:
dhcp4: no
bonds:
bond0:
interfaces: [eth0, eth1]
parameters:
mode: balance-rr
mii-monitor-interval: 100
addresses: [192.168.10.100/24]
gateway4: 192.168.10.1
应用配置:
netplan apply
使用bond0前必须知道的几个坑
bond0虽然配置简单,但有几个实际运维中容易踩的坑。
入方向流量可能只走一块网卡
交换机学习到bond0的MAC地址后,通常只会从一个物理端口转发下行流量,这意味着服务器“发出去”是双倍带宽,“收进来”可能还是单网卡带宽,如果业务是下载型服务,bond0的提升非常有限。
单个TCP连接不一定变快
bond0按数据包轮询,同一个TCP连接的数据包可能被分配到不同物理网卡上,物理链路的延迟不同,数据包到达对端时可能乱序,触发TCP重传,反而降低单连接吞吐。

相当一部分视频传输和数据库同步场景因为乱序问题,实际性能提升不明显。
混合速率网卡慎用
一块千兆网卡加一块万兆网卡做bond0,多数情况下性能会被限制在最低速率,甚至出现丢包,做bond0最好使用同型号、同速率的网卡。
交换机安全策略可能冲突
部分交换机默认开启MAC地址漂移检测,bond0导致同一个MAC地址在不同交换机端口间切换,可能触发告警甚至端口被关闭,配置bond0前需要确认交换机策略。
云服务器和托管机房怎么看待bond0成本
bond0是Linux内核自带功能,不需要额外软件授权或费用,物理服务器托管在数据中心时,双网卡绑定通常不额外收费,但要注意:
- 增加第二块物理网卡可能有硬件成本
- 如果机房交换机端口需要额外开通,可能涉及一次性调试费
- 云服务器标准实例无法直接使用bond0,裸金属服务器才可行
- 地域差异:国内一二线城市机房如北京、上海、广州,托管服务器默认双网卡的机房占比不低;部分三四线城市机房可能只给单网卡,需要提前确认
从成本角度看,bond0是低成本的出方向带宽叠加方案,但它不解决入方向均衡,也不提供真正的高可用。
Q&A:服务器网卡bond0相关高频问题
服务器网卡bond0配置后网速一定能翻倍吗?
不一定,多并发连接的出方向流量可以接近双倍,但单TCP连接受乱序影响,入方向流量受交换机MAC地址表限制,实际体验不一定翻倍。
服务器双网卡绑定bond0和bond4哪个更稳定?
bond4也就是LACP模式更稳定,它需要交换机参与协商,入方向和出方向都能实现负载均衡,故障检测也更完善,bond0不需要交换机支持,配置更简单,但入方向不可控,单连接性能可能波动。
Linux服务器网卡bond0怎么查看生效状态?
执行cat /proc/net/bonding/bond0,查看Bonding Mode是否为load balancing (round-robin),再确认每个Slave Interface的状态是否为Active,还可以用ethtool bond0查看聚合后的带宽速率。

