Wake-on-LAN not working? Here is the whole chain to check

Wake-on-LAN is one of those features that either works immediately or refuses to work for reasons nobody can see. There is no error message. You send the packet, nothing happens, and there is no feedback anywhere to tell you which of the eight possible prerequisites was not met.

That is the real difficulty: the sender gets no confirmation by design. A magic packet is fire and forget, so "it did not work" could mean the packet never left, never arrived, arrived at the wrong address, or arrived perfectly at a machine that was configured to ignore it.

Here is the whole chain, in the order worth checking.

How a magic packet actually works

When a machine sleeps, its network card stays partly powered and keeps watching the wire. It is not running an operating system, it has no IP address, and it cannot participate in anything. It is listening for exactly one pattern.

That pattern is the magic packet: six bytes of FF followed by the target's MAC address repeated sixteen times. The card scans every frame it sees for that sequence, and when it finds its own address repeated, it tells the motherboard to power up.

Three things follow from this and they explain nearly every failure:

• The packet is addressed by MAC, not by IP. The sleeping machine has no IP address for you to send to.
• It has to be delivered as a broadcast, because nothing on the network knows where that MAC address lives while the machine is asleep.
• Broadcasts stay inside one subnet. Routers do not forward them, which is why this works on a LAN and needs help across the internet.

The packet itself is usually wrapped in UDP and sent to port 9 or 7, but the port barely matters: the network card is pattern matching on the payload, not listening on a port in any normal sense. Port 9 is the common convention.

The broadcast address is the usual culprit

This is the mistake that accounts for most failures, and it is subtle because the wrong answer sometimes works.

People send the magic packet to the sleeping machine's old IP address, for example 192.168.1.40. To deliver that, your device needs to know which MAC address sits at 192.168.1.40, and it looks that up in its ARP cache. If the machine went to sleep recently the entry may still be there and the packet gets delivered. An hour later the entry has expired, nothing answers the lookup, and the packet is silently dropped.

Hence the classic report: "it worked once and then stopped."

Send to the subnet broadcast address instead. For a /24 network like 192.168.1.0/24, that is 192.168.1.255. Every device on the segment receives it, including the sleeping network card, and no address lookup is needed.

If you are not sure what your broadcast address is, a subnet calculator gives it directly from your address and prefix. It is always the highest address in the range, and on anything other than a /24 it is not the number people guess.

# Right: subnet broadcast, port 9
https://netdebug.app/open/wol?mac=AA:BB:CC:DD:EE:FF&broadcast=192.168.1.255&port=9

# Open it pre-filled without sending, to check the values first
https://netdebug.app/open/wol?mac=AA:BB:CC:DD:EE:FF&broadcast=192.168.1.255&autorun=false

While you are checking values, confirm the MAC address is the right one. Machines have several: wired, wireless, Bluetooth, and often virtual adapters from VPN software or virtualisation. Wake-on-LAN almost always needs the wired adapter's address. Copying the Wi-Fi MAC by mistake is a common and completely invisible error.

Settings on the machine you are waking

Wake-on-LAN usually needs enabling in two separate places, and both have to agree.

In the BIOS or UEFI

Look for "Wake on LAN", "Power On by PCI-E", "Resume by PCI-E Device", "Power On by Onboard LAN" or similar wording. Manufacturers name it inconsistently and it is frequently disabled by default. There may also be a separate setting controlling whether the machine can wake from full shutdown as opposed to only from sleep.

In the operating system

On Windows, open Device Manager, find the network adapter, and check the Power Management tab. Two boxes matter: "Allow this device to wake the computer" and "Only allow a magic packet to wake the computer." The second one is worth enabling, because without it the card will wake on all sorts of ordinary broadcast traffic and the machine will refuse to stay asleep.

The adapter's Advanced tab often carries additional entries such as "Wake on Magic Packet" and "Shutdown Wake-On-Lan" that need to be enabled separately.

On Linux, check with ethtool that the wake setting includes g for magic packet, and make it persist across reboots, because many distributions reset it. On macOS, the setting is "Wake for network access" in Energy Saver or Battery settings.

Power settings that undo it

