Hue Bridge Cannot Be Discovered by the App: A Clean Diagnostic

You open the Hue app, tap to add a new bridge or reconnect to an existing one, and you wait. The app spins, then tells you it cannot find a bridge. The bridge LEDs all look normal. Your phone is on the same Wi-Fi. Other apps on your phone work fine. This pattern frustrates new users and frustrates experienced users even more because the troubleshooting flow is not obvious.

The four reasons a Hue Bridge will not be discovered

In order from most to least common:

1. Your phone and the bridge are on different network segments (different VLANs, guest Wi-Fi, 5GHz vs 2.4GHz on isolated SSIDs)
2. Your router has mDNS or UPnP discovery disabled
3. The Hue cloud’s bridge discovery service is having an incident
4. The bridge is in an actual fault state

The Hue app uses two discovery mechanisms, in this order: it asks Philips’s cloud which bridges are associated with your account and on what local IPs, and it falls back to mDNS broadcasts on the local network. Both can fail independently.

Check the network segment first

This is the most common cause and the easiest to verify. From your phone, you should be able to reach the bridge’s local IP in a browser. Find the bridge IP by checking your router’s DHCP client list (look for a hostname starting with Philips-hue) or by opening https://discovery.meethue.com in your phone’s browser, which returns a JSON list of bridges seen from your current network.

Once you have the IP, open http://<bridge-ip>/api/config in your phone’s browser. If you see a JSON blob, your phone can reach the bridge and discovery should work. If you get a connection refused or timeout, your phone and bridge are not on the same network as far as routing is concerned.

Common causes of this:

• Your phone joined the guest network instead of the main one
• Your home network is split into a main SSID and a 5GHz only SSID, and the bridge is wired to a network that mirrors only one of them
• You have a smart home VLAN that does not allow connections from the main LAN

The fix is to make sure both are on the same network. Either join your phone to the main SSID temporarily, or configure your router to allow local discovery across segments. The latter usually means enabling “allow mDNS across VLANs” on a managed router like Unifi or pfSense.

Check that mDNS is enabled

If the bridge is reachable directly but discovery fails, mDNS is blocked somewhere. On most consumer routers, this is enabled by default. On business or prosumer routers, it sometimes is not. The exact setting varies:

• Unifi: “Multicast DNS” must be enabled per network
• Mikrotik: IGMP snooping must be off or correctly configured
• OpenWrt: install luci-app-mdns and enable on the LAN interface
• Apple AirPort or Linksys consumer: usually fine by default

If you cannot enable mDNS, the workaround is to use the bridge’s direct IP. The Hue app has a hidden manual IP entry. On iOS, go to Settings, Hue Bridge, scroll to the bottom, tap version five times. A debug menu appears with an “Enter bridge IP manually” option. Android has a similar gesture.

Check the Hue cloud

If your phone is on cellular data (not Wi-Fi) and you cannot discover bridges, the cloud discovery service is the only path the app has. If it fails, you cannot discover bridges remotely. Visit Philips’s status page in your browser. If they show a degraded discovery service, wait.

If you are on Wi-Fi and discovery still uses the cloud, the issue is also cloud-related. The app prefers cloud discovery when available because it is faster.

The bridge is in a fault state

If all the network checks pass and you still cannot discover the bridge, look at the bridge LEDs. The center LED should be solid blue. If it is anything else, see our Hue Bridge red light status guide. The two side LEDs should also be steady. A bridge with the right-side internet LED off cannot register with cloud discovery, which means cloud discovery will never find it. Reboot your router to give it a fresh internet connection, then power-cycle the bridge.

Recovering after a router change

One of the most common situations for this issue is after replacing a router. The bridge cached the old gateway IP and is trying to register with a network that no longer exists in the same form. The cleanest recovery is:

1. Power-cycle the bridge with the new router fully up first.
2. Confirm the bridge appears in the new router’s DHCP client list.
3. Open https://discovery.meethue.com from a device on the new network. The bridge should appear with its new IP within a minute.
4. Open the Hue app and tap to add a bridge.

If after step three the discovery page still shows the old IP, the bridge has not re-registered with the cloud yet. Wait five minutes and refresh.

What to do if nothing works

If you have exhausted these checks, the bridge is reachable on its local IP, mDNS is open, the cloud is healthy, and the bridge LEDs all look normal but the app still says “no bridge found”, the fix is usually to delete the Hue app, reboot the phone, and reinstall. The app keeps a local cache of bridge IDs that can become inconsistent with what the cloud knows. A clean install forces a fresh sync.

The two-network home and why it bites

Many homes split Wi-Fi into a main band and an IoT band on separate SSIDs without realizing how that breaks Hue discovery. The bridge is wired ethernet, which is on the main network. The phone is on the IoT or guest SSID for convenience. Same physical router, different network from a routing perspective.

Discovery uses mDNS, which by default does not cross subnets. You can either temporarily join the phone to the main SSID for the setup, or configure mDNS reflection on the router. The full setup for keeping discovery working across isolated networks is documented in our IoT VLAN guide.

Related reading: motion light guide.