What Does a 169.254 IP Address Mean?

A 169.254.x.x IP address means your device could not get a valid address from a DHCP server and assigned itself a fallback address, a mechanism called APIPA (Automatic Private IP Addressing). With a 169.254 address, your device has no internet access and cannot communicate with other subnets; it is isolated to the local physical segment. The fix in most cases is restarting your router, then releasing and renewing the IP lease on the affected device.

What the 169.254.0.0/16 Range Actually Is

The 169.254.0.0/16 block is officially defined as link-local address space in RFC 3927. Microsoft's implementation is branded APIPA. When any modern operating system — Windows, macOS, Linux, iOS, or Android — cannot get a DHCP response within its timeout period (typically a few seconds), it picks a random address in the 169.254.1.0 to 169.254.254.255 range and broadcasts an ARP probe to verify nothing else on the segment is using it before claiming it.

This range is non-routable by design. No router forwards a packet with a 169.254.x.x source or destination address. It is a last-resort mechanism that gives the appearance of a working network adapter while providing almost no usable connectivity. Two devices on the same physical segment that both hold 169.254 addresses can ping each other, but that is the extent of it — no gateway, no DNS, no internet.

Root Causes, Ranked by Frequency

Knowing which cause is most common saves significant time. In rough order of how often they appear in practice:

1. Router DHCP service crashed or is temporarily overloaded. Responsible for the majority of APIPA incidents. A power cycle of the router resolves this instantly in most cases.
2. DHCP pool exhausted. Routers ship with a default pool that often caps at 50 to 100 simultaneous leases. Dense households with many IoT devices, shared office networks, or apartment buildings can hit this ceiling. New devices get no offer and fall back to APIPA.
3. Physical layer problem — bad cable, wrong port, marginal Wi-Fi signal. If the device cannot form a reliable layer-2 link, DHCP Discover packets never reach the router. The adapter shows as connected but receives no response.
4. DHCP disabled on the router. Happens silently after a factory reset, firmware update, or manual misconfiguration. Easy to miss because the router otherwise appears healthy.
5. Two DHCP servers running on the same segment. Adding a second router or access point with DHCP enabled creates a conflict. Devices may receive responses from the wrong server or get no usable offer at all.
6. Network adapter driver problem or stale adapter state. Less common, but after OS updates or hardware changes the adapter may not send DHCP Discover packets correctly. A driver update or adapter reset resolves it.
7. VPN or endpoint security software blocking DHCP traffic. Some corporate endpoint protection tools or VPN clients intercept DHCP broadcasts on the local adapter.

Diagnosing Which Cause You Have

Before touching any settings, run the appropriate command to check your full adapter state. This takes under a minute and shows exactly where the break is.

Windows

Find the adapter showing 169.254.x.x and check these four fields:

• DHCP Enabled: must say Yes. If it says No, the adapter has a manual static IP that is not working — switch it back to DHCP in the adapter properties.
• Autoconfiguration IPv4 Address: Windows labels APIPA addresses this way rather than the usual IPv4 Address label, confirming DHCP tried and failed rather than being disabled.
• Default Gateway: blank or 0.0.0.0 when APIPA is active, because no DHCP offer arrived to provide one.
• DNS Servers: also blank or 0.0.0.0 for the same reason — DNS server addresses are delivered by DHCP.

macOS

A 169.254 IP with a blank router line confirms DHCP failure. You can also check visually at System Settings → Wi-Fi → Details → TCP/IP: if Configure IPv4 reads Using DHCP but the shown address starts with 169.254, the DHCP server is not responding.

Linux

A 169.254 address appears on the interface with scope link. The routing table will have no default route, and resolvectl status will list no DNS servers — both are normally delivered by DHCP. For the exact failure message, check logs with journalctl -u NetworkManager.

iOS and Android

On iOS: Settings → Wi-Fi → tap the (i) next to your network → IP Address. On Android the path varies by manufacturer skin: stock Android and Samsung One UI show the IP under Settings → Wi-Fi → tap and hold the SSID → Manage network settings → IP address; on MIUI try Settings → Wi-Fi → tap the SSID → IP address. If you see 169.254.x.x on any mobile platform, the router is the problem — fix steps are the same regardless of device.

