What a 169.254 IP address means

When a device joins a network it broadcasts a request for an address, and the router's DHCP server answers with one, typically something like 192.168.1.23, plus the router's own address and the DNS servers to use. If no answer arrives within the timeout, the device falls back to the procedure defined for link-local addressing: it picks a random address between 169.254.1.0 and 169.254.254.255, checks with ARP that nothing on the link already uses it, and starts using it.

That address is good for one thing: talking to other devices on the same physical link that are in the same situation, which is how two laptops joined by a cable can share files with no router at all. It is not good for the internet. The standard requires routers to drop any packet with a 169.254 source or destination, and the device has no gateway and no DNS server anyway. Hence the familiar symptom: Wi-Fi shows connected, the browser says there is no internet, and Windows reports Unidentified network or No internet access. macOS is blunter: Wi-Fi has the self-assigned IP address … and will not be able to connect to the Internet.

The device keeps asking for a real address in the background, so sometimes the problem fixes itself after a minute. When it does not, something between the device and the DHCP server is broken, and the possibilities are short:

• The router is not responding. It is rebooting, crashed, overloaded, or its DHCP server has been switched off (common after someone added a second router or a mesh system, leaving two DHCP servers or none).
• The request never reaches it. A bad cable, a dead switch port, a Wi-Fi link that associated but never fully authenticated, or a guest network with client isolation that blocks DHCP.
• The pool is full. The router has handed out every address in its range, which happens on networks with many devices and long lease times.
• Something on the device blocks DHCP. A VPN client, a security product, a misconfigured static setting or a half-installed driver.

IPv6 has the same idea built in: every interface gives itself a link-local fe80:: address from the start, without waiting for anyone. Seeing one of those is normal; seeing only one, with no other IPv6 address, means the router is not advertising IPv6, which the IPv6 test confirms.

Work from the cheapest fix to the most invasive. Most cases end at step 2 or 3.

1. Check whether it is just you. If a phone on the same Wi-Fi has internet, the router's DHCP works and the fault is on your device (skip to step 3). If nothing on the network has internet, it is the router.
2. Restart the router (and the modem if it is a separate box). Wait for the lights to settle, two minutes or so, then reconnect. This clears a hung DHCP service and empties an exhausted address pool.
3. Ask for a new lease.
   • Windows 11: right-click Start, open Terminal (Admin), run ipconfig /release then ipconfig /renew. The second command should print an address that does not start with 169.254.
   • macOS: System Settings > Wi-Fi (or Ethernet) > Details > TCP/IP > Renew DHCP Lease.
   • iPhone: Settings > Wi-Fi > (i) > Renew Lease. Android: forget the network and join it again.
4. Check the physical link. On Ethernet, try another cable and another port; a cable that lights the link LED can still drop packets. On Wi-Fi, forget the network and rejoin, typing the password again.
5. Make sure the device is not set to a static address. Windows: Settings > Network & internet > Wi-Fi (or Ethernet) > your network > IP assignment must say Automatic (DHCP). macOS: the TCP/IP tab's Configure IPv4 must say Using DHCP.
6. Reset the network stack if Windows keeps failing while other devices work: Settings > Network & internet > Advanced network settings > Network reset > Reset now. It reinstalls the adapters and reboots; you will need to re-enter Wi-Fi passwords and VPN settings.
7. Check the router's DHCP server. Log in to the router (the router IP guide shows how to find its address; it is usually 192.168.1.1), open the LAN or DHCP page, and confirm the server is enabled and the pool is large enough. If you run two routers, only one should serve DHCP.

Setting a static address by hand is a workaround, not a fix: it gets one device online while leaving the DHCP fault for every other device to hit. If you do it, pick an address outside the router's DHCP range, enter the router as the gateway and DNS, and remember to switch back to automatic later. Once the device has a proper address, the local IP tool shows it and CheckMyIP confirms you reach the internet.

One address in this range turns up constantly in server logs and security write-ups, and it has nothing to do with DHCP failures. 169.254.169.254 is the instance metadata service on every major cloud platform. A virtual machine on AWS, Google Cloud or Azure can send an HTTP request to that address and get back information about itself: its instance ID, region, network settings, startup script and, most importantly, temporary credentials for the cloud account's APIs.

The address was chosen precisely because it is link-local: it is reachable only from inside the VM, is never routed, and the request never leaves the physical host. Each platform has its own guard rails. AWS's IMDSv2 requires a session token obtained with a PUT request before any metadata is returned, and an instance can be set to accept nothing else; Azure requires a Metadata: true header and rejects requests carrying X-Forwarded-For; Google Cloud requires a Metadata-Flavor: Google header. Those guards exist because of server-side request forgery: a web application that can be tricked into fetching an arbitrary URL would otherwise hand an attacker the server's cloud credentials by fetching http://169.254.169.254/.

So if you see 169.254.169.254 in an application log, nobody's DHCP is broken. Either the software is legitimately asking its own cloud for metadata, or someone is probing your application to see whether it will fetch that URL for them.