家里装了几个网络摄像头，都接在不同网段的交换机上，结果主控室的NVR就是收不到某台摄像机的发现包——反复检查IP、子网掩码、供电都没问题，最后发现是中间串了个老式网桥，它把广播帧给‘拦’住了。
网桥不是路由器，但它真会筛广播帧
很多人以为网桥就是个“透明中继”，所有包照单全收、原样转发。其实不对。传统二层网桥（比如早年用的透明网桥或某些工业级无线网桥）默认会学习MAC地址表，对单播帧按表转发；对未知单播和广播帧，则采取“泛洪”策略——也就是往除接收端口外的所有端口都发一份。
但注意：这个“泛洪”只发生在同一广播域内。如果网桥启用了VLAN划分、端口隔离，或者本身是带路由功能的“三层网桥”（有些厂商叫法混乱），那它就可能把广播帧拦在端口外。特别是当它被当成“隔离设备”来用时，工程师常手动关闭广播泛洪。
一个真实小场景帮你判断
你用手机连Wi-Fi，打开某款局域网扫描APP（比如Fing），它靠ARP广播找设备。如果扫描结果里始终看不到隔壁办公室那几台摄像头，但直连同一交换机就能看到——那很可能是中间的网桥没转发广播帧。
再验证一下：登录网桥后台（通常是192.168.1.1这类地址），看有没有类似 Broadcast Flooding、ARP Broadcast Forwarding 或 Unknown Unicast/Multicast/Broadcast 的开关项。不少国产网桥默认关掉了广播转发，得手动打钩。
常见配置位置参考（以某品牌无线网桥为例）
Network Settings > Bridge Mode > Advanced Options
☑ Enable Broadcast Forwarding
☑ Forward ARP Requests
☐ Isolate LAN Ports (if checked, blocks broadcast between ports)勾上前两项，保存重启，再扫一次，大概率就能看见“失踪”的设备了。
顺带一提：如果是纯硬件网桥（没管理界面那种），基本默认转发广播；但现在很多所谓“网桥”其实是Linux软路由盒子刷的OpenWrt固件，背后跑的是ebtables或bridge-utils，广播行为完全可配——不能光看名字，得看底子。
下次监控画面突然断连、设备搜不到、ONVIF发现失败，别急着换线换电源，先查查那个不起眼的网桥，是不是悄悄把广播帧给“静音”了。