Your home server may still be running perfectly even when the old address stops working. The dashboard, media app, Docker service, or file share usually breaks because the address you saved no longer points to the same machine.
Before changing router settings, separate the problem into three possibilities: the server’s local IP changed, the public IP for remote access changed, or the name you use to reach the server is no longer resolving correctly. That first check prevents a simple local network issue from turning into a risky static IP or port forwarding project.
Start by Finding Which Address Changed
The first question is not how to set a static IP. It is which address stopped pointing to the server. Local access usually uses a private LAN address such as 192.168.x.x, 10.x.x.x, or 172.16.x.x. Remote access usually depends on your public IP, a domain name, a VPN address, or a tunnel.
If your browser bookmark was http://192.168.1.50 and the server is now 192.168.1.72, the problem is local. If the server still opens at home but fails from a phone on cellular data, the problem is probably remote access. Those two failures look similar, but the fix is different.
Check the server’s current address from the router’s client list, the server dashboard, or the server’s network settings. If you can still reach the router admin page, the connected devices list is often the safest first place to look.
Do this before changing anything. If you reserve the wrong device, set a static address on the wrong interface, or chase the public IP when the LAN IP moved, the server can become harder to find.
DHCP Is Usually Why the Local IP Moves
Most home routers act as a DHCP server. DHCP gives devices the network details they need, including an IP address, gateway, and DNS settings. The standard describes dynamic allocation as assigning a network address for a limited period of time, which is why a device does not permanently own the first address it receives.
That temporary assignment is called a lease. A server reboot, router reboot, firmware update, mesh network handoff, or expired lease can all lead to the server asking for an address again. The router may give it the same one, but it may also choose another available address from the address pool.
This is normal router behavior, not a sign that the home server failed. It only becomes a problem when your bookmarks, apps, scripts, or Docker service URLs depend on the old number.
Why Old Bookmarks and App Shortcuts Break
A saved IP address is literal. If your NAS dashboard, Jellyfin app, Home Assistant shortcut, or browser bookmark points to 192.168.1.50, it will keep knocking on that address even after the server moves somewhere else.
That old address might now be empty, assigned to another device, or blocked by a different service. The result can look like a timeout, a login failure, a forbidden page, or a blank browser tab. The server may be online the whole time; your shortcut is just pointing to the wrong door.
This also explains why one device may still work while another fails. A phone app may rediscover the server, while a TV app or browser bookmark may keep using the old IP until you update it.
A Router Reservation Is the Cleanest Fix for Most Home Servers
For most home servers, the cleanest long-term fix is a router-side DHCP reservation. Instead of forcing the server to manage its own address, you tell the router to give the same LAN IP to the same server every time.
Router vendors often call this feature Address Reservation, DHCP reservation, static lease, reserved address, or IP/MAC binding. The idea is the same: the router matches the server’s MAC address to a specific IP address inside your local network.
This is usually safer than editing network files on the server because the router stays in charge of the address plan. If you reinstall the server OS, change a Docker stack, or reset an app, the reservation can still keep local access stable.
Choose an address you can remember, but stay consistent with your router’s subnet. For example, if your router is 192.168.1.1, your reserved server address should usually stay in the same 192.168.1.x network unless you intentionally changed your LAN design.
When a Static IP on the Server Is Worth the Extra Care
A server-side static IP can also work, but it requires more care. In this setup, the server stops asking the router for an address and uses the IP, gateway, DNS, and subnet settings you enter manually.
The main risk is overlap with the DHCP pool. Cisco Meraki’s DHCP conflict guidance describes a common conflict case where a device uses a static IP that is still inside an active DHCP scope, causing two devices to use the same address and creating connectivity problems through an IP conflict.
That is why static IP should not be the first fix for every user. If you set the server to 192.168.1.50 while the router is still allowed to hand out 192.168.1.50 to another device, a guest phone, printer, or smart TV could collide with the server later.
Use a server-side static IP when you understand the DHCP pool, gateway, DNS, and subnet settings. For most home users, a DHCP reservation gives the same stable result with less chance of locking yourself out.
When a Hostname Works Better Than an IP Bookmark
You do not always need to memorize an IP address. A local hostname can make day-to-day access easier, especially when the server advertises a name such as myserver.local, casaos.local, or another friendly LAN name.
Multicast DNS, or mDNS, is designed to provide name resolution on a local link without requiring a conventional DNS server. That is why .local names can work well inside a home network when the operating system, router, and client device support them.
A hostname is not the same as a full remote access setup. It is mainly useful inside your LAN. If you leave home and try to reach the same server from the internet, .local will not replace Dynamic DNS, VPN access, or a tunnel.
The practical approach is to use both: reserve the server’s IP for stability, then use a local hostname for convenience. The reserved IP protects services that need a predictable address, while the hostname keeps daily access easier to remember.
When Wi-Fi or a Second Network Interface Makes the Address Look Different
A home server can have more than one network interface. Ethernet, Wi-Fi, virtual bridges, Docker networks, and VPN interfaces may all show their own addresses. If the server moves from Ethernet to Wi-Fi, the old wired address may stop working even though the machine is still online.
This is common when users add a wireless card or move a server to another room. The router sees the wired interface and wireless interface as different network identities because they have different MAC addresses. A DHCP reservation for Ethernet will not automatically apply to Wi-Fi.
For ZimaOS users, the AX210 Wi-Fi workflow is a useful example of checking the active network path. The ZimaOS guide for the AX210 Wi-Fi module shows users how to confirm the wireless card is detected, connect with nmtui, and verify the current IP address with ip a.
The same principle applies even if you are not using AX210. Before changing DHCP or static IP settings, confirm which interface is active and which address it received. A server with two working interfaces may simply be reachable at a different address than the one you saved.
When the Problem Is Actually Remote Access
If the server works inside your home but fails from outside, the local IP may not be the issue. Remote access usually depends on your public IP, a domain name, a VPN, or a tunnel.
A changing public IP is handled differently from a changing LAN IP. Dynamic DNS keeps a DNS record updated when the public IP changes, so a domain name can keep pointing to the right home network.
VPN and tunnel tools solve the problem in another way. Tailscale assigns devices stable tailnet addresses, which can make private remote access less dependent on your home router’s public address. A Cloudflare Tunnel can also connect services through outbound connections instead of requiring a publicly routable IP on the home network.
Do not mix the fixes. A DHCP reservation helps local access by keeping the server’s LAN IP stable. DDNS, VPN, or tunnel access helps remote access when the public side changes or when you do not want to expose ports directly.
A Low-Risk Fix Path Before You Change Network Settings
The safest troubleshooting path is to identify the broken layer first. Check whether the server has a new LAN IP, whether the old bookmark points to the wrong address, whether the active interface changed, or whether the failure only happens outside your home.
Once you know the layer, choose the smallest fix. For local access, start with a DHCP reservation. For daily convenience, add a local hostname. For advanced server-side control, use a static IP only after checking the DHCP pool. For remote access, look at DDNS, VPN, or a tunnel instead of changing the LAN address.
| Symptom | Likely Cause | Low-Risk Next Step |
|---|---|---|
| Old local IP no longer opens the dashboard | DHCP gave the server a new LAN IP | Check the router client list and create a DHCP reservation. |
| Server works on Ethernet but not Wi-Fi | Different interface received a different address | Check the active interface and current IP. |
| Phone app works but browser bookmark fails | Bookmark still points to the old address | Update the bookmark after reserving the server IP. |
| Static IP causes other devices to disconnect | IP conflict inside the DHCP pool | Move the static IP outside the pool or use router reservation. |
| Server works at home but not remotely | Public IP, DDNS, VPN, or tunnel issue | Check remote access separately from LAN DHCP. |
| Hostname works but IP changes | Local name resolution still finds the server | Keep using the hostname and reserve the IP for services. |
The goal is not to make the network more complicated. The goal is to give the server one stable local identity, then use the right name or remote access method for the way you actually connect.
FAQ
Why does my home server IP change after a reboot?
It usually changes because the router assigns local addresses with DHCP. After a reboot or lease renewal, the server may request an address again and receive a different one from the router’s address pool.
Is DHCP reservation better than setting a static IP on the server?
For most home servers, yes. A DHCP reservation keeps the address stable from the router side, which is easier to manage and less likely to create a bad server-side network configuration.
What happens if my static IP is inside the DHCP pool?
Another device can receive the same address from the router, creating an IP conflict. When two devices try to use the same IP, one or both may become unreliable or unreachable.
Why does my server work locally but fail outside my home network?
That usually points to remote access, not local DHCP. Your public IP may have changed, your DDNS record may be stale, your VPN may be disconnected, or your tunnel may not be running.
Can I use a .local hostname instead of an IP address?
Yes, if your devices support local name resolution. A .local hostname can make LAN access easier, but it does not replace DDNS, VPN, or tunnel access when you are outside your home network.
A broken home server bookmark does not always mean the server is down. In many cases, the server simply received a new local address, switched interfaces, or is being reached through the wrong access path. Start by finding which address changed, reserve the local IP when needed, and keep remote access troubleshooting separate from LAN troubleshooting.
Support & Tips
More to Read

Home Server Recovery Checklist: Password, Network, Boot, and Storage
A practical checklist for recovering a home server safely, from password access and network repair to boot recovery, storage checks, ZFS pools, and apps.

How to Choose Between RAID 5, RAID 6, RAIDZ, and Mirrored Drives
This guide explains how to choose between RAID 5, RAID 6, RAIDZ, and mirrored drives for a home NAS, media server, backup pool, Docker...

Which NAS Apps Actually Improve Speed, Backup, and Media?
Most NAS apps do not make a NAS faster by themselves. They improve the system only when they remove a real bottleneck: slow local...

