LocalSend not working? Fix discovery, 'Waiting for response…' and firewall blocks

LocalSend not working usually means a network problem, not a broken app: the devices aren't really on the same local network, a firewall is blocking port 53317, or a phone hasn't been given local network access. Start with the checklist, then go to the section that matches what you're seeing.

LocalSend not working? Start with the two-minute checklist

Run through these on both devices. Most problems are one of them.

1. Same network. Both devices on the same Wi-Fi: not a guest network, and neither on mobile data. LocalSend's own hint is blunt: 'Please ensure that the desired target is also on the same Wi-Fi network.'
2. Same, current version. Update both to the latest release (v1.18.2 as of October 2026). LocalSend doesn't update itself, so copies downloaded from its website or GitHub need updating by hand (app-store and package-manager installs update through those), and v1.18.2 fixed compatibility problems with v1.17.0 and older.
3. App open on both. On an iPhone, keep LocalSend on screen. Its v1.18.0 notes say: 'On iOS, the app must still stay in the foreground.'
4. VPN off, or set to allow local network traffic.
5. Matching settings. In Settings, switch on Advanced settings and check that Port (53317 by default), Encryption and Multicast address match on both devices.
6. Troubleshoot button. Tap Troubleshoot at the bottom of the Send tab. On Windows it can add the firewall rules for you.
7. Manual sending. Tap the Manual sending icon next to Nearby devices and type the receiver's IP address.

LocalSend not finding devices: AP isolation, VPNs and manual IP

LocalSend finds devices by multicast on the local network (224.0.0.167, port 53317), then falls back to probing local IP addresses. Anything that stops devices talking directly to each other stops discovery. Errors such as 'No route to host' or a timeout mean the sender can't reach the receiver at all, so check isolation, VPNs and the receiver's firewall.

• AP isolation. Some routers stop devices reaching each other, especially on guest networks. LocalSend's README puts it simply: 'If it is enabled, connections between devices are forbidden.' Turn it off in the router's settings, or use the main network instead of the guest one.
• VPNs. 'Some VPNs block local network connections by default.' Allow LAN traffic in the VPN app, or pause it while you send.
• Big or split networks. A user in issue #654 found discovery failed on a network bigger than /24 when the two devices sat in different /24 ranges (10.0.0.x and 10.0.1.x); moving them into the same range fixed it. Manual sending by IP is worth a try too.
• Extra network adapters. LocalSend uses every network interface by default. With Advanced settings on, tap Network (it shows All) to exclude the ones you don't use, then restart the server, as the app asks.

Send by IP address, then save it as a favourite

1. On the receiving device, open the Receive tab and tap the info (i) button to see its IP address.
2. On the sending device, open the Send tab, tap the Manual sending icon next to Nearby devices and type in that IP address.
3. If that works, add the device to favourites (the heart icon) so LocalSend checks it directly next time.

iPhone or Mac can't find the PC: the 'No permission' message

On iPhone, LocalSend needs Local Network access. Without it you'll see a message titled No permission: 'LocalSend can't find other devices without having the permission to scan the local network. Please grant this permission in the settings.'