Some systems cut power to PCIe devices entirely in deeper sleep states, which stops the card listening. If waking from sleep works and waking from shutdown does not, this is usually why, and the BIOS often has a separate option for exactly that case.

The Windows Fast Startup trap

This one deserves its own section because it breaks Wake-on-LAN completely while looking like nothing is wrong.

Windows Fast Startup does not really shut the machine down. It logs you out and then hibernates the kernel, so the next boot is quicker. As part of that process it powers the network adapter down fully, which means the card is not listening and no magic packet will ever reach it.

The signature is unmistakable once you know it: waking from sleep works, waking after a shutdown never does.

Turning Fast Startup off (Control Panel, Power Options, "Choose what the power buttons do", then uncheck "Turn on fast startup") costs a few seconds of boot time and makes Wake-on-LAN work from a powered off state. On most machines with an SSD the difference is barely noticeable.

Network conditions that silently block it

Wi-Fi

Wake-on-Wireless-LAN exists but support is patchy, and many laptops power the wireless card down completely when they sleep. If the target is on Wi-Fi and nothing you try works, that is very likely the reason. Wake-on-LAN is fundamentally a wired feature.

Different subnets or VLANs

Broadcasts do not cross a router. If your phone is on a guest network or a separate VLAN, the packet reaches your phone's segment and stops there. Some routers can forward directed broadcasts between VLANs, but it is off by default and often not available at all on consumer gear.

Managed switches

Some switches with energy saving features power down ports that have been idle. A port that has gone quiet may not deliver the broadcast to the sleeping machine at all.

The machine never had a DHCP lease

Less about waking and more about what happens after. If it wakes but you cannot reach it, check whether it got an address. Run a LAN Scan thirty seconds after sending the packet: if a new device appeared, the wake worked and your problem is now something else entirely.

Waking a machine over the internet

This is much harder than it sounds and the naive approach almost never works.

Forwarding UDP port 9 to a subnet broadcast address is the obvious idea, and most routers refuse to do it, because forwarding directed broadcasts from the internet is a well known amplification attack vector. Some firmware allows it, most does not.

Three approaches that do work:

• Use an always on device inside the network. A Raspberry Pi, a NAS, a smart home hub or a router with a Wake-on-LAN feature built in. You connect to that, and it sends the magic packet locally. This is the most reliable option by a wide margin.
• Use a VPN into your own network. Once you are on the LAN, it is an ordinary local wake. Most modern routers can run a VPN server, and this solves several other remote access problems at once.
• Configure a static ARP entry on the router. Map the sleeping machine's IP to its MAC permanently, then forward the port to that IP. The router delivers it without needing a lookup. This requires router firmware that supports static ARP entries, which usually means something running OpenWrt or a business grade device.

Whichever you choose, remember that your home IP address probably changes, so you also need dynamic DNS or a service that handles it.

The full checklist

1. Confirm the MAC address, specifically the wired one

   Not Wi-Fi, not Bluetooth, not a virtual adapter. Check it on the machine itself while it is awake.

2. Send to the subnet broadcast address, not the host IP

   192.168.1.255 for a typical /24. Use a subnet calculator if your network is anything else.

3. Enable it in the BIOS or UEFI

   Including the separate option for waking from a full shutdown if there is one.

4. Enable it in the operating system

   Both the "allow this device to wake" box and the magic packet option, plus any adapter specific entries on the Advanced tab.

5. Turn off Windows Fast Startup

   If sleep wakes and shutdown does not, this is almost certainly the answer.

6. Use a wired connection

   Wireless waking is unreliable and often simply unsupported.

7. Send from the same subnet

   Not from a guest network, not from a different VLAN, not over the internet without one of the approaches above.

8. Verify with a scan rather than by guessing

   Send the packet, wait thirty seconds, then scan the subnet. Either a new device appeared or it did not, and now you know which prerequisite to revisit.

The short version

The magic packet is matched by MAC address on a network card that has no IP, which is why it has to arrive as a broadcast. Send it to the subnet broadcast address rather than the machine's old IP, use the wired adapter's MAC, enable the feature in both the BIOS and the operating system, and turn off Windows Fast Startup if waking from shutdown never works. Over the internet, put an always on device or a VPN inside the network and wake locally from there.