家里的智能家居网络偶尔会出一种很难描述的问题：设备本身没有断电，App 也显示在线，但就是控制不了。或者打印机突然找不到了，AirPlay 投屏的时候设备列表空白，HomeKit 里某个配件显示"无响应"。
重启一下路由器，或者把手机 Wi-Fi 断开重连，有时候好了，有时候没用。
这类问题，背后很多时候是同一个东西在作怪：mDNS。
mDNS 是什么
mDNS，全称 Multicast DNS，苹果叫它 Bonjour。它解决的问题很基础：局域网里的设备怎么互相找到对方。
普通的 DNS 需要一台服务器来做地址解析。mDNS 不用服务器，设备直接在局域网里广播：“我是 xxx.local，我的 IP 是 192.168.x.x，谁要联系我？“同一个网络里的其他设备收到广播，就知道怎么找它了。
苹果的生态对 mDNS 依赖很深。HomeKit 设备的发现、AirPlay 投屏目标的搜索、AirDrop 的设备发现、网络打印机的自动识别——背后全是 mDNS 在工作。平时感觉不到它的存在，出了问题才意识到它有多重要。
最常见的问题：跨 VLAN 没有转发
家里的网络如果做了 VLAN 隔离——比如智能家居设备放一个 VLAN，电脑和手机放另一个 VLAN——mDNS 默认是跨不过去的。
原因很简单：mDNS 用的是组播（Multicast），组播流量默认不跨越网段边界。设备在自己的 VLAN 里广播"我在这里”，另一个 VLAN 的设备根本收不到这个广播，自然就找不到对方。
具体表现：手机和苹果电视在不同 VLAN，AirPlay 列表里搜不到设备；HomeKit 控制台里的设备显示"无响应”；网络打印机自动发现失败。
解决办法是在网关或者交换机上开启 mDNS 转发（有些设备叫 mDNS Repeater 或 mDNS Proxy）。它的作用是把一个 VLAN 里的 mDNS 广播，转发到另一个 VLAN，让跨网段的设备也能互相发现。
Ubiquiti 的设备在网关上有 mDNS 转发的选项，配置正确之后，跨 VLAN 的设备就可以互相发现了。但这个功能要手动开，默认不启用。
固件的问题
有一次家里智能家居突然集体失联，HomeKit 里大半设备显示"无响应"，但设备本身在各自的 App 里都能正常控制，说明网络连接没有问题，是发现机制出了问题。
排查了一圈，最后发现是交换机刚升级了一个新固件，新固件里的 mDNS 实现有 bug，导致部分组播流量被错误丢弃。
回滚固件，问题消失。
这种事遇到一次之后，我对"新固件"的态度变得谨慎了很多。智能家居网络的稳定性，有时候比新功能更重要。
转发 hang 住了
还有一类更难排查的问题：mDNS 转发服务在运行，配置也是对的，但设备就是找不到彼此。
这种情况通常是 mDNS 转发进程 hang 住了——软件还在跑，但实际上已经停止工作了。不会有任何报错，日志里也看不出异常，就是没有响应。
目前发现，重启交换机可以解决。重启之后 mDNS 转发进程重新初始化，一切恢复正常。
这不是一个优雅的解法，但目前就是这样。
一点感想
智能家居网络和普通家用网络最大的区别，不在于设备多不多，而在于这张网里运行着很多"服务发现"的机制，mDNS 只是其中之一。这些机制平时无声无息，一旦出问题，症状往往让人摸不着头脑——设备在线，App 没报错，但就是不工作。
遇到这类问题，与其反复重启设备，不如先想想：是不是网络层面的发现机制出了问题？大多数时候，答案就在这里。
My home network occasionally develops a problem that’s hard to describe: a device is powered on, the app shows it as online, but it simply won’t respond. Or the printer suddenly disappears. AirPlay shows an empty device list. Something in HomeKit displays “No Response.”
Rebooting the router helps sometimes. Toggling Wi-Fi on the phone helps sometimes. Sometimes nothing works.
More often than not, the same thing is behind all of this: mDNS.
What mDNS is
mDNS stands for Multicast DNS. Apple calls it Bonjour. It solves a basic problem: how do devices on a local network find each other?
Regular DNS needs a server to resolve addresses. mDNS doesn’t. Devices broadcast directly onto the local network: “I’m xxx.local, my IP is 192.168.x.x, anyone looking for me?” Other devices on the same network receive the broadcast and know how to reach it.
Apple’s ecosystem depends heavily on mDNS. HomeKit device discovery, AirPlay target search, AirDrop device detection, automatic network printer recognition — all of it runs on mDNS underneath. You never notice it when it’s working. You only understand how important it is when it breaks.
The most common problem: no cross-VLAN forwarding
If your home network uses VLAN segmentation — smart home devices on one VLAN, computers and phones on another — mDNS won’t cross between them by default.
The reason is simple: mDNS uses Multicast, and multicast traffic doesn’t cross network boundaries by default. A device broadcasts “I’m here” within its own VLAN, and devices on other VLANs never receive that broadcast, so they can’t find each other.
The symptoms: phone and Apple TV on different VLANs, AirPlay list is empty; HomeKit shows devices as unresponsive; network printers fail to auto-discover.
The fix is to enable mDNS forwarding on the gateway or switch — sometimes called mDNS Repeater or mDNS Proxy. It takes mDNS broadcasts from one VLAN and forwards them to another, so devices across different network segments can discover each other.
Ubiquiti’s gateway has an mDNS forwarding option. Once configured correctly, cross-VLAN discovery works. But it’s not enabled by default — you have to turn it on manually.
The firmware problem
Once, the smart home devices in my house went offline all at once. Most of HomeKit showed “No Response.” But every device could still be controlled individually through its own app, which meant the network connection was fine — something was wrong with the discovery layer.
After working through the possibilities, I found it: the switch had just been updated to a new firmware version, and that firmware had a bug in its mDNS implementation that caused some multicast traffic to be silently dropped.
Rolling back the firmware made the problem disappear.
After that experience, I became considerably more cautious about new firmware. For a smart home network, stability often matters more than new features.
When the forwarder hangs
There’s another failure mode that’s harder to diagnose: the mDNS forwarding service is running, the configuration is correct, but devices still can’t find each other.
This usually means the mDNS forwarding process has hung — the software is still technically running, but it has stopped doing anything. No errors, nothing visible in the logs. Just silence.
The fix, as far as I’ve found: reboot the switch. After the reboot, the mDNS forwarding process reinitializes and everything comes back.
Not an elegant solution. But that’s where things stand.
A broader observation
The biggest difference between a smart home network and an ordinary home network isn’t the number of devices. It’s that a smart home network runs many service discovery mechanisms underneath, and mDNS is just one of them. These mechanisms are invisible when they work. When they fail, the symptoms are bewildering — device shows online, app reports no error, nothing responds.
When that happens, rather than rebooting devices one by one, it’s worth asking first: is something wrong with the network’s discovery layer? Most of the time, that’s where the answer is.