家里装了多个摄像头，直播时老是卡顿，换了几台路由器也没解决。后来才发现，问题出在网桥模式下的UDP流量处理上。这类场景很常见，尤其是用网桥连接两个网络段时，音视频流、游戏数据、直播推流这些依赖UDP的应用，稍不注意就会丢包、延迟高。
为什么网桥对UDP特别敏感？
网桥工作在数据链路层，负责转发MAC帧。它不像路由器那样能深度分析IP层以上的协议，所以面对UDP这种无连接、不重传的协议时，一旦网络拥塞或帧缓冲不足，数据直接就被扔了。而音视频软件大多用UDP传实时流，丢一帧可能就是画面卡一下，连续丢包体验就崩了。
调整MTU减少分片
UDP包太大容易在网桥处被分片，一旦某个分片丢失，整个UDP数据报就作废。把MTU从默认的1500适当调小，比如设成1460，能降低分片概率。在Linux下可以这样设置：
ip link set dev br0 mtu 1460br0是你的网桥接口名，改完之后再跑一遍直播推流，会发现卡顿明显减少。
启用快速转发模式
很多网桥默认使用iptables做转发过滤，但这会把每个包送到内核网络栈处理，增加延迟。如果安全策略允许，可以开启bridge-nf-call关闭机制：
sysctl -w net.bridge.bridge-nf-call-iptables=0
sysctl -w net.bridge.bridge-nf-call-ip6tables=0这一招能让UDP流量绕过不必要的检查，转发速度提升不少，尤其适合局域网内的媒体传输。
合理配置缓冲队列
网桥端口的发送队列长度也影响UDP表现。默认队列太短，突发流量一来就溢出。可以通过tc命令增大队列：
tc qdisc replace dev eth1 root fq flow_limit 1000把eth1换成你网桥接入的实际物理口。fq队列对UDP流有较好的调度能力，能避免单一流霸占带宽。
避免广播风暴干扰
UDP常伴随广播或多播行为，比如设备发现协议。如果网桥没做限制，一个设备发广播，整个网络都在传，UDP有效数据就被挤占了。可以在网桥上启用端口隔离或限制未知组播泛洪：
bridge link set dev eth1 multicast_router 0
bridge link set dev eth1 flood off这样控制平面和数据平面分开，媒体流更稳定。
实际调试时，可以用tcpdump抓桥接口的UDP包，看有没有大量重传或分片标志。优化不是一步到位，而是根据具体流量特征微调。比如监控摄像头用H.265编码，码率波动大，那就得把缓冲再放宽些。每一步改动后观察几小时，效果才真实。