1. Open Settings → Privacy & Security → Local Network (Apple's steps).
2. Turn LocalSend on. If it's already on, turn it off and on again, as LocalSend's README suggests.
3. Reopen LocalSend and keep it on screen while you send or receive.

On a Mac

Same idea: System Settings → Privacy & Security → Local Network, then turn LocalSend on (Apple's guide). If the Mac is the one receiving, LocalSend's Troubleshoot page has an Open Firewall button that goes straight to the firewall settings.

Running a proxy app?

If you use a proxy such as Shadowrocket, update to v1.18.2. That release made LocalSend ignore system proxies, which had been causing 'TLS info not found' errors.

LocalSend stuck on 'Waiting for response…'

'Waiting for response…' means the sender found the receiver, asked to send, and is waiting for an answer. If the answer never comes, it's usually one of these:

• Nobody has accepted. Check the receiving screen for the request. A decline shows 'The recipient has rejected the request.' on the sender, and a busy receiver shows 'The recipient is busy with another request.'
• The receiver's firewall is blocking the transfer. The classic case is issue #654: a phone on Wi-Fi sending to a Windows PC on Ethernet sits on 'Waiting for response…' while PC-to-phone works fine. LocalSend's maintainer suspected a dismissed firewall prompt, and users fixed it by setting the Windows network profile to Private or opening the port.
• An old address. If the receiver is a favourite whose IP address has changed, say after moving from Wi-Fi to a cable, LocalSend can keep trying the old one. A user in the same issue fixed it by typing the new IP with Manual sending.

From v1.18.0, requests from favourite devices are accepted automatically (you can turn that off in Settings). Quick Save goes further and accepts everything, which LocalSend itself warns means 'everyone on the local network can send you files'.

LocalSend on Windows 11: Private network and port 53317

Windows is stricter on networks marked Public, and LocalSend's README says so: 'Windows might be more restrictive when the network is configured as public.' Fix the receiving PC in one of two ways.

Set the network profile to Private

Microsoft notes that Private makes your PC 'discoverable to other devices on the network' (Microsoft), so only do this on a network you trust, like home.

1. Open Settings → Network & internet.
2. Select Wi-Fi and then the network you're connected to, or select Ethernet.
3. Under Network profile type, choose Private network.

Let LocalSend add the firewall rules

1. In LocalSend, open the Send tab and tap Troubleshoot at the bottom.
2. Next to 'This device can send files to other devices but other devices cannot send files to this device.', tap Fix automatically. It needs administrator rights and adds inbound rules for LocalSend's port (53317 unless you changed it), TCP and UDP.
3. Or tap Open Firewall to check the rules yourself.

LocalSend on Linux: ufw, firewalld and portals

If the Linux machine can send but not receive, LocalSend's Troubleshoot page calls that 'most likely a firewall issue'. If a firewall is running, open LocalSend's port with the commands from its README:

• ufw: sudo ufw allow 53317
• firewalld: sudo firewall-cmd --permanent --add-port=53317/tcp, then sudo firewall-cmd --permanent --add-port=53317/udp, then sudo firewall-cmd --reload

Desktop portals

LocalSend's README also lists desktop portal packages as dependencies on Linux: xdg-desktop-portal plus xdg-desktop-portal-gtk on GNOME, or xdg-desktop-portal-kde on KDE. Make sure they're installed.

LocalSend on a Chromebook can't find devices

This one's a known bug rather than a setting. On a Chromebook, the LocalSend Android app runs inside ChromeOS's Android container, which sits on its own subnet (100.115.92.0/24 in the original report), so discovery looks in the wrong place. Issue #29 has been open since January 2023.

Typing the other device's IP address with Manual sending has worked for some people, sometimes only on a second try or after restarting the server on the receiving device (Settings → Network → Server). Others say it never worked. If it doesn't for you, use a browser tool: Beamaroo runs in Chrome on a Chromebook, and our iPhone to Chromebook guide covers the other options.

Slow LocalSend transfers

• Use 5 GHz Wi-Fi. It's the first item in LocalSend's own speed advice.
• Update both devices. LocalSend's in-app notes for v1.18.0 say 'Encryption no longer slows down transfers', and the same release sped up transfers to slow receiving devices.
• Expect Android receiving to be slower. The README lists it as a known issue.
• Leave encryption on. The README still suggests disabling it on both devices for speed, but then LocalSend switches to plain HTTP ('Communication now takes place via the unencrypted HTTP protocol'), and anyone who can watch the network could read your files. Since v1.18.0, LocalSend says encryption doesn't cost speed anyway.

When LocalSend can't work, and what does

Some situations can't be fixed from LocalSend's side, because as of October 2026 it needs both devices on one local network (its FAQ: 'Does it work over the internet? No.'):

• The other device is on mobile data or a different Wi-Fi network.
• You're on guest or hotel Wi-Fi and can't change AP isolation.
• It's a work laptop where you can't install apps, change the network profile or open ports.
• It's someone else's phone and they don't have LocalSend.
• It's a Chromebook hit by the discovery bug.

Beam it in the browser instead

Open beamaroo.com on both devices, share the one-time code, and the files go directly between them, encrypted, with nothing uploaded or stored. There are no firewall rules or ports to set up and no shared network needed; if a network blocks a direct connection, an encrypted relay passes the bytes along without being able to read them. Very locked-down work networks can still get in the way. Here's how the code pairing works.

The honest limits: both devices must be online at the same time, and both screens should stay on until it finishes, because there's no resume. Folders need zipping first. The receiving browser holds files in memory, so phones are comfortable up to a few hundred MB and computers up to about 1–2 GB. For big transfers between your own devices on one network, a working LocalSend is still the better tool. More in our LocalSend alternative comparison.