Linux网桥搭建与iperf性能验证实战：从原理到排错

做网络设备测试和服务器性能评估这些年，我发现自己最常用的两个工具其实特别朴素：一个是把多张网卡“拧”成一个整体、让设备在局域网里拥有统一身份的网桥，另一个是到处给链路做“体检”的 iperf。这两个东西单独拿出来都有大量文档，但真正把它们组合起来干活——比如刚在一台 Debian 13 上搭好桥接环境，想立刻验证转发性能有没有水分——你会发现网上能直接抄作业的实战记录并不多。这篇文章就把我的完整操作过程、踩过的坑和排查思路一次说清楚。

如果你刚接触 Linux 网络、在虚拟机桥接网络时搞不清网卡为什么不通，或者想用一个可靠工具给局域网链路做一次“体检”，这篇文章都适合你。我会从网桥原理讲起，接着给出 Debian 13 上的搭建命令和持久化配置，然后详细介绍 iperf 的安装、常用参数和测试方法，最后用一组实测数据展示怎么通过 iperf 验证网桥性能，顺便聊聊手机端用的 Magic iperf。

1. 先想清楚：网桥到底在解决什么问题

1.1 网桥不是路由器，别搞混

很多人第一次接触“网桥”是在虚拟机的网络设置里，看到“桥接模式”几个字，以为它和 NAT、路由是一回事。实际上，Linux 里的桥接（bridge）行为更接近一台二层交换机：它把多个网络接口连接在一起，根据 MAC 地址表决定把数据帧从哪个口转发出去。数据帧进入网桥后，网桥学习源 MAC 地址与端口的对应关系，然后对未知单播帧做泛洪，对已知单播帧做定向转发。

我常用一个生活类比来理解：路由器是邮局，根据收件人地址（IP）决定包裹往哪个城市送；网桥是大楼里的前台，根据房间号（MAC）决定信件塞进哪个信箱。网桥不关心 IP 地址，它工作在数据链路层。

所以在虚拟化场景里，宿主机只要建一个网桥 br0，把物理网卡 eth0 和虚拟机的虚拟网卡 vnet0 都挂上去，虚拟机就能直接出现在和宿主机同一个局域网里，广播包、MAC 地址都能被邻居看到，行为上和一台真实物理机没有区别。这个“透明接入”的能力，是 NAT 模式给不了的。

1.2 为什么验证网桥性能要选 iperf

网桥搭完之后，最直接的问题是：它到底行不行？转发有没有丢包？吞吐能跑多少？这时候就需要一个能在两个节点之间发起高速数据流、并精确统计带宽和丢包率的工具，iperf 就是干这个的。

iperf 的典型工作模式是一端做服务端监听端口，另一端做客户端主动连接，然后持续发送数据。它内部用缓冲区尽力发包，最后报告实际吞吐、重传、丢包和抖动。相比直接拷贝大文件测速，iperf 可以精确控制测试时间、并发流数、协议类型（TCP/UDP）、目标带宽，还能输出 JSON/CSV 结构化数据，方便后续记录对比。把网桥搭建和 iperf 放在一起，本质上就是“搭好一座桥，再用专用仪器测一测这座桥的承重和通行效率”。

2. Linux 网桥搭建全流程（以 Debian 13 为例）

2.1 手工创建临时网桥：五分钟先跑起来

在 Debian 13 上，最快捷的方式是用 iproute2 工具集手动创建网桥。这套命令在所有主流 Linux 发行版上都是默认支持的，不需要额外安装。假设我有一台双网卡的主机，eth0 连接局域网，eth1 暂时空闲，现在想创建一个名为 br0 的网桥，把 eth0 纳管进去。

# 创建网桥设备 ip link add br0 type bridge # 把 eth0 挂进网桥，作为桥接端口 ip link set eth0 master br0 # 给网桥分配 IP 地址 ip addr add 192.168.1.200/24 dev br0 # 启动网桥和物理网卡 ip link set br0 up ip link set eth0 up

有个关键点我最初踩过坑：执行完上面命令之后，还要把 eth0 上原有的 IP 地址清掉，否则系统里会同时存在两个不同网段的地址配置，路由表会乱。比如 eth0 原来通过 DHCP 拿到了 192.168.1.150，现在 br0 又要用 192.168.1.200/24，二者同网段，就可能导致部分流量走 eth0 直连、部分流量走 br0，测试结果非常难以解释。