Step-by-Step Fixes

Fix 1: Restart the Router

1. Unplug the power cable from the router. Do not use the reset pinhole button — that restores factory defaults on most models.
2. Wait 30 full seconds. This allows in-memory DHCP lease tables to clear on models that do not persist them to flash storage.
3. Plug back in. Wait 60 to 90 seconds for the router to fully initialize before testing.
4. Disconnect and reconnect the affected device from the network.

If two or more devices show 169.254 addresses and all recover after this, a DHCP crash or pool exhaustion was the cause. See Fix 6 to prevent recurrence.

Fix 2: Release and Renew on Windows

Open Command Prompt as Administrator by right-clicking the Start button and selecting Terminal (Admin) or Command Prompt (Admin):

The /release command sends a DHCPRELEASE packet, surrendering the stale lease. The /renew broadcasts a fresh DHCPDISCOVER. If /renew times out or returns a message about being unable to contact the DHCP server, the router is still unreachable — restart the router first, then re-run /renew.

Fix 3: Renew on macOS

1. Open System Settings → Network → Wi-Fi → Details → TCP/IP.
2. Click Renew DHCP Lease.

From Terminal:

Replace en0 with your actual interface name. Run ifconfig to list all interfaces — on most Macs, en0 is Wi-Fi and en1 or en2 may be Ethernet via a USB adapter.

Fix 4: Renew on Linux

With NetworkManager (most desktop distributions):

With systemd-networkd:

To force a new DHCP request on a specific interface using dhclient directly:

Fix 5: Forget and Rejoin the Wi-Fi Network

On wireless connections, a stale saved network profile can hold bad state. Forgetting the network forces a clean reconnect:

• Windows: Settings → Network and Internet → Wi-Fi → Manage known networks → select the SSID → Forget.
• macOS: System Settings → Wi-Fi → click (i) next to the SSID → Forget This Network.
• iOS: Settings → Wi-Fi → tap (i) → Forget This Network.
• Android: Settings → Wi-Fi → tap and hold the SSID → Forget network.

Rejoin by selecting the network and re-entering the passphrase. The device will attempt a fresh DHCP negotiation from scratch.

Fix 6: Check and Expand the DHCP Pool on Your Router

If the problem reoccurs or affects multiple devices at once, log in to your router admin panel. First, find your actual gateway address — do not guess it. Run ipconfig /all on Windows or netstat -nr | grep default on macOS and read the Default Gateway value. Common values include 192.168.0.1, 192.168.1.1, 10.0.0.1, and 192.168.2.1, but your network may use a different address entirely.

DHCP pool settings appear in different menu paths depending on your router firmware:

• TP-Link Archer (tplinkwifi.net): Advanced → Network → DHCP Server → Address Pool. Extend the ending address to allow more simultaneous leases.
• Netgear (routerlogin.net): Advanced → Setup → LAN Setup → Address Pool. Adjust the ending IP upward.
• Asus (asusrouter.com): LAN → DHCP Server → IP Pool Starting Address and Ending Address.
• Linksys (linksyssmartwifi.com): Local Network → DHCP Server → Maximum Number of DHCP Users.
• Xiaomi (miwifi.com): Settings → LAN Settings → DHCP. Menu labels vary across MiWiFi firmware versions — look for an address range or max clients setting.
• Netgear Orbi (orbilogin.com): Advanced → Setup → LAN Setup → Address Pool.
• OpenWrt: Network → Interfaces → LAN → Edit → DHCP Server → Advanced Settings → Limit (maximum leases).
• DD-WRT: Setup → Network Address Server Settings (DHCP) → Maximum DHCP Users.

Also check the lease time while you are there. If it is set to 7 days or longer, devices that left the network long ago are still holding pool slots. Reducing it to 24 hours lets stale leases expire faster without impacting connected clients.

Fix 7: Check the Physical Connection

