Giving a printer, NAS, or home-automation hub a predictable IPv4 address can make it easier to manage locally. A bookmark, backup target, or integration then has a consistent destination. But a fixed address can also cause an outage that's hard to track down if DHCP is already offering that address, it belongs to another network segment, or you copied it from an old router configuration.
“Does this address answer a ping right now?” isn't enough to go on. An address that doesn't respond may still be reserved for a sleeping client, blocked by a firewall, or reachable only from another part of the network. The checks below give you a short sequence for assigning a fixed address based on what you can verify, on a network you own or are authorized to manage.
DHCP reservations and static configurations
There are two common ways to give a device a predictable address. You enter a static configuration on the device itself. A DHCP reservation lives on the DHCP server, which offers the same address to a recognized client. Neither is always better. A reservation does, however, keep the gateway, DNS servers, and other network settings under the DHCP server's control.
First, check what the device supports and what manages its current network. A managed work network, guest Wi-Fi, IoT VLAN, or second router may use a different DHCP server from the main home router. Before setting a static address, identify which server is responsible and which subnet applies. If someone else or another organization manages the device, ask the responsible administrator to assign the address.
A fixed address won't fix weak Wi-Fi, a missing route, an unavailable service, or a name-resolution problem. Write down the original symptom. Otherwise, the new configuration may make it harder to work out what went wrong in the first place.
The correct network range
On a device that's currently connected, note its IPv4 address, subnet mask or prefix length, default gateway, and DNS servers. Check those values against the router or DHCP server serving that connection. RFC 1918 describes the private IPv4 ranges often used on local networks. It doesn't tell you which subnet your network uses or which addresses your DHCP service can allocate. See RFC 1918.
For example, an address starting with 192.168.1 isn't automatically suitable just because another device uses 192.168.1.20. The subnet mask determines which addresses are local to a particular interface. A private range that looks the same can also sit behind a downstream router or on a separate VLAN. The address you choose must belong to the network the device is supposed to join.
Record the current values before changing anything. If the device stops responding afterward, you'll have a known configuration to compare with its recovery procedure. Don't copy a gateway or DNS address from an unrelated network, a screenshot, or an old tutorial.
The DHCP scope and available addresses
Open the DHCP settings for the relevant network. Find the allocation range, reservations, exclusions, and current leases. Menu names vary, so look for DHCP server, address pool, leases, or client list. DHCP leases are usually time-limited and can be renewed; infinite leases are also supported. A lease table is useful evidence, but it doesn't show every static address in use. RFC 2131 describes this exchange.
A DHCP reservation for the device's actual network interface usually leaves the least room for confusion. If you need a static configuration, use an address that the local network documentation and DHCP configuration explicitly place outside the dynamic pool. Alternatively, create an exclusion using the router's documented procedure. Don't assume the last few addresses in a range are free. Check the router and any existing records.
Check the device's identity carefully, too. A laptop may have different MAC addresses for Wi-Fi and Ethernet, and phones and laptops can use private Wi-Fi addresses. The reservation needs to match the interface that will connect. If you tie it to an old identifier, the device may get a different dynamic address instead of the one you expected.
Reachability tests as supporting evidence
Before applying a static setting, look for the proposed address in current leases and any documented static-address list. A reachability check from an authorized machine on the intended network can tell you more, but it can't prove the address is unused. A device may ignore ping, be asleep, or sit behind a firewall while still owning that address.
IPv4 Address Conflict Detection is a specific protocol behavior. It doesn't guarantee that every client and network will reveal a conflict the same way. RFC 5227 explains how hosts that implement it probe and announce addresses. That background helps explain why a conflict might come and go, or appear only when a second device reconnects. Don't deliberately assign a duplicate address to see how your router reacts.
If a record assigns the proposed address to another device on the intended network, choose another documented address. If ownership is unclear, resolve it before proceeding. Stop if the records disagree. Before changing several settings at once, work out which DHCP server and network segment those records belong to.
A single change and full-path verification
Configure a static address on the device, or create a reservation on the responsible DHCP server using its documented procedure. Write down the old settings and proposed address, along with the time of the change and whether it requires a reconnect or restart. For a NAS or a device running backups, use a maintenance window. Changing the network configuration can interrupt transfers and make remote recovery harder.
Once the device reconnects, check more than the address it displays:
- Confirm that the address, prefix, gateway, and DNS settings match the intended network.
- Check that the DHCP server no longer offers the same address to a different client.
- Reach the device through one authorized local service or administration page.
- Confirm that any bookmark, integration, or backup target points to the new address.
- Keep a note of the old address until you know that no permitted local dependency still uses it.
If the device works locally but a service can't reach it, check routing, access rules, service state, or DNS separately. Changing the address again is unlikely to help explain any of those problems.
A short record for future changes
You don't need an elaborate address plan. A short entry with the device, interface, network, address method, address, and date is enough to prevent many accidental duplicates. Label any guesses as guesses. Update the record only after you've checked the actual configuration.
On networks you administer, DeviceShelf can provide one source of local observations when you compare devices and address changes. Use it alongside the responsible DHCP server and the device's own configuration. Seeing an address associated with a device doesn't, by itself, prove that the address is reserved, exclusive, or reachable from every network segment.
Choose an address after you've identified the right network and checked its allocation policy. Those checks take a few minutes, but they're much easier than recovering a device after two clients have been given the same address.