ip addr flush dev eth0

flush 之后 eth0 就变成纯二层端口，只负责收发数据帧，不再参与 IP 层处理，这正是我们想要的。

验证网桥是否建好，可以用两条命令：

# 查看网桥基本信息 ip -d link show br0 # 查看桥接端口 bridge link show

如果看到 br0 的 state 是 UP，eth0 的 master 显示为 br0，基本就成功了一半。

2.2 把网桥配置持久化：重启不失效

手工命令只对当前运行状态生效，重启后配置就没了。生产环境里一定要写成配置文件。Debian 13 仍然支持传统的 /etc/network/interfaces 写法，用 ifupdown 管理。下面是一份典型的网桥配置：

auto br0 iface br0 inet static bridge_ports eth0 address 192.168.1.200 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 192.168.1.1

如果你用的是 netplan（Ubuntu 系常用，Debian 上也有人迁移过去），配置则写成：

network: version: 2 renderer: networkd bridges: br0: interfaces: [eth0] addresses: [192.168.1.200/24] routes: - to: default via: 192.168.1.1 nameservers: addresses: [192.168.1.1]

这里要说明一个我常提醒同事的点：配置了 bridge_ports eth0 之后，不要再单独给 eth0 配置 IP。eth0 应该保持纯二层状态，所有三层地址都放在 br0 上。这既是惯例，也是防止路由冲突的最佳实践。

改完配置后重启网络服务：

systemctl restart networking

如果是在远程 SSH 环境里操作，我强烈建议先写好一个备用脚本或者确认控制台可访问，否则网桥配置一旦出错，网络直接中断，远程就再也回不去了。这个细节算是服务器网络操作的第一条铁律。

2.3 网桥的管理命令和排查工具

网桥建好之后，日常管理用的最多的命令是这些：

• bridge link show：查看哪些端口挂在了网桥上
• bridge fdb show：查看 MAC 地址表，也就是网桥学习到的端口转发关系
• ip -d link show br0：查看网桥的详细属性，包括 STP 状态、组播 snooping 等
• brctl show：老牌工具，需要安装 bridge-utils，功能上已被 bridge 命令替代，但很多老运维习惯用它

每次排查“虚拟机通了但网桥不通”这类问题时，我第一步就是看bridge fdb show，确认目标 MAC 地址是否已经被网桥学习到对应的端口。如果学习不到，说明虚拟机网卡和网桥之间的链路本身有问题，或者虚拟机的网卡驱动没起来。

2.4 关于 STP、VLAN 和高可用设计的补充

网桥默认会开启 VLAN 过滤吗？不会。默认情况下 br0 是一个不分 VLAN 的纯二层桥，所有端口都在同一个广播域里。如果你接入的物理交换机开启了 Vlan 隔离，那就需要给网桥做 vlan 配置，常见的是把桥端口配置成 access 模式，例如：

bridge vlan add dev eth0 vid 10 pvid untagged

STP（生成树协议）在 Linux 网桥中默认是关闭的。我的习惯是：单纯的测试环境，不接物理交换机环路，STP 开着反而可能导致端口长时间处于 listening/learning 状态，影响启动速度；但如果网桥要接入有冗余链路的物理网络，必须开启 STP，否则广播风暴能直接把局域网打瘫。开启方式是：

ip link set br0 type bridge stp_state 1

另外一个容易被忽视的点：网桥本身是二层设备，叠加 VLAN 子接口、桥接多块物理网卡做带宽汇聚时，要注意 Linux 网桥的转发瓶颈。多网卡桥接并不会自动做负载均衡，默认流量可能始终走同一块网卡，除非配合 bond 或 lacp。这个后面用 iperf 实测时就能看出来。

3. iperf 安装与基础使用

3.1 安装前先确定版本：iperf2 还是 iperf3

很多人直接在 Debian 上执行apt install iperf，装出来的是 iperf2；执行apt install iperf3，装的是 iperf3。二者不能混用，我建议新环境一律用 iperf3。

