For example, you open your router's device list and count 18 clients. A scan of the same home network finds 14, or 23. Neither number is automatically wrong. The two tools answer different questions, at different times, and don't see the network the same way.
Before treating an extra entry as an intruder or assuming a missing device is offline, it helps to understand that difference. A router usually keeps records of addresses it assigned or devices it learned about. A scanner sends traffic or checks local network information to see what's there. Both are useful. Neither gives you a complete, permanent inventory on its own.
This guide is for a network you own or are authorized to administer. It covers common reasons the lists don't match, how to compare them without changing configuration, and what evidence to keep when a device needs investigation.
The router's device list
Labels such as Connected devices, Network map, DHCP clients, and Known devices can sound interchangeable. They aren't. A DHCP client list is mainly a record of address leases. DHCP defines how a client obtains and renews a configuration lease, and the router may keep that record until the lease expires. By then, the device may have gone to sleep, left the house, or switched networks. A remembered hostname or icon can outlast the connection it described. RFC 2131: Dynamic Host Configuration Protocol
Some routers also show clients learned from their Wi-Fi or Ethernet tables. Others put current and historical entries on the same screen. How this works depends on the router and firmware. Instead of relying on the total at the top of the page, look for a status indicator, last-seen time, connection type, IP address, and MAC address. An entry with no recent activity but a remaining lease is a clue about a past connection, not proof that the device is online now.
A network scan's view
A local scanner usually looks for hosts that answer while the scan runs. On an Ethernet or Wi-Fi LAN, it may use ARP to ask which device owns an IPv4 address. Depending on the tool and its settings, it can also use ICMP, TCP, UDP, or protocol-specific discovery. Nmap's documentation treats host discovery as a separate step and explains that different probes get different kinds of responses. A quiet or filtered host can be missed by one scan and found by another. Nmap: Host Discovery
Where you run the scan matters too. A laptop on guest Wi-Fi may be deliberately separated from devices on the main LAN, and a scan from one VLAN may not reach another VLAN. A phone using mobile data or a VPN isn't necessarily probing the same path as the router. Before comparing results, check that the scanning device is on the intended local network. Note its address and network name.
A scan doesn't ask a device to identify itself fully. The device might answer ARP but block ping, respond on one port but ignore another, or sleep between probes to save power. A scan can also find a router, access point, printer, NAS, or phone without finding a useful name for it. The result tells you what was observed at a particular time. It doesn't settle who owns a device or what it's for.
Common reasons for different counts
Timing is a good place to start. A phone may have joined Wi-Fi after the scan, or a tablet may have gone to sleep before it. Refresh the router page and run one new scan within a few minutes. A scan from today and a router screenshot from last week aren't a useful comparison.
Then compare addresses rather than names. Router names often come from DHCP, a device hostname, or a label an administrator entered. A scanner may obtain hostnames through reverse DNS, mDNS, or NetBIOS, and manufacturer labels through a MAC vendor lookup. Those sources can disagree. They can also be missing or out of date. The MAC address and current IP address are more useful for matching entries, though privacy features still need care.
Modern phones and laptops may use a private Wi-Fi address instead of their hardware MAC address. Apple documents that its devices can use a private Wi-Fi address per network to reduce tracking. If that address changes, a familiar phone can look like a new entry in the router's list. Don't block or delete an entry just because its vendor name is missing or its MAC address looks unfamiliar. Check the device's Wi-Fi settings first, including whether its private address was changed or reset. Apple: Use private Wi-Fi addresses
Scope matters as well. A mesh system may include a main router and several nodes, each with its own management address. A wired switch, access point, or virtualization host can expose more than one interface. Docker or other virtual networking can create addresses that mean something on the host but don't represent ordinary household devices. You don't need to force every entry into a one-to-one list. Record which entries represent infrastructure and which represent endpoints.
A comparison worksheet
Use a short worksheet you can repeat:
- Record the date, time, timezone, network name, and the device from which the scan runs.
- Export or screenshot the router list if the interface supports it. Otherwise, record the current IP, MAC, connection type, and last-seen value for each uncertain entry.
- Run one local scan and save its timestamped result. Don't run repeated aggressive probes just to make the count match.
- Match entries by current IP and MAC address first. Use names and vendor information as supporting clues.
- Mark each mismatch as “router only,” “scan only,” “renamed,” “private address possible,” or “needs confirmation.”
- Confirm an important unknown entry from a second source, such as a switch port, Wi-Fi access-point association, or the device's own network settings.
This gives you a calmer way to assess the differences than guessing from a count. A router-only entry whose last-seen time looks old is different from a scan-only device answering right now. An unfamiliar MAC address present in both views gives you stronger grounds to investigate. Even then, it could be a phone using a private address, a recently added smart device, or managed infrastructure.
Unfamiliar devices that need action
If a device is active in both views and you can't account for it, save the evidence before changing anything: current time, IP, MAC, connection type, router or access-point name, and any hostname. Check your own phones, tablets, media devices, work equipment, guests, and smart-home hardware. Ask household members before assuming the connection is unauthorized.
Before blocking a device or changing the Wi-Fi passphrase, identify the device you use to administer the router and your network infrastructure, and test an alternative connection to the router's management interface. Blocking the wrong entry can disrupt legitimate devices or cut off your management access. Expect Wi-Fi devices to need reconnection after a passphrase change. If you still can't identify it, use the router's normal access controls to remove or block the device. Then change the Wi-Fi passphrase if that's appropriate for your network, and reconnect known devices deliberately. Security changes vary by router. Follow its current documentation instead of using commands copied for another model. A single network scan can't establish who used a device or why it appeared.
For ongoing inventory checks, DeviceShelf is one local option that can discover devices and keep an inventory for comparison over time. Use it as another record alongside the router's information. A stale lease, an unclear hostname, or a sleeping device will still need some explanation. Product website
A baseline for future comparisons
Once you've matched the ordinary devices, set a simple routine for maintaining the inventory. Keep the device name, owner or location if appropriate, MAC address, normal IP behavior, and the reason you recognize it. Update the inventory when you add a camera, printer, NAS, access point, or guest network. Don't publish unredacted screenshots. Internal hostnames, addresses, and device names can reveal more about a home or small office than you intended.
The next time the router and scanner disagree, start with that baseline and the timestamps. Instead of an alarming count, you'll have a specific question: “why does this address appear now?” or “why is this known NAS not answering?” That's usually enough to decide whether to wait for a sleeping device, correct a label, inspect network segmentation, or take a security action.