AirPlay, Chromecast or printer not showing up on the network

The device is powered on. It has an IP address. You can open its web page in a browser. And it still does not appear in the AirPlay list, the Cast menu, or the printer picker.

This is a discovery problem, not a connectivity problem, and the two are completely different. Streaming and printing do not start with you typing an address. They start with your device shouting a question onto the local network and waiting to hear who answers. If that question never reaches the other device, or the answer never comes back, the device simply does not exist as far as your phone is concerned, no matter how reachable it actually is.

How discovery actually works

Apple calls it Bonjour. The standards call it mDNS and DNS-SD. Chromecast uses the same mechanism, and so do most network printers, NAS boxes and smart speakers.

The idea is that there is no central directory. Your phone sends a multicast query to a special address that everything on the local network is listening to, essentially asking "is anyone here offering AirPlay?" Devices that offer it reply with their name, their address, the port, and a bundle of details about what they support. Your phone collects the replies and builds the picker list you see.

The important consequence: multicast does not cross network boundaries. It stays within a single broadcast domain by design. Move the two devices onto different subnets or VLANs and they become invisible to each other, even though a direct connection between them would work fine. Nearly every "it used to work and now it doesn't" story comes down to this.

Two tests that separate the two failure modes

You want to know which of these you have: the device is unreachable, or the device is reachable but its announcements are not getting through. Two tests, one minute.

1. Can you reach it at all?

   Find its IP address (the device's own settings screen, or a LAN Scan of your subnet) and connect to it directly. For AirPlay try port 7000, for Chromecast try 8009, for a printer try 9100 or 631. The TCP/UDP Connect tool opens a connection and tells you whether anything answered.

   If the connection opens, the device is alive, reachable, and serving. The problem is purely discovery. If it does not open, you have a routing or isolation problem instead, and discovery was never going to work.

2. Is it announcing itself?

   Run a Bonjour browse from the same device that cannot find it. This shows exactly what services are visible from where you are standing. If the target appears here but not in the AirPlay or Cast menu, the network is fine and the problem is in the app or the operating system. If it does not appear here at all, the announcements are not reaching you, and the network is where to look.

Direct connection	Visible in Bonjour browse	What it means
Works	Yes	Network is fine. Restart the app, then the device. Check app level permissions.
Works	No	Classic multicast problem. Different subnets, client isolation, or multicast filtering.
Fails	No	Isolation or a different network entirely. Check which SSID each device is on.
Fails	Yes	Unusual. The device is announcing but refusing connections, so check its own firewall or a sleep state.

# What is advertising itself on this network?
https://netdebug.app/open/bonjour

# Is the AirPlay port actually answering?
https://netdebug.app/open/portconnect?target=192.168.1.72&port=7000&protocol=tcp

The usual causes, in order

1. The two devices are on different networks

By far the most common. Your phone is on the guest network, or on a 5GHz SSID with a different name, or on a mesh node that hands out a different subnet. Compare the IP addresses: if one is 192.168.1.x and the other is 192.168.2.x or 10.x.x.x, they are on different networks and multicast will never bridge them.

Splitting 2.4GHz and 5GHz into separate SSIDs is usually fine, because most routers still bridge them into one network. Guest networks are the opposite: isolation is their entire purpose.

2. Client isolation is switched on

Also called AP isolation, client isolation, or "prevent devices from communicating with each other." It is normal on guest networks and standard in hotels, offices and student accommodation. Devices can reach the internet and nothing else. Discovery, printing and casting all stop dead.

The signature is distinctive: internet works perfectly, and no device on the network can see any other device. If a direct port connection to a device on the same subnet fails, this is the first thing to suspect.

3. Multicast filtering on the router

Some routers have settings named IGMP snooping, multicast forwarding, or multicast to unicast conversion. When these are misconfigured, multicast traffic is dropped or mangled, and discovery becomes unreliable in a maddening way: it works sometimes, or works for a minute after a reboot and then stops. If your devices are on the same subnet and still cannot see each other, look here.

4. VLANs without an mDNS repeater

If you separated your IoT devices onto their own VLAN (a genuinely good idea), you also cut off discovery between VLANs. Business and prosumer equipment generally offers an mDNS repeater or Bonjour gateway to forward announcements across specific VLANs. Without it, your phone on the main network will never see the speaker on the IoT one.

5. The device fell asleep or lost its lease

Printers are the worst offenders. Deep sleep modes stop them answering discovery queries until something wakes them. A DHCP lease that expired and was reassigned can also leave stale entries cached on your phone, pointing at an address the printer no longer has.

6. Stale cached entries

If a device shows up but fails when selected, your phone may be holding an old record with an old address. Toggling Wi-Fi off and on clears most of this. Restarting the phone clears the rest.

The iOS local network permission trap

Since iOS 14, apps must ask permission before they can talk to devices on your local network. The prompt appears once, usually at an inconvenient moment, and if you tapped "Don't Allow" then that app is now permanently blind to everything on your network until you change it manually.

The symptom is very specific and worth recognising: one app cannot find any devices, while other apps find them fine. Everything looks like a network fault and nothing about the network is wrong.

The setting lives in Settings, then Privacy and Security, then Local Network. Check the app in question is enabled. This one setting is responsible for a remarkable number of "Chromecast stopped working" reports.

A checklist that works

1. Confirm both devices are on the same network

   Not the same Wi-Fi name, the same network. Compare the first three octets of both IP addresses. If they differ, stop and fix that.

2. Check local network permission on iOS

   Thirty seconds, and it explains the "only this app" cases entirely.

3. Browse for Bonjour services

   If the device appears in the browse but not in the app, the network is doing its job.

4. Try a direct connection to the service port

   This separates "cannot reach" from "cannot discover" and points you at either isolation or multicast.

5. Restart in the right order

   The target device first, then your phone, then the router. Most guides say router first, but the router is rarely the problem and rebooting it costs everyone in the house ten minutes.

6. Check the router for isolation and multicast settings

   Guest network settings, AP isolation, IGMP snooping. If you have VLANs, check whether an mDNS repeater is configured.

The short version

Discovery and connectivity are different problems. Browse for Bonjour services to see what your phone can actually hear, and open a direct connection to the service port to see whether the device is alive. If it is reachable but silent, you have a multicast problem: different subnets, client isolation, or filtering on the router. If nothing is reachable at all, check which network each device is really on, then check iOS local network permission before touching anything else.