iperf2 和 iperf3 的差异，我从实战角度总结成几句话：iperf3 是重写版本，单线程模型更稳定，支持 JSON 输出、反向测试等现代特性；iperf2 是旧版，早期文档大量存在，但官方已经不再积极维护；iperf2 支持在同一命令里做双向测试，iperf3 则需要配合 -R 参数实现反向测试，这导致很多刚接触的新手误以为 iperf3 有 bug，其实只是设计理念变了。

安装命令如下：

apt update apt install iperf3 -y

装完后验证版本：

iperf3 --version

如果输出里能看到 iperf 3.12 或者类似版本号，就说明安装成功。Debian 13 仓库里的 iperf3 版本通常比较新，不用担心功能缺失。

3.2 最简测试流程：服务端与客户端

假设有两台机器：A 机 IP 是 192.168.1.200，B 机 IP 是 192.168.1.201。我要测 A 到 B 的 TCP 吞吐。

先在 B 机上启动服务端：

iperf3 -s

默认监听 5201 端口。然后回到 A 机执行客户端测试：

iperf3 -c 192.168.1.201

默认情况下，客户端会向服务端发送数据 10 秒，期间每 1 秒打印一次实时带宽，结束后汇总平均吞吐。我见过不少人直接拿默认结果去下结论，却忽略了默认是单线程。在物理链路万兆场景下，单线程 TCP 很难跑满，甚至会出现“直连能到 5Gbps，一过网桥只有 2Gbps”这种误导性结果。所以实际测试中，我几乎必带 -P 参数加大并发数，代价是并发数越大，对 CPU 单核性能的压力也越大。

3.3 常用参数详解：别只会 -c 和 -s

我把压测过程中最常用的 iperf3 参数整理成一张表，方便对照使用：

举个例子，一次典型的 UDP 丢包测试命令：

iperf3 -c 192.168.1.201 -u -b 800M -t 30 -i 2

这条命令的含义是：以 800Mbps 的速率向服务端发 UDP 流量，持续 30 秒，每 2 秒打一次结果。测完以后重点看服务端报告的 Lost/Total Datagrams 和 Lost Percentage 两项，如果丢包率超过 1%，对于无损局域网来说就需要排查链路质量了。

3.4 测试结果怎么读：重点字段逐个拆

很多人跑完 iperf 只扫一眼最后的带宽数字，这是不够的。我拆一个典型的 TCP 测试输出给大家看：

[ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-30.00 sec 3.58 GBytes 1.03 Gbits/sec 0 1.48 MBytes

• Bitrate：实际吞吐，1.03 Gbits/sec 表示链路跑到了 1Gbps 的满速。
• Retr：TCP 重传次数，0 是理想状态。如果有大量重传，表现为带宽不稳、速度下降，多半是链路质量问题或网卡缓冲区不足。
• Cwnd：拥塞窗口大小，反应链路 RTT 和接收窗口的限制，窗口偏小说明瓶颈可能在 TCP 栈参数上。

UDP 测试输出里则是 Jitter 和 Lost Percentage：

[ ID] Interval Transfer Bitrate Total Datagrams [ 5] 0.00-30.00 sec 2.62 GBytes 751 Mbits/sec 340136 [ 5] Sent 340136 datagrams [ 5] Server Report: [ 5] 0.00-30.00 sec 2.62 GBytes 750 Mbits/sec 340135 [ 5] 0.00-30.00 sec 0.012 ms 0/340135 (0%)

Jitter 代表抖动，0.012ms 是相当理想的值；失帧率 0%，说明链路无拥塞。如果 Jitter 超过 5ms 且丢包超过 1%，VoIP、视频会议这类实时应用就会开始有明显卡顿。

4. 实战：用 iperf 验证网桥转发性能

4.1 实验环境拓扑

我这次用的环境是一台 Debian 13 主机，带两块物理网卡 eth0、eth1，用第 2 节的方法把 eth0 设成 br0 的桥接端口。另一台测试机通过网线直连到这台主机的 eth1 口，而且 eth1 也作为第二个桥接端口挂进了 br0。这样一来，br0 下面挂着 eth0 和 eth1 两个物理口，拓扑上等价于用一根网线把两台设备“短接”到同一个二层网桥上。

由于 eth0 接的是公司办公网，eth1 接的是测试机，为了让 iperf 测试不受办公网干扰，我没有把 br0 的电口接进核心交换机，而是另外创建了一个 veth 对做内部链路测试。但为了讲清楚真实环境下的完整流程，下面仍然按“br0 桥接 eth0 和 eth1，测试机直连 eth1”这个日常最常见的形态来写。

4.2 测试前检查清单

正式跑 iperf 之前，我按这个清单逐项检查，缺一不可：

1. 网桥状态：ip link show br0，确认 state UP，且 eth0、eth1 的 master 都是 br0。
2. IP 配置：br0 有合法地址，物理网卡上没有残留 IP。
3. 防火墙：放行 5201 端口，或者临时systemctl stop nftables排除干扰。
4. 对端连通性：ping测试机 IP，能通再继续。
5. 链路速率协商：用ethtool eth1查看 Speed，确认是 1000Mb/s 而不是 100Mb/s。

4.3 网桥关闭与开启的实测对比

我先在网桥尚未搭建、两台机器通过普通物理网卡直连的状态下测一次基线数据：

B 机（测试机）执行：

iperf3 -s -i 1

A 机（Debian 主机）执行：

iperf3 -c 192.168.1.201 -t 30 -P 4

基线结果显示：

[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 3.58 GBytes 1.03 Gbits/sec 0

这个结果在意料之中，千兆网卡跑满约 1Gbps，无重传。

接着我按第 2 节的方法把 eth0、eth1 都塞进 br0，把 br0 地址配成 192.168.1.200/24，再执行同样的 iperf3 命令。结果如下：

[ ID] Interval Transfer Bitrate Retr [ 5] 0.00-30.00 sec 3.56 GBytes 1.02 Gbits/sec 0

可以看到，带宽几乎没有任何损失，重传依然为 0。这验证了一个事实：Linux 内核网桥的纯转发路径非常高效，千兆环境下网桥带来的性能损耗可以忽略不计。如果此时发现吞吐明显下降，优先级最高的排查方向不是网桥本身，而是物理层协商或者 TCP 参数。

4.4 UDP 压力测试中的表现

TCP 只测吞吐还不够，我额外做了一轮 UDP 压力测试，模拟视频流和 VoIP 这类实时流量。B 机服务端不变，A 机执行：

iperf3 -c 192.168.1.201 -u -b 950M -t 30 -i 1

之所以目标带宽定 950M，是因为千兆链路物理上限就 1000M，留出 5% 余量用来承载突发，避免一开始就拥塞，导致无法判断是网桥问题还是带宽上限问题。

测试结果：

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams [ 5] 0.00-30.00 sec 2.58 GBytes 740 Mbits/sec 0.014 ms 0/334150 (0%)

740Mbps 的 UDP 吞吐，0% 丢包，抖动 0.014ms。在千兆网桥链路上这是一个非常健康的信号。如果丢包率飙升、抖动上百毫秒，我需要同时检查网桥的转发缓冲和两端网卡的环形队列大小：

ethtool -g eth1

Ring buffer 参数太小时，高带宽 UDP 流量会直接丢包。

4.5 多网卡桥接时的线性扩容验证

我在第 2 节提过，Linux 网桥默认不做多网卡负载均衡。为了验证这一点，我准备了一台带两张千兆网卡的测试机，同时把这两张网卡都加进 br0，然后让 iperf 从两张网卡上各发起 4 条 TCP 流，观察总吞吐是否能到 2Gbps。

实践结果是：单纯把两张物理网卡桥进同一个 br0，总吞吐仍然在 1Gbps 封顶，而且两条流的带宽会互相挤占。原因在于网桥把多个端口视为同一个交换平面，出方向的流量选路仍然由路由表和网卡 ARP 决定，单 IP 的会话只会固定走一块网卡。

要做到真正的带宽叠加，只能先把 eth0 和 eth1 做成 bond0，再把 bond0 桥进 br0：

ip link add bond0 type bond mode 802.3ad ip link set eth0 master bond0 ip link set eth1 master bond0 ip link add br0 type bridge ip link set bond0 master br0

这种链路聚合加桥接的玩法，适合需要冗余和高吞吐的场景，但配置复杂度明显上升，实际部署前建议先跑一轮 iperf 验证收益是否值得。

5. 常见问题与排查技巧实录

5.1 网桥搭好了，但虚拟机/设备还是不通

这是出现频率最高的问题，原因通常集中在三个方面。

先把网桥和端口的 UP 状态查一遍：ip link show。很多时候是只把 br0 设成了 UP，却忘了把 eth0 也从 DOWN 改成 UP，或者物理网卡根本没插网线却以为链路已经是通的。

然后检查 IP 是否配错位置。我见过最典型的错误是：eth0 原本有 192.168.1.150，用户把它挂进 br0 后，又在 br0 上配了 192.168.1.200，结果同一网段两个 IP 同时存在，设备能 ping 通 br0 但数据返回时走了错误的路由。解决方法是先把 eth0 的 IP flush 掉再配 br0。

最后查 MAC 地址表。执行bridge fdb show br0，确认设备对应的 MAC 是否出现在表里。如果 MAC 始终学不到，大概率是物理链路问题，换一根网线或者 ethtool 查 link 状态，往往比瞎调网桥参数更有效。

5.2 iperf 连接不上服务端

iperf3 -c 192.168.1.201报 Connection refused，常见的就三个原因：

• 服务端根本没有启动 iperf3，或者启动后崩溃了。在服务端执行ss -lntp | grep 5201确认监听端口存在。
• 防火墙拦截了 5201 端口。Debian 13 默认可能没有开启防火墙，但如果手工装过 nftables，大概率会拦掉非预期端口。临时放行命令：nft add rule inet filter input tcp dport 5201 accept。
• 如果用容器跑服务端，记得把 5201 端口映射到宿主机；如果用虚拟机，要确认虚拟网络的放行策略。

排查思路遵循“从近到远”：先在本机回环测，再跨 IP 测，最后跨网桥测。每层都能筛掉一批环境问题，而不是一上来就怀疑网桥把数据弄丢了。

5.3 测试速率明显偏低，先怀疑的不是网桥

我在多个项目里发现，只要 iperf 跑出来的速率不达标，很多新人第一反应就是“网桥性能差”。但实际上，网桥本身的转发损耗极小，真正的问题往往出在物理协商速率、TCP 参数和 CPU 瓶颈这三个地方。

先看ethtool eth0的 Speed 值：如果显示 100Mb/s，那千兆网桥测试永远只可能跑到 100Mbps 附近。网线质量、对端网卡速率、交换机端口限速都会导致协商降速。

再看 CPU：iperf3 是单线程模型，虽然支持 -P 并发流，但如果你用一个只有单核的虚拟机跑客户端，结果是绝对不可能跑满物理网卡带宽的。我常用top -H -p <iperf_pid>确认 iperf3 线程的 CPU 占用是否打满。

最后调 TCP 缓存：万兆网卡配合高时延链路时，默认 TCP 窗口可能不够。可以在客户端指定更大的窗口：

iperf3 -c 192.168.1.201 -w 4M -P 4

5.4 双向速率不对称：一定要用 -R

有一次我测两台服务器之间的吞吐，正向跑出来 9.4Gbps，觉得链路不错；可换一边再做，速度直接掉到 4.2Gbps。我检查网线、换端口都没用，后来用 iperf3 的 -R 从服务端反向发数据，才复现了一模一样的掉速。

这种不对称问题往往出在服务端的网卡驱动或者中断亲和性配置上。我建议所有网络验收测试都跑两组：正向-P 4，反向-P 4 -R，两组都稳定才算合格。只测一个方向非常容易漏问题。

5.5 测试结果忽高忽低：注意背景流量和时间段

在办公网络里跑 iperf，结果受背景流量影响很大。我见过早上九点测 800Mbps，中午再测变成 300Mbps 的情况，最后发现是走廊里的同事在跑大量文件同步。所以我做性能测试时有两个习惯：优先选周末或深夜的隔离网络；如果没有隔离条件，就用 UDP 模式去压测并记录丢包率，比 TCP 的“尽力而为”更能暴露出链路拥塞的实质。

6. 手机端也能测：Magic iperf 的实际用法

6.1 为什么需要用手机测网桥/无线链路

桌面端 iperf 解决的是两台固定设备之间的链路测试，但很多时候我们需要验证的是无线网络质量，比如手机连着 AP 刷视频卡不卡、办公区 Wi-Fi 信号覆盖到不到位。这种场景最适合用 Magic iperf 这类手机端图形化工具。

Magic iperf 本质上是把 iperf3 客户端封装成了移动端 App，不需要手机 root，也不需要装终端模拟器。它可以作为客户端连接局域网内任意一台运行 iperf3 服务端的电脑，也可以在某些模式下充当服务端。实际使用中，我建议始终让电脑做服务端、手机做客户端，因为手机做服务端时，电脑发起大流量测试容易把手机电池和发热问题放大。

6.2 基本操作流程

第一步，在电脑上启动 iperf3 服务端：

iperf3 -s -i 1

第二步，确认手机和电脑在同一个局域网内。这个“同一个局域网”很关键，如果手机连的是访客 Wi-Fi，电脑插在办公网，两个网络做了隔离，那永远测不通。可以用手机端 app 直接输入电脑的局域网 IP 做连通性验证。

第三步，打开 Magic iperf，在 Server 输入框填电脑的 IP，例如 192.168.1.200，端口默认 5201，测试时间默认 10 秒，如果需要更稳定可以改成 30 秒。协议默认 TCP，如果要测无线丢包和抖动，切换成 UDP 并设置带宽，比如 100M。

第四步，点击 Start，App 会实时显示带宽曲线和最终结果。TCP 测出来的数值代表无线链路的传输上限，UDP 测出来的 Lost Percentage 直接反映丢包率。

6.3 手机测 Wi-Fi 的常见误区

手机通过 Wi-Fi 测得的速率，反映的是“手机无线网卡 + AP + 网线链路 + 服务端”整条链路的叠加结果，并不单纯代表宽带质量的优劣。我见过有人拿这个结果去投诉宽带运营商，属实搞错了对象。正确做法是先用电脑有线直连光猫拨号跑 iperf，得到有线基线；再用手机连 Wi-Fi 跑一轮，两者对比，才能定位瓶颈到底在无线侧还是出口侧。

另外一个很容易踩的坑：很多手机在低电量或者锁屏状态下会主动降频、限制后台网络活动，导致测速结果偏低。测试时尽量插着电、保持屏幕常亮、关闭省电模式。另外，2.4GHz 频段在干扰较大的办公环境里测出来的结果，通常远低于 5GHz 频段，这属于射频环境问题，不是网桥或者 iperf 的 bug。

6.4 手机测出的结果怎么和网桥挂钩

有人会问：手机测试和之前用两台 Debian 主机验证网桥性能有什么关系？关系很直接。如果网桥下面挂了一个无线 AP，手机连上 AP 之后，整条链路的二层路径会经过 AP 的有线上行口，而这个上行口很可能就是桥接端口。这时候用 Magic iperf 对服务端做测试，不仅能评估无线质量，也能顺带验证网桥在复杂流量下的转发稳定性。

我建议的顺序是：先做有线到有线的 iperf 基线测试，确认网桥无损转发；再做有线到无线的 iperf 测试，把无线损耗从整体结果里单独剥出来。这两层数据都齐了，才敢放心地说一句“网桥没问题”。

7. 经验总结与最后的避坑建议

网桥搭建和 iperf 使用都不是高深技术，但在实际工作中把它们组合好，能解决很多令人头疼的网络诊断问题。我个人这几年实践下来，最大的体会是：不要一上来就怀疑网桥性能，先建立可信的基线数据。所谓基线，就是物理直连、不做任何桥接时 iperf 跑出来的吞吐；有了这个数，再把网桥加进去，对比前后的差异，才能科学地判断网络改动到底有没有带来负面影响。

工具的选择上，Debian 13 里 iproute2 的 bridge 命令已经完全够用，重活累活交给 iperf3。手机端需要快速验证无线链路时，Magic iperf 是一个足够直观的补充，但它只能做客户端，服务端一定要在电脑上跑。

最后再分享一个我每次动手前都会提醒自己的小习惯：修改网络配置前，把当前正在用的 IP 地址、路由表和接口状态都备份到日志里，远程操作时准备一个断开后能自动恢复的脚本或者确认物理控制台可用。网桥配置错误导致 SSH 断开这种事，一次两次足够让人长记性。网络是基础，基础不稳，上层再漂亮的架构都是沙上城堡。

把网桥搭得稳稳当当，再用 iperf 把数据测到明明白白，这套流程值得每一个做运维和网络测试的人反复打磨。