桥接网络是把物理网卡和虚拟网卡虚拟成同一个交换机层面的技术，配置好之后虚拟机可以直接从局域网的DHCP服务器获取IP，和宿主机处于同一网段，局域网内其他设备也能直接访问虚拟机。但在Ubuntu上配置br0时，不少人遇到过这样的情况：配置文件改完一重启，SSH直接断连，物理机网络彻底失联；或者桥接看似配置成功了，虚拟机却始终拿不到IP地址。这篇文章就来系统地讲讲br0配置的修复方法，覆盖Netplan和新旧两代配置体系下的常见坑。
一、先搞清楚Ubuntu当前用的是哪套网络配置体系
修复之前必须先判断系统用的配置工具，否则改了文件也不生效。Ubuntu的网络配置体系经历了几次大的变动：16.04及更早版本主要依赖/etc/network/interfaces；17.10之后逐步转向Netplan，配置文件位于/etc/netplan/目录下；而Server版从22.04开始又默认引入了systemd-networkd直接管理或通过Netplan渲染。判断方法很简单，执行下面的命令：
# 查看netplan目录下是否有配置文件 ls /etc/netplan/ # 查看当前网络由谁管理 networkctl status sudo systemctl status NetworkManager
如果/etc/netplan/下存在.yaml文件，说明系统走的是Netplan。如果目录为空，而/etc/network/interfaces里有内容，则是老式的ifupdown体系。混用两套体系是新手最常踩的坑之一：有人在Netplan环境下改interfaces文件，改完发现毫无作用，还以为是自己写错了。另外要注意，Desktop版默认由NetworkManager接管网卡，如果Netplan文件中renderer写的是networkd，而系统实际跑的是NetworkManager，就会出现配置看起来正确但网卡不受控制的怪现象。修复的第一步，就是把配置归属理清楚，确定唯一生效的那套配置，把另一套里的重复配置清理掉。
二、Netplan下br0的正确配置写法
假设物理网卡是ens33，我们要把它桥接到br0上。一个常见且致命的错误写法是：在ens33上配置了DHCP或静态IP，同时又把它加进bridges的interfaces列表。这样 ens33 自身还持有IP，桥接就会行为异常。正确的思路是：物理网卡不配置任何IP信息，只做桥接成员，所有网络参数全部配置在br0上。
network:
version: 2
renderer: networkd
ethernets:
ens33:
dhcp4: no
dhcp6: no
bridges:
br0:
interfaces: [ens33]
dhcp4: yes
parameters:
stp: false
forward-delay: 0
静态IP的写法如下，注意网段、网关和DNS都要写在br0这一层：
network:
version: 2
renderer: networkd
ethernets:
ens33:
dhcp4: no
bridges:
br0:
interfaces: [ens33]
addresses: [192.168.1.100/24]
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [223.5.5.5, 114.114.114.114]
parameters:
stp: false
写完配置先不要急着apply。这里有一个救命的技巧：netplan try命令会在应用配置后给你120秒的确认时间，如果新配置导致网络中断，你无法按下回车确认，它会自动回滚到旧配置。这在远程SSH操作时尤其重要，能避免把自己锁在系统外面。确认无误后再执行：
sudo netplan try # 确认网络正常后回车保存，或者直接应用 sudo netplan apply
还有一个隐蔽的问题值得注意：Netplan要求YAML文件整体缩进必须严格一致，混用空格和Tab会直接报错。如果apply时提示解析失败，用cat -A 文件名检查一下是否混入了Tab字符（Tab会显示为^I）。另外，较新版本的Netplan把gateway4字段废弃了，改用上面的routes写法，如果你从旧教程里抄来的配置报错，大概率就是这个原因。
三、老版本ifupdown下的br0配置修复
如果系统还在使用/etc/network/interfaces，配置逻辑是一样的：物理网卡设为manual模式不配IP，br0上承载网络参数。参考配置：
auto lo
iface lo inet loopback
auto ens33
iface ens33 inet manual
auto br0
iface br0 inet static
address 192.168.1.100
netmask 255.255.255.0
gateway 192.168.1.1
dns-nameservers 223.5.5.5
bridge_ports ens33
bridge_stp off
bridge_fd 0
改完执行sudo systemctl restart networking生效。如果重启后桥接没起来，常见原因有几个：一是bridge_ports写错了网卡名，Ubuntu对网卡命名做过调整，老的eth0可能已经变成ens33或enp0s3，用ip link确认实际名称；二是安装了ifenslave相关包但依赖缺失，桥接需要的bridge-utils没有安装，可以补装一下；三是同时存在NetworkManager在抢网卡管理权，这时可以在/etc/NetworkManager/NetworkManager.conf中加入unmanaged-devices配置，把对应物理网卡排除出它的管理范围。
四、桥接不通时的系统性排查步骤
配置生效不等于桥接真的能通。第一步，确认桥接建立成功：
# 查看br0是否存在，以及物理网卡是否挂在桥下 ip addr show br0 bridge link show # 正常情况下会看到ens33 master br0的输出
第二步，如果br0本身能ping通网关，但虚拟机拿不到IP，重点检查这几个方向：宿主机上是否开启了防火墙规则拦截了桥接流量，可以临时执行sudo iptables -F验证（注意生产环境慎用）；内核的br_netfilter模块是否把桥接流量送进了iptables，如果送进去了而链上默认策略是DROP，桥接流量就会被无声丢弃，可以调整net.bridge.bridge-nf-call-iptables参数为0测试；虚拟化层面，KVM用户需要检查虚拟机的XML定义中是否绑定到了br0，用virsh domiflist 虚拟机名确认接口绑定情况。
第三步，如果改配置改到网络彻底失联，本机登录后可以用最原始的方式临时救急：
# 临时给物理网卡恢复IP，先把机器救回来 sudo ip addr add 192.168.1.100/24 dev ens33 sudo ip link set ens33 up sudo ip route add default via 192.168.1.1
这些命令重启后会失效，但足够让你重新连上SSH去修复配置文件。修复完成后，建议把一份验证可用的配置备份到其他目录，下次出问题直接覆盖回来再apply，比从头排查快得多。桥接网络的问题看似五花八门，但归纳起来无非三点：配置体系归属混乱、参数写错层级、底层过滤拦截流量。沿着这三条线逐层排查，绝大多数br0问题都能在十分钟内定位解决。
Ubuntu桥接网络br0配置Netplan修改时间：2026-09-10 00:00:43