Why your NAS or server keeps dropping off the network

A server that is reliably down is annoying. A server that disappears for ninety seconds every few hours and then comes back is far worse, because by the time you go to look at it, it is fine, and you have nothing to investigate.

These faults have a small set of causes, and several of them are settings nobody thinks of as network settings at all. Here they are, roughly in order of how often they turn out to be responsible.

First, catch it happening

Everything else depends on knowing what actually stops. Three things can disappear independently, and they point in different directions.

1. Run a continuous ping at the server's IP address

   Set the count to 0 in Ping and leave it running from another device. When the outage happens, the question is whether ping stopped too. If it did, the machine or its network connection went away. If ping kept answering while the service was unreachable, the machine is fine and an application or a firewall is at fault, which is a completely different investigation.

2. Watch the service port as well

   A TCP connect to the service port distinguishes "the host is up but the application died" from "the host vanished." On a NAS this is often the difference between a disk problem and a network problem.

3. Note whether it recovers on its own

   Self healing after a fixed interval suggests something with a timer: a DHCP lease, a power saving state, a link renegotiation. Recovery only when you touch it suggests a hardware or driver fault.

4. Check whether anything else drops at the same moment

   If several devices go quiet together, the problem is upstream: the switch, the access point, or the router. If only one does, it is that machine or its port.

Because runs are saved in Run History with timestamps, an intermittent fault becomes something you can correlate against server logs and switch logs instead of something you are describing from memory.

The static IP that was never safe

The most common cause, and the one people are most confident is not the problem, because they configured that address deliberately.

Here is the failure. You set a static address on the server, say 192.168.1.50. Your router's DHCP pool hands out 192.168.1.2 through 192.168.1.254. Your static address is inside that pool.

For months nothing happens, because the router never happens to allocate .50. Then a visitor joins with a new phone, the pool reaches that number, and now two devices claim the same address. What follows is exactly the symptom being described: intermittent unreachability, sometimes for one device and sometimes for the other, depending on whose entry each machine cached most recently.

Two ways to fix it, and one is clearly better:

• A DHCP reservation, not a static address. The router always gives that machine the same address and knows it is taken. One place to look, no conflicts possible, and the machine still gets DNS and gateway settings automatically.
• A static address outside the pool. Shrink the DHCP range and put static assignments below or above it. Works fine, but now there are two places where addressing lives.

To check whether you have a conflict, run a LAN scan while the server is powered off. If its address still answers, something else has it. That is a thirty second test that settles an argument.

A related case: two DHCP servers on the same network. An old router left plugged in as a switch, or a second device in router mode, will hand out addresses from a different range and point clients at the wrong gateway. The symptom is devices that work or fail depending on which server answered first when they joined.

Energy efficient Ethernet

This one is genuinely obscure and causes a very characteristic fault.

Energy Efficient Ethernet, sometimes labelled green Ethernet or EEE, lets a network port drop into a low power state when traffic is idle and wake when it resumes. On well matched equipment it works fine. On mismatched equipment, which describes most homelabs, the negotiation can fail and the link flaps: it drops, renegotiates, and comes back a few seconds later.

The signature is precise. Brief drops, a few seconds to a minute, during quiet periods rather than under load, and the machine is otherwise completely healthy. Overnight is common, which is why people often notice it as failed backups rather than as a network fault.

Two places to look. The network adapter's advanced settings on the server, where the option is usually named Energy Efficient Ethernet or Green Ethernet, and the switch's per port settings if it is managed. Turning it off on both ends of the problem link is the test. The power saving is negligible at homelab scale and the reliability is worth more.

A related setting on some adapters, often called interrupt moderation or various power management options in the driver, can produce similar symptoms. If EEE alone does not resolve it, the adapter's power management tab is the next place to look.

Sleep settings that are not network settings

Several things put a machine or its network card to sleep, and none of them announce themselves as networking.

The operating system's power plan. Windows in particular defaults to allowing the computer to turn off the network adapter to save power, in Device Manager under the adapter's power management tab. On a server that setting is simply wrong, and it produces exactly the intermittent disappearance being investigated.

NAS hibernation and disk spindown. Most NAS firmware has aggressive power saving. Disk spindown is usually harmless and just makes the first request slow. Full system hibernation is not, and a NAS that hibernates will be unreachable until something wakes it, which may be nothing at all if the thing that would have woken it is the request that just failed.

Wi-Fi power saving. If your server is on Wi-Fi, the client will save power between packets, and it may drop to a lower rate or briefly lose the association. A server should be on a cable. This is the least popular advice in homelabbing and the most consistently correct.

Virtual machine and hypervisor settings. A VM whose host suspends, or whose virtual adapter is attached to a bridge that reconfigures on a network change, will disappear in a way that looks like a physical fault. If the host stayed reachable while the guest did not, start there.

When the address is fine and the name is not

Worth separating, because the fix is somewhere else entirely.

If the server answers on its IP address but not by name, nothing about the machine is wrong. Your name resolution is. The usual suspects are a DNS record that is stale or was never created, a resolver that restarted with an empty configuration, or an mDNS name that stopped being announced.

Test it directly. Ping the IP address, then resolve the name with a DNS lookup pointed at your internal resolver. If the address works and the name does not, you are debugging DNS, not the server.

On a network using .local names there is a further wrinkle: those are answered by the device itself over multicast, so a machine that is busy, asleep, or on a different segment stops responding to name queries while remaining perfectly reachable by address. A Bonjour browse shows whether it is still advertising.

The physical layer

Last because it is least glamorous, and worth checking because it is cheap.

The cable. Gigabit needs all four pairs, and a damaged pair drops the link to 100 megabit silently or causes it to renegotiate repeatedly. If a throughput test comes back near 94 Mbps, that is the clue, and there is more on reading that number in the post on testing speed between two machines. Swapping a cable takes thirty seconds and resolves a surprising share of intermittent faults.

The switch port. Move the server to a different port. If the problem follows the port, you have found it. Cheap unmanaged switches do fail one port at a time, and they do it gradually.

Heat. A switch or adapter that works for two hours and then starts misbehaving is a thermal story. Check it is not in a cupboard with no airflow, which is where switches usually end up.

Power. Anything on a cheap power adapter or a crowded extension lead is worth eliminating, particularly if drops correlate with other appliances starting.

The short version

Run a continuous ping and a port check from another device so you know what actually stops and when. Then check the address is a DHCP reservation rather than a static one sitting inside the DHCP pool, because that is the most common cause by a distance. Turn off Energy Efficient Ethernet if the drops are brief and happen when the network is quiet, turn off adapter power management and system hibernation on anything that calls itself a server, and put it on a cable. If it answers by address but not by name, stop looking at the server and start looking at DNS.