mDNS (multicast DNS) is how most smart home devices announce themselves on a local network without needing a central server, broadcasting a message that says “I’m here, and this is what I am” to anything listening nearby. Your app or hub relies on that broadcast to discover the device in the first place. When a router blocks, filters, or fails to forward that multicast traffic, which happens often between different bands, different network segments, or a device and its controller on different Wi-Fi networks, the device is fully online and reachable, but nothing ever tells your app it exists. Confirming whether multicast traffic is actually reaching both sides is the direct way to check this rather than assume.
What mDNS is actually doing when it “just works”
Most of the time, device discovery is invisible. You open an app, it scans, and the device shows up, because mDNS handled the announcement automatically in the background. The device sends a multicast packet, typically addressed to a special multicast group rather than any single recipient, announcing its own hostname (often something ending in .local) and what services it offers. Anything on the same network segment listening for that kind of traffic picks it up and can then resolve the device’s name to an address without needing a central directory to ask.
This is deliberately a local-network mechanism. mDNS traffic is link-local by design, meaning it’s built to stay within one network segment and is not automatically forwarded across separate subnets or VLANs, the same way a shout doesn’t carry between rooms unless something specifically relays it.
Why “same network, same room” doesn’t guarantee it works
This is what makes the symptom so frustrating: the device and the phone can both show as connected to the exact same Wi-Fi name, in the same room, with full internet access on both, and discovery can still fail. That happens because being on the same Wi-Fi name doesn’t always mean being on the same network segment underneath it. Some routers and mesh systems put 2.4 GHz and 5 GHz traffic, or a main network and a guest network, or devices on different access points, onto separate segments even when they share one visible network name, and multicast traffic doesn’t automatically cross that boundary. It also happens on networks that are genuinely one flat segment, if the router itself filters or drops multicast traffic as part of its own settings, sometimes bundled into the same setting as AP isolation, sometimes separate.
The practical test: if a device you can reach by typing its IP address directly still won’t show up when your app scans for it, that’s a strong signal the device itself is fine and reachable, and the discovery broadcast specifically isn’t making it across.
How this differs from AP isolation
AP isolation and blocked mDNS produce a nearly identical symptom (device connected, app can’t find it), but they’re different mechanisms. AP isolation blocks direct traffic between two devices entirely, in both directions, for any kind of traffic. Blocked mDNS specifically stops the automatic announcement broadcast from reaching listeners, while direct traffic to a known address might still work fine. That distinction matters for the fix: disabling AP isolation restores all direct device-to-device traffic, while fixing mDNS specifically means making sure multicast traffic is allowed to reach the segment your controlling app or hub is on. It’s worth checking both independently rather than assuming fixing one fixes the other.
Where this shows up most often
The most common trigger isn’t a single flat network at all, it’s some kind of network split: a VLAN set up for IoT devices, a guest network the device ended up on, a mesh system that segments 2.4 GHz and 5 GHz differently than expected, or a router that treats wired and wireless clients as separate segments. If you’ve made any of those changes recently and discovery broke right after, that timing is a strong clue.
It also shows up on router firmware that ships with multicast filtering on by default as a general traffic-reduction measure, unrelated to any deliberate network segmentation you set up yourself, which is why checking your router’s actual settings matters even if you haven’t knowingly changed your network structure.
What actually helps
Check whether your router has a specific multicast or mDNS forwarding setting. Some routers, especially ones that support VLANs or guest networks, expose an option often labeled something like “multicast forwarding,” “mDNS repeater,” or “Bonjour forwarding” (Bonjour being Apple’s name for its mDNS implementation), though naming and location vary by manufacturer and firmware, so check your specific router’s documentation rather than assuming a fixed menu path.
Confirm both the device and the controlling app or hub are genuinely on the same segment, not just the same visible network name, if your setup includes a mesh system, multiple access points, or any kind of network segmentation.
If you’re running a genuinely separate IoT network by design (a VLAN rather than a flat guest network), a purpose-built mDNS reflector or repeater, which forwards multicast announcements between segments without merging the networks entirely, is the standard fix rather than flattening the segmentation you set up for a reason.
What this doesn’t explain
Blocked mDNS explains a device that’s reachable but not discoverable. It doesn’t explain a device that’s genuinely offline, which is a different diagnosis covered in the device, radio, router or cloud test, and it doesn’t explain a device that keeps losing its address entirely, which points toward the router running out of addresses to hand out instead. If you’ve ruled out AP isolation and confirmed the device responds when reached directly, mDNS is the strongest remaining explanation for a “same network, not found” symptom.
FAQ
Is mDNS the same as Bonjour?
Bonjour is Apple’s name for its own implementation of mDNS and related service-discovery protocols. Functionally, they refer to the same underlying mechanism, which is why some routers label the relevant setting “Bonjour forwarding” instead of “mDNS.”
Can I fix this by restarting my router?
A restart won’t fix a settings-level block or a genuine network segmentation issue. It might temporarily resolve it if the problem was a stuck cache or a transient state, but if the underlying setting or network structure is unchanged, the symptom will return.
Does this only affect smart home devices?
No. Any local-network discovery that relies on mDNS is affected, which includes some printers, media casting devices, and file-sharing tools, not just smart home devices specifically. If more than one category of device on your network has started having “can’t find it” problems at once, that’s a clue pointing toward this rather than something specific to one device.
Why does the device work fine through the cloud but not locally?
Cloud-based control doesn’t depend on local discovery at all, it routes through the manufacturer’s servers instead. That’s why a device can respond perfectly to app commands sent over the internet while still failing any feature that specifically requires local discovery or local control.
Will a mesh system make this more likely?
It can, particularly if the mesh system segments bands or access points in ways that aren’t obvious from the app’s network name. Some mesh systems handle this transparently and others don’t, so it’s worth checking your specific system’s documentation for how it treats multicast traffic across its nodes.
Sources referenced in this article
- Neat, Checking if mDNS is enabled on your network.
https://support.neat.no/article/checking-if-mdns-is-enabled-on-your-network/(accessed 2026-07-21). Source of the general mDNS announcement and discovery mechanism. - TP-Link, Troubleshooting guide for mDNS Repeater cannot work on the Omada Gateway.
https://www.tp-link.com/us/support/faq/4294/(accessed 2026-07-21). Source describing mDNS as link-local by design and the role of a repeater/reflector across segments.
Review interval: 12 months (router and mesh-firmware handling of multicast traffic can change).