On Ethernet: swap the cable (a cable that passes a link-light test can still drop the small UDP packets DHCP uses), try a different port on the switch or router, and confirm the port LED lights solid or blinks. On Wi-Fi: move closer to the router. A weak signal can silently drop packets during the four-step DHCP handshake (Discover, Offer, Request, Acknowledge) while still showing the device as associated.

Fix 8: Reset the Network Stack on Windows

If only one Windows device is affected and all other fixes have failed, a full network stack reset clears driver-level issues without touching saved passwords or other settings:

Restart the computer after running these commands. This resets the Winsock catalog and TCP/IP stack to defaults.

Confirming the Fix Worked

After any fix, verify you have a valid private IP address — it should start with 10.x, 172.16 through 172.31.x, or 192.168.x.x. Then test connectivity layer by layer:

If ping 8.8.8.8 succeeds but nslookup google.com fails, you have routing but DNS is still broken. This usually means the DHCP renew did not correctly restore the DNS server assignment. As a temporary fix, manually set DNS to 8.8.8.8 or 1.1.1.1 in your adapter settings, then investigate why your router is not distributing DNS server addresses via DHCP.

Common Misdiagnoses

169.254.x.x is not a working private IP address. Seeing it listed alongside 10.x or 192.168.x addresses leads some users to assume it is a normal local address. It is not — it is a failure indicator. A device with only a 169.254 address cannot reach the internet or any other subnet.

Blaming the device when the router is the problem. If two or more devices on the same network simultaneously show 169.254 addresses, the router's DHCP service is almost certainly the common cause. Do not reinstall drivers or reset individual devices until you have confirmed the router is actually distributing leases to other clients.

Confusing CGNAT with APIPA. If your router's WAN IP starts anywhere from 100.64 through 100.127, that is CGNAT space (100.64.0.0/10) assigned by your ISP — normal behavior that does not indicate a local problem. The 169.254 range only appears on client LAN adapters, never on WAN interfaces.

Assuming the ISP is at fault. APIPA happens entirely before any traffic reaches your ISP. If a device shows 169.254.x.x, the problem is entirely local — your router or the physical connection between the device and the router.

Preventing Recurrence

• Update router firmware regularly. DHCP stability fixes appear in firmware releases. Check your router admin panel or the manufacturer support site every few months.
• Monitor DHCP pool utilization. Log in occasionally and compare active lease count against total pool size. Expand the pool before it fills — there is no cost to widening the address range within the same subnet.
• Use DHCP reservations instead of static IPs on devices. For printers, NAS units, or smart-home hubs that need a predictable address, create a MAC-address reservation in the router. The device still uses DHCP, the slot is always available for that device, and IP conflicts are eliminated.
• Set shorter lease times on guest or IoT networks. A 2 to 4 hour lease time on high-turnover segments keeps the pool recycling without impacting normal clients.
• Ensure only one DHCP server runs per segment. If you add a second router as a wired access point, disable its DHCP server. Only the main router should distribute addresses on a given subnet.

IPv6, DoH, and 2026 Context

Most networks in 2026 run dual-stack (IPv4 and IPv6). Even when IPv4 DHCP fails and a device lands on a 169.254 address, it may still receive an IPv6 link-local address (fe80::/10) automatically — those are always self-assigned and require no DHCP server. Without a global unicast IPv6 address from SLAAC (Router Advertisement) or DHCPv6, the device still cannot reach the internet via IPv6 either. Run ipconfig /all on Windows or ip addr show on Linux and macOS to see both stacks at once and confirm which is healthy.

One edge case to watch for: if your router provides IPv6 via SLAAC but IPv4 DHCP is broken, a browser may appear to load IPv6-capable sites while IPv4-only services fail silently. This produces confusing intermittent connectivity. Always confirm a valid IPv4 address is present before concluding the network is fully healthy.

DNS-over-HTTPS and DNS-over-TLS have no bearing on APIPA. Both protocols require a working IP address and functional routing to operate at all. Fix the IP address first; encrypted DNS resolves automatically once DHCP is working correctly.