A router lists a device as connected, but a network scanner can't find it. Or the scanner finds an address that doesn't appear in the router's list. That doesn't automatically mean either tool is broken. Each collects different evidence, and the observations may come from different times.
This guide is for a network you own or are authorized to administer. The goal is simple: compare the router's device list with a scan and find a useful next check. The comparison can't prove who owns a device, bypass network controls, or diagnose every connectivity problem from one screen.
The information behind each list
Most home routers keep a DHCP lease table, often displayed as a client or connected-device list. DHCP offers network settings, including an IP address, for a limited lease period. A record can include a client identifier or MAC address, a hostname, the offered address, and lease timing. It tells you what the DHCP server knows about an address assignment. RFC 2131
That's useful, but it isn't necessarily a live presence check. A client can still have a valid lease while asleep, unplugged, out of Wi-Fi range, or connected to a different access point. Some router interfaces hold on to entries that look historical longer than you might expect. A device with a manually configured address, meanwhile, may never appear as a normal DHCP lease.
A network scan checks something else: which hosts respond or leave discoverable evidence from the place on the network where you're running it? Depending on the tool, it may use ARP on a local IPv4 network, ICMP, TCP probes, neighbor tables, name-resolution records, or service announcements. Nmap's host-discovery documentation shows why both the selected probes and your position on the network affect the results. Nmap: Host Discovery Controls
The lists often overlap enough to be useful. They won't necessarily match exactly.
Devices in the router list that a scan misses
Timing is the simplest explanation. A lease can remain active while the device is sleeping or disconnected. Battery-powered sensors, phones with Wi-Fi power saving, and laptops with closed lids are common examples. Wait for the device's normal activity instead of repeatedly forcing it to reconnect just to get the lists to agree.
Then consider network boundaries. A scan from one VLAN, guest network, or Wi-Fi isolation zone may not reach hosts on another segment. A mesh controller may list clients that a computer on a guest SSID can't reach with ARP or probe traffic. Firewall rules can cause the same mismatch. The device has an assigned address, but the probe you've chosen gets no answer.
The scan method matters, too. A host might ignore ICMP echo but answer a local ARP request; while asleep, it might answer neither. ARP resolves an IPv4 address to a link-layer address on the local network and doesn't cross routed boundaries. RFC 826 Record how you scanned before deciding what a missing result means.
Addresses a scan finds outside the router list
The device may have a static address. Printers, NAS appliances, lab equipment, and old devices are sometimes configured locally rather than getting an address from DHCP. They can respond on the network without a current lease entry in the router.
You may also have more than one DHCP server. Another router, a misconfigured extender, a lab subnet, or a virtual-network service can hand out addresses independently. The router page you're looking at may simply not be the authority for that device's network. Before changing reservations or deleting entries, identify the DHCP server that actually serves the segment.
Or the scan may be showing stale local evidence. Operating systems keep ARP and neighbor-cache entries for a while. An entry means the machine learned a mapping, not that you have timestamped proof the device is still on the wire. Compare that entry with a fresh scan and with the device's normal service, such as its management page or a file share, where doing so is safe and authorized.
Fields for comparing devices
Router labels help, but they're weak identifiers. A label may come from a hostname, be assigned manually, get reused after a reset, or be cut short by the interface. Start with the IP and MAC addresses, writing each MAC address exactly as displayed. For a device with multiple network adapters, check that you're comparing the adapter used on this network.
A MAC vendor lookup provides only a clue to a device's identity. It may tell you which manufacturer owns an address block. It can't prove the model or who is using the device. Modern phones and computers can also use private Wi-Fi addresses, so the address you see on one SSID may differ from the hardware's factory address.
Keep a short comparison note. Include the observation time, the router page or controller you used, the scan machine and network, and the methods used. Those details make a vague disagreement reproducible. For example: “router lease at 10:15; ARP scan from wired LAN at 10:18; phone on guest Wi-Fi.”
A safe sequence for resolving a mismatch
- Confirm that the router list covers the same LAN, VLAN, or SSID as the machine running the scan.
- Compare the IP and MAC addresses, not just the device name. Note whether the router marks the lease as active, offline, or historical.
- Run one fresh local discovery method appropriate to the segment, then record the time and result.
- If the device should be online, check one ordinary service you're allowed to use, such as its local web interface or a known file share.
- Check for guest isolation, VLAN rules, mesh nodes, extenders, a second router, or a static-address configuration before editing DHCP settings.
- Leave the device alone if the remaining explanation is normal sleep or scheduled downtime. A missing scan response alone isn't a reason to reboot equipment.
Following this sequence avoids two common mistakes: assigning a new reservation to an address that belongs to another DHCP domain, and mistaking a legitimate sleeping device for an intruder. If you can't establish which network segment is involved, stop and map the topology before making changes.
Inventory tools and their limits
If you make this comparison regularly, an inventory tool can help you keep a dated record of addresses, names, and changes. DeviceShelf is one option for discovering devices on a local network and reviewing the results alongside router information. Treat it as another source of observations, not proof that a router, client, or network rule is wrong.
Usually, the comparison leaves you with a more specific question: is this a current DHCP lease, a reachable host on this segment, a cached observation, or a device behind a boundary? Once you've pinned that down, it's much easier to investigate the relevant router, switch, access-point, or device setting.