A device can be online and still be absent from a network scan. It may be on a different network segment, asleep, protected by a firewall, or unreachable through the scanner's current interface. A router's list may also include old clients that are no longer online.
Start with one device you know should be present. Confirm its current IP address, wake it, and check that it shares a reachable local network with the scanner. That gives you a useful test case instead of a device count to guess at.
Choose the symptom that matches your scan
| Scan result | Check first |
|---|---|
| Almost nothing appears | Local Network permission, active connection, VPN routing, guest Wi-Fi |
| Router appears but peers do not | Client isolation or separate network segments |
| One printer or camera is missing | Power state, current IP, firewall, Ethernet or Wi-Fi connection |
| IP appears but name or manufacturer is blank | Missing identity information or a private MAC address |
| Router lists more clients than the scan | Live clients versus DHCP history, other segments, sleeping devices |
| Device responds directly but is absent from inventory | Discovery method, selected interface, and scan range |
If devices are visible but unfamiliar, follow our unknown-device identification workflow. If your problem is missing Windows computers in File Explorer, use the separate network discovery and file-sharing guide.
1. Check Local Network permission
On iPhone or iPad, open Settings → Privacy & Security → Local Network and enable access for the scanner you intend to use. Reopen the app and scan again. An app can still access the internet when this permission is denied, so a working public-IP lookup does not confirm local discovery access.
On supported macOS versions, open System Settings → Privacy & Security → Local Network and check the scanner's permission. If the app is not listed, attempt its network scan so macOS can request access. Close and reopen it after changing the setting.
Apple documents the controls for iPhone and iPad and Mac. Grant access to an app you trust; a local scan requires communication with devices on your network.
On Android, check the permissions requested by your scanner and its documentation. Nearby Wi-Fi or location permissions may affect particular functions, depending on the app and Android version. They are not a universal explanation for every missing LAN device.
2. Confirm the scanner is on the right network
A phone on cellular data cannot perform an ordinary scan of devices on your home LAN. Join the intended Wi-Fi network. On a laptop, check whether Wi-Fi, Ethernet, a VPN, or a virtual adapter is the active path.
Your router may broadcast a main SSID, a guest SSID, and a separate IoT network. Similar names do not mean the clients can communicate. Guest Wi-Fi often permits internet access while blocking access to the main LAN.
For a home-network test, put the scanner and the known device on the main network where local communication is allowed. Keep intentional guest or IoT isolation in place; use a device connected to the appropriate segment if you need to inspect it.
3. Check guest-network and client-isolation settings
Look in your router or access-point settings for names such as AP Isolation, Client Isolation, Wireless Isolation, or Allow Local Access. These settings can stop clients reaching one another even when both can browse the web.
As a vendor example, TP-Link's guest-network documentation describes separate guest and main networks and model-dependent local-access controls. Use your own router's manual to confirm its behavior.
Being connected to 2.4 GHz rather than 5 GHz is not, by itself, a reason for devices to be invisible. Those bands are commonly bridged into the same LAN. The important question is whether the router allows communication between the clients.
4. Compare addresses and subnet masks
Read the known device's current address from its settings. On Windows use ipconfig; on Mac check Network → active service → Details → TCP/IP. Compare the subnet mask and gateway too.
With a 255.255.255.0 mask, 192.168.1.20 and 192.168.1.60 are in the same IPv4 subnet. 192.168.50.60 is in a different one. Other masks change the calculation; our CIDR guide explains how to read them.
A local scan may not cross VLANs or routed subnets. Even where direct unicast traffic is allowed, broadcast or multicast discovery may not cross the boundary. The router's all-client inventory can therefore contain devices that are outside your scan's reach.
For an IPv6-only device, check whether your scanner supports IPv6 discovery. An IPv4 sweep will not provide a complete IPv6 inventory.
5. Wake the missing device and verify its current connection
Unlock a phone, wake a laptop, turn on a printer, or open the device's network-status screen. Some battery-powered and IoT devices respond only while awake. Do not disable their power-saving features merely to keep an inventory full.
Check that the address is current. A saved address from last week may now belong to something else. Confirm Wi-Fi association or the Ethernet link rather than relying only on a stored DHCP lease.
Then rerun the scan. A device appearing only while awake points toward its response behavior rather than a permanent discovery failure.
6. Check reachability without treating ping as proof
From a computer on the same reachable network, try the known device's current address. For this example, replace 192.168.1.60 with that address:
ping 192.168.1.60Stop with Ctrl+C if the command continues running. A reply confirms that address answered ICMP from your computer. No reply does not prove the device is offline: a firewall or the device itself may ignore ping.
If the device has a documented web interface or service, test that known service too. A printer that accepts a print job while ignoring ping is still online. Different scanners use different combinations of probes, so their result lists can differ.
The site's online Ping tool and Port Checker run from outside your home network. They cannot directly test a private address such as 192.168.1.60. Use a local app or local command for this step.
7. Review VPN routes and endpoint protection
A VPN may route local traffic through its tunnel or apply a policy that blocks LAN access. If your VPN provides an allow-LAN setting, review it. On your own network, compare a scan with the VPN connected and disconnected if doing so is appropriate for your connection.
If discovery works only without the VPN, consult its local-network policy. On a managed work device, ask your administrator rather than changing enforced security controls.
Similarly, check the device firewall for rules affecting the expected discovery or service traffic. Use a narrow rule for the trusted network where appropriate. Turning off every firewall or enabling every sharing feature is not required for a scanner to discover a device.
8. Separate missing devices from missing details
A visible IP address with no hostname or manufacturer is a discovered endpoint with limited identity information. Not every device advertises a name. Private MAC addresses can prevent a vendor lookup, and platform restrictions may stop a mobile app obtaining a peer's MAC address at all.
An ARP or neighbor table is also not a complete inventory: it contains recently learned neighbors. Our ARP table guide explains what those entries mean.
For the Mac scanner, one basic scan is free; repeated scans and deeper investigation require Pro. More probes may add information, but a subscription cannot override network isolation or make a sleeping device respond.
What to record if the problem persists
Note the scanner version, operating system, connection type, subnet mask, current target IP, VPN state, and whether a documented service responds. Include whether the router entry is a live client or a stored lease. Avoid posting complete device inventories or identifiers publicly.
These observations distinguish a discovery limitation from a permissions problem, network boundary, or unreachable device. They also make a support request much more useful than “the scan found fewer devices.”