Fix DHCP Unreachable: 169.254 IP Addresses Explained

You're sitting at a client's desk, and their PC shows a network connection – but nothing loads. You open a command prompt and type ipconfig. There it is: Autoconfiguration IPv4 Address: 169.254.82.101. That's the Windows Automatic Private IP Addressing (APIPA) fallback. It means the machine shouted for a DHCP server and got silence.

I've seen this in a hundred offices. Last month, a dental clinic's entire front desk lost internet because their ISP router rebooted and came back with DHCP disabled. Another time, a warehouse had a switch loop that flooded the network so bad that DHCP requests never made it to the server. The trigger is always the same: clients boot up or renew, no DHCP offer comes back, and Windows gives up.

Why You're Seeing APIPA

DHCP runs on UDP ports 67 and 68. The client broadcasts a DHCPDISCOVER. The server responds with an offer. If that handshake never happens, you get a 169.254.x.x address. Root causes break down into three buckets:

Server-side: The DHCP service is stopped, the server's network is down, or the scope is exhausted (no more IPs).
Network-side: VLANs misconfigured, a rogue firewall rule blocking UDP 67/68, or a switch port is in the wrong VLAN.
Client-side: A dead NIC driver, a dirty cable, or the client firewall is blocking its own DHCP requests (rare but happens).

Don't overthink it. Start with the simplest check, then work up.

The Fix: Step-by-Step

Renew the lease manually. On the affected PC, open Command Prompt as admin and run:
```
ipconfig /release
ipconfig /renew
```
Watch the output. If it still comes back with 169.254, move on.
Check the DHCP server itself. Log into your DHCP server (could be a Windows Server, a router, or a firewall). Open the DHCP console or admin page. Look at the scope: are there available addresses? Is the service running? On Windows Server, run:
```
Get-Service DhcpServer
```
If it's stopped, start it and set it to Automatic.
Test from a second device. Plug a laptop into the same switch port. If the laptop gets a proper IP, the problem is the original PC's NIC. If it also gets 169.254, the network path is broken.
Check for rogue DHCP servers. If you have multiple devices handing out IPs (like a home router plugged into the office network), they can conflict. Use ipconfig /all on a working client to see which server gave the lease. If it's not your intended server, unplug the rogue device.
Verify VLANs and trunk ports. If your switches use VLANs, make sure the port the client is on belongs to the same VLAN as the DHCP server. A quick way: on a managed switch, check the port's PVID and untagged VLAN settings.
Flush the DNS and reset the network stack. On the client, run these:
```
ipconfig /flushdns
netsh int ip reset
netsh winsock reset
```
Reboot. This fixes weird stale states that sometimes block DHCP.
Update the NIC driver. Outdated drivers can cause DHCP to fail intermittently. Go to Device Manager, right-click the network adapter, and choose Update driver. If the driver is old, download the latest from the OEM's site.

Still Not Working? Check These.

Sometimes the obvious steps don't cut it. Here's what I dig into next:

Firewall rules: On both the DHCP server and the client, make sure UDP 67 and 68 are allowed. Windows Firewall usually has a built-in rule, but third-party antivirus can block them. Temporarily disable the firewall on the server to test, but don't leave it off.
Switch port security. I've seen ports with MAC address lockdown that silently drop DHCP broadcasts. Check the switch's port security settings.
DHCP relay issues. If your DHCP server is on a different subnet, you need a relay agent (often the router). Make sure it's configured to forward broadcasts to the server's IP. If the relay is broken, clients on that subnet get nothing.
Scope exhaustion. Log into the DHCP console and look at the Address Leases. If the scope is 100% used, you'll need to expand it or clean up stale leases. Right-click the scope, go to Properties, and increase the end IP or reduce the lease time to free up addresses.
Check the server's event log. On Windows Server, filter the System log for DHCP events. You'll see errors like "DHCP server service is shutting down" or "No free addresses." That tells you exactly what to fix.

One last thing: if you're in a hurry and need clients online now, you can set a static IP temporarily. But that's a band-aid. DHCP is the right way to run a network, and chasing down the real cause beats fighting static IP conflicts later. I've been called back to offices that 'solved' the DHCP problem with static IPs only to find duplicate address hell a week later.

So run through the steps, test after each one, and you'll have that 169.254 address gone in no time.