LocalSend device not showing: the README's five fixes, explained
If a LocalSend device is not showing, the app's own troubleshooting table gives five fixes for "Device not visible", and four of them apply to a Mac and an Android phone: disable AP isolation on the router, toggle the Local Network permission on the Mac, stop any VPN from blocking local traffic, and send manually to the other device's IP address. The fifth is for Windows. Behind all of them is one fact from LocalSend's protocol notes: devices find each other by sending a small announcement to everything on the local network, and anything that stops that announcement makes the other device invisible.
The fixes here come from the LocalSend README and the project's protocol document. Installing and sending is covered in LocalSend from Mac to Android. This page is only about the empty device list.
Symptom, cause, fix
| What you see | Cause the README gives | Fix |
|---|---|---|
| Device not visible, either direction | AP isolation. "If it is enabled, connections between devices are forbidden" | "Make sure to disable AP-Isolation on your router" |
| Device not visible on a guest network | The same. Some routers enable AP isolation, "especially guest networks" | Move both devices to the main network |
| Mac is sending, phone not visible | The macOS permission | "Toggle the Local Network permission under Privacy in the OS settings" |
| Device not visible with a VPN on | "Some VPNs block local network connections by default" | "Allow local/LAN traffic or temporarily disable the VPN" |
| Device still not visible | Discovery is failing, though the devices may be able to reach each other | "Use manual sending to enter the receiver's IP address directly. If that works, add the device to favorites so it is probed directly" |
| Visible, but sending or receiving fails | A firewall | Allow incoming TCP and UDP on port 53317, and all outgoing |
How does LocalSend find other devices?
The protocol document describes two methods.
Multicast, the default. When the app starts, it sends an announcement to a multicast address, 224.0.0.167, on UDP port 53317. Every LocalSend device on the network that hears it replies. Multicast is a message addressed to a group on the local network, and it does not leave that network.
HTTP, the fallback. The document says this "should be used when multicast was unsuccessful". In this mode, "devices are discovered by sending this request to all local IP addresses" on TCP port 53317.
Three things follow from that. Both devices have to be on the same local network, because neither method reaches beyond it. A router that forbids devices from talking to each other defeats both methods. And a device that cannot hear the announcement can still be reached if you tell LocalSend its address, which is what manual sending does.
What should I check, in order?
- Open LocalSend on both devices and leave it open. The protocol document says the announcement is sent when the app starts, so a device where the app is closed has nothing to answer with.
- Check both are on the same network. Look at the Wi-Fi name on each. The phone must be on Wi-Fi, not mobile data. LocalSend's site says it "uses your local WiFi network to transfer files" and does not work over the internet.
- Leave the guest network. The README singles out guest networks as the place AP isolation is usually switched on. If either device is on a network with "guest" in its name, move it.
- On the Mac, toggle the Local Network permission. Apple's Mac User Guide gives the path: Apple menu, System Settings, Privacy & Security, Local Network. Turn LocalSend off and on again there, which is what the README means by toggle.
- Deal with the VPN. If either device runs a VPN, look in the VPN app for a setting that allows local or LAN traffic. If there is none, turn the VPN off while you transfer.
- Try manual sending. Enter the other device's IP address directly. The README's point is diagnostic as much as practical. If manual sending works, the two devices can reach each other and only discovery is blocked. Add the device to favorites, and the README says it will then be "probed directly".
- Check the Mac's firewall. The README's setup section says to allow incoming TCP and UDP on port 53317. The macOS firewall is set per app. Apple's firewall page gives the path: System Settings, Network, Firewall, Options. Add LocalSend and allow incoming connections. Apple notes that when an app not on the list receives a connection, an alert appears, and until you answer it "any attempts to connect to the app are denied".
- Disable AP isolation on the router. This is the README's first row and the hardest to act on, because it means signing in to the router. The README says it "should be usually disabled by default". The setting's name varies by router maker, and the README does not list the variants.
What if I do not control the network?
On office, hotel, university, or cafe Wi-Fi you cannot change the router, and AP isolation may be deliberate. The README offers no workaround for that beyond manual sending, and manual sending cannot get through if the network forbids connections between devices.
The README does not describe a phone hotspot as a workaround, so we will not promise that it works. It is a five-minute test: turn on the phone's hotspot, join it from the Mac, open LocalSend on both, and see whether the devices appear.
Failing that, use a cable. Options are in every way to transfer files from Android to a Mac.
What does the README not cover?
Mesh systems, range extenders, and Android permissions are not mentioned. Nor does it say that mismatched app versions hide devices, though it notes the app "does not have an auto-update", so update both before you file a bug. LocalSend's site asks for bug reports on its GitHub Issues page.
Is another tool less fussy about the network?
Publisher note: The Relay publishes this guide and is one of the products discussed. Details about other products come from each maker's own pages, checked on 1 October 2026. Prices and features change, so confirm before you buy.
Not in the way you might hope. Any app that sends directly between a phone and a Mac needs the network to let the two talk. That is true of NearDrop. The Relay also works over your own Wi-Fi network, with Bluetooth as a fallback, so it is not something to buy as a cure for AP isolation.
Where The Relay differs is in what happens once the devices can see each other. The Relay's file transfer and browsing shows the phone's storage in a window on the Mac, and the same app carries the clipboard, texts and login codes, notifications, and calls. It costs $19.99 once. LocalSend is free and open source, and if sending a file now and then is all you need, fix LocalSend and keep it.
Questions people ask
Why can my phone see my Mac in LocalSend but not the other way round?
The README has a row for exactly this when the Mac is the sender: toggle the Local Network permission in the Mac's privacy settings. The README does not explain the mechanism. It gives the fix, and Apple's page says that permission controls whether an app can find devices on your local network.
What port does LocalSend use?
Port 53317, for both TCP and UDP. The README says to allow incoming traffic on that port and all outgoing traffic.
Does LocalSend work if the devices are on different Wi-Fi networks?
No. LocalSend's site says it uses your local Wi-Fi network and does not work over the internet. Both devices must be on the same local network.
KEEP READING
LocalSend Mac to Android: Setup and Sending Both Ways
LocalSend from Mac to Android, step by step: where to install it on each device, the same-network rule, the macOS permission to allow, and fixes if nothing shows up.
NearDrop vs LocalSend: Mac to Android File Sharing
NearDrop makes a Mac a Quick Share device; LocalSend runs its own app on both ends. How each works from Mac to Android and back, per their READMEs, and which to pick.