CN
EN
生产环境的服务器最怕什么？不是CPU跑满，不是内存告急——而是网络断了。
一块网卡故障、一根网线松动、一个交换机端口异常，都可能让整台服务器从互联网上“消失”。对于承载业务的生产环境来说，网络中断几分钟造成的损失，可能远超一台服务器本身的成本。
解决这个问题的标准方案是双网卡故障切换——用两块物理网卡组成一个逻辑接口，主网卡工作时备网卡待命，主网卡故障时备网卡在毫秒级内自动接管。本文将手把手教你用 Linux Bonding 实现这一方案，覆盖 Ubuntu（Netplan）和 RHEL 系（nmcli）两大主流配置方式。
双网卡故障切换的原理：Bonding 主备模式
Linux 内核自带的 bonding 驱动可以将多块物理网卡聚合成一个逻辑接口（通常命名为 `bond0`）。在多种工作模式中，`active-backup`（mode 1） 是专门为故障切换设计的模式：只有一块网卡处于活动状态，负责收发所有流量；其余网卡处于备用状态，持续监测主网卡的链路健康。主网卡故障时，备用网卡在毫秒级内接管，交换机通过 Gratuitous ARP 更新 MAC 地址表，流量自动切换到新路径。
关键参数：`miimon=100` 表示每100毫秒检测一次物理链路状态。这个值不能设置过大（超过300毫秒可能导致业务超时），也不能过小（容易产生误判）。另一个容易被忽略的参数是 `fail_over_mac=1`——它让备用网卡在接管时主动同步主网卡的 MAC 地址，避免交换机因 MAC 地址变化而丢弃数据包。
方式一：Ubuntu / Debian 使用 Netplan 配置
Ubuntu 20.04 及以上版本默认使用 Netplan 管理网络。配置前先确认网卡名称：执行 `ip link show` 查看物理接口，通常为 `enp0s3`、`enp0s8` 或 `eth0`、`eth1`。
第一步：备份现有配置
sudo cp /etc/netplan/*.yaml /etc/netplan/backup/第二步：编写 Netplan 配置
编辑 `/etc/netplan/01-netcfg.yaml`：
yaml
network:
version: 2
renderer: networkd
ethernets:
enp0s3:
dhcp4: false
enp0s8:
dhcp4: false
bonds:
bond0:
interfaces:
- enp0s3
- enp0s8
addresses:
- 192.168.1.100/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses:
- 8.8.8.8
- 8.8.4.4
parameters:
mode: active-backup
primary: enp0s3
mii-monitor-interval: 100
fail-over-mac: 1物理接口 `enp0s3` 和 `enp0s8` 中不配置 IP 地址，所有地址、路由和 DNS 全部由 `bond0` 接管。`primary: enp0s3` 指定主网卡，故障恢复后系统会优先切回这块卡。
第三步：应用配置并验证
sudo netplan apply
cat /proc/net/bonding/bond0输出中应显示 `Bonding Mode: fault-tolerance (active-backup)`，`Currently Active Slave` 为 `enp0s3`，两块网卡的 `MII Status` 均为 `up`。
第四步：模拟故障测试
拔掉 `enp0s3` 的网线（或在虚拟机中断开该接口），等待2到3秒后再次查看 `/proc/net/bonding/bond0`，应显示 `Currently Active Slave` 已切换为 `enp0s8`。同时持续执行 `ping 192.168.1.1`，正常情况下应该只有一两个包的延迟波动，不会完全中断。
方式二：RHEL / CentOS / Rocky Linux 使用 nmcli 配置
RHEL 8 及以上版本推荐使用 NetworkManager 的 `nmcli` 命令进行配置，比传统 ifcfg 文件更简洁、可管理性更强。
第一步：创建 Bond 主接口
nmcli connection add type bond \
con-name bond0 ifname bond0 \
bond.options "mode=active-backup,miimon=100,fail_over_mac=1,primary=eth0"这一条命令创建了名为 `bond0` 的 Bond 连接，指定了主备模式、100毫秒链路检测、MAC 同步策略，以及 `eth0` 为主网卡。
第二步：添加从属网卡
nmcli connection add type ethernet port-type bond \
con-name bond0-port1 ifname eth0 controller bond0
nmcli connection add type ethernet port-type bond \
con-name bond0-port2 ifname eth1 controller bond0RHEL 9 中使用 `port-type bond` 和 `controller bond0` 参数来建立从属关系；RHEL 8 及更早版本可以使用 `type bond-slave` 和 `master bond0`。
第三步：配置 IP 地址
nmcli connection modify bond0 \
ipv4.addresses "192.168.1.100/24" \
ipv4.gateway "192.168.1.1" \
ipv4.dns "8.8.8.8,114.114.114.114" \
ipv4.method manual如果使用 DHCP，则执行 `nmcli connection modify bond0 ipv4.method auto`。
第四步：启用连接
nmcli connection up bond0-port1
nmcli connection up bond0-port2
nmcli connection up bond0第五步：验证切换效果
cat /proc/net/bonding/bond0在另一终端持续 Ping 网关，然后执行 `nmcli device disconnect eth0` 模拟主网卡故障。观察 `Currently Active Slave` 是否切换为 `eth1`，Ping 是否保持连续（最多丢一两个包）。
配置完成后必须检查的四件事
第一，物理网卡上不能有残留 IP。 如果 `eth0` 和 `eth1` 上仍然有独立的 IP 地址配置，系统会出现多条默认路由，导致选路混乱。执行 `ip addr show eth0` 确认其没有分配 IP。
第二，路由表中只能有一条默认路由。 执行 `ip route show default`，输出中应只有一条 `default via ... dev bond0`。如果出现 `eth0` 或 `eth1` 作为出口的默认路由，说明从属网卡上仍有残留配置。
第三，在服务器上配置业务时绑定 bond0 而非物理网卡。 Nginx、数据库、应用服务的监听地址和出站连接都应使用 `bond0` 接口的 IP，而不是 `eth0` 或 `eth1` 的地址。这样故障切换对业务是完全透明的。
第四，交换机端口不需要特殊配置。 与 LACP（mode 4）不同，active-backup 模式不需要交换机端的任何配合配置。两块网卡可以连接同一台交换机的不同端口，也可以连接两台不同的交换机——后者能同时防范网卡故障和交换机故障。
双网卡故障切换的适用场景与底层保障
双网卡故障切换的价值在于消除单点故障。只要服务器主板上有两个网卡插槽，或者云服务商支持为实例绑定多块虚拟网卡，这套方案就适用。
但需要明确一点：bonding 解决的是服务器侧网卡和线路的冗余，解决不了上游网络本身的问题。如果机房的出口带宽被跑满、上游线路出现拥堵，bonding 无法提供额外的带宽或绕过上游故障。
因此，故障切换方案的有效性，最终取决于服务器本身的网络基础设施质量。一台接入优质线路的服务器，bonding 是“锦上添花”的可靠性加成；而一台线路本身就不稳定的服务器，bonding 只能解决网卡层面的问题，无法弥补上游网络的质量缺陷。
Jtti 的云服务器方案在这一点上提供了匹配的基础设施保障。香港及美国节点接入 CN2 GIA 精品线路，三网直连优化，晚高峰丢包率稳定在 0.1% 以下。全系标配独享带宽，不存在“邻居抢带宽”导致上游链路拥塞的问题。对于需要部署双网卡故障切换的高可用架构，一台线路稳定、资源独享的底层服务器，能让 bonding 的切换逻辑更加可靠——不会因为上游抖动而触发不必要的“假故障”切换。续费同价政策确保长期运行的成本可预期。
双网卡故障切换是服务器高可用的基础配置，配置本身并不复杂，但细节决定成败。 miimon 的间隔、fail_over_mac 的参数、从属网卡的 IP 清理——每一个细节都影响着切换是否真正“无感”。访问 Jtti 官网，查看香港 CN2 及美国 CN2 云服务器的完整配置与当前优惠，为你的高可用架构选一台底子扎实的服务器。
