A device that usually gets the same local address can suddenly get a different one. That's inconvenient when a printer, NAS, home-automation hub, or bookmark expects the old address. Before you edit the DHCP reservation, check whether the device uses a private Wi-Fi address on this particular network. The reservation may still be correct. It may just point to a different Wi-Fi address than the one the router sees today.
This guide is for a network you own or are authorized to administer. A changed address does not necessarily mean something is broken or an unauthorized device has connected. The aim is to establish how one network, Wi-Fi address, and DHCP lease currently relate to each other, then make one deliberate change if needed.
The three separate records
A DHCP reservation is a rule on a DHCP server: when a recognized client requests configuration, the server should offer a chosen address. DHCP defines how the server and client exchange that information. A lease isn't a permanent label on a physical device. The router may also keep showing an old lease after the client disconnects, depending on its interface and how much lease time remains.
A Wi-Fi address is a separate record. A device uses it when associating with an access point. Some operating systems can use a private or randomized address to reduce tracking across networks. Apple documents a separate private Wi-Fi address for each network, with fixed and rotating modes on current systems. The setting and exactly how it behaves depend on the device, operating-system version, and saved network. An address change doesn't prove that the device's hardware changed or that somebody joined the network.
In practice, a reservation for the hardware address may not match the private address the device currently uses on the home SSID. The router can then assign an ordinary address instead. And an unfamiliar router entry can still be the same phone or laptop, using the private address selected for that network.
A record of the current connection
Open the router's DHCP or connected-client view. Write down the time, network name or VLAN, displayed client name, IP address, address used by the client, and lease state or expiration if shown. A privately stored screenshot can help, but don't share router screenshots that contain passwords, public addresses, serial numbers, or administration tokens.
Then check the device while it's connected to that same Wi-Fi network. On current Apple systems, the network's Wi-Fi details show the private address setting. The exact path and options vary by OS version. Android manufacturers can display network details differently, so check the settings for the connected network rather than looking for a label from an older screenshot.
Compare the device's current Wi-Fi address with the address in the router's active entry. Check the reservation's location, too: it needs to be on the DHCP server serving this network. A guest SSID, IoT VLAN, mesh satellite, or second router may have a different DHCP authority. Comparing an address from the main LAN with a reservation on a guest network won't explain the lease.
The address for the reservation
If the device and router show the same private Wi-Fi address, this is usually a choice about local policy, not something to fix. You can associate a reservation with the address the device presents on that trusted network. A lasting MAC-based reservation requires a stable address for that network. Where supported, use Fixed private addressing on the trusted network, then reserve that address. If rotation remains enabled, the reservation can stop matching after the private address rotates. Before saving, check that the chosen address isn't already reserved for another client and falls within the DHCP server's intended scope.
If the reservation holds an older address and the device now presents a different private address, confirm the device and that its address is stable for this network, then update only the reservation. Don't disable private addressing, set a manual IP on the device, and edit the router all in one attempt. Changing several things at once makes it hard to tell which change restored connectivity. It can also create an address conflict.
Some environments deliberately require a stable hardware address. Examples include a managed network, a captive portal, or a narrowly defined access policy. Follow that network's documented requirement. On a household network, updating the reservation to match the address actually used on that SSID is often less disruptive than weakening a privacy setting just to make the router table match an old note.
Lease renewal and verification
After one confirmed reservation change, reconnect the device to Wi-Fi or renew its DHCP lease through its normal controls. Check the router again. Look for a specific result: the same client address appears, the intended IP was offered, and the device can reach the local service it needs. The router page needs to have refreshed since the change.
If the intended address still isn't offered, stop before assigning a manual address. Check the reservation syntax and the relevant DHCP scope. Confirm that the device is actually on the expected SSID or VLAN, and check whether another DHCP server is present. A ping alone doesn't prove that the right device owns an address. Verify from both the router and the device where possible.
For a device that must remain discoverable, record the network name, the address the router uses for its reservation, and the date you confirmed it. Don't treat a MAC address as a person or a permanent identity. It's a network clue, and its meaning depends on the interface and network in use.
An inventory for comparison
A small inventory gives you something to check when an entry changes later. Note the device's role, SSID or segment, current reserved IP, and whether it uses a private Wi-Fi address where relevant. Keep Wi-Fi passwords and router administrator credentials out of the inventory. When a router entry changes, compare it with the dated record and the device's own settings before blocking anything.
DeviceShelf is one possible local comparison tool for an authorized network. Check its observations against the router and the device itself. Sleeping clients, guest-network isolation, and different network segments can all limit what a scan can see. Use the scan as evidence for comparison, not as a reason to overwrite a DHCP rule automatically.