You run ipconfig on a Windows PC that can't reach anything, and the IPv4 address starts with 169.254. That address tells you something specific: the computer asked for an address, got no answer from a DHCP server, and gave itself one. The fix is almost always to find out why the DHCP exchange failed.
Where 169.254 addresses come from
The block 169.254.0.0/16 is registered for IPv4 link-local addressing, defined in RFC 3927. A host that has no other address picks one from 169.254.1.0 to 169.254.254.255; the first 256 and last 256 addresses in the block are reserved and never chosen. Before using its pick, the host sends ARP probes to make sure no other device on the link already has it.
Windows calls this Automatic Private IP Addressing, or APIPA. In ipconfig /all output it usually appears as an Autoconfiguration IPv4 Address rather than a plain IPv4 address, with a subnet mask of 255.255.0.0.
What a link-local address can reach
Devices on the same physical link can talk to each other with link-local addresses, which is the point: two machines plugged into the same switch with no DHCP server can still exchange traffic. But RFC 3927 says a router must not forward a packet with a link-local source or destination address. So a PC with a 169.254 address can't reach other subnets, the internet, or any server beyond its own link.
The address is temporary by design. As soon as the host gets a routable address, for example when a DHCP server finally answers, it uses that address for every new connection.
Why DHCP failed: the usual causes
A client with no lease broadcasts a DHCPDISCOVER message on its local subnet. A server replies with an offer, the client requests it, and the server acknowledges: discover, offer, request, acknowledge, often remembered as DORA. A 169.254 address means that exchange never finished. Work outward from the PC:
- No working link. A loose cable, a dead switch port, or a Wi-Fi adapter that never joined the network means the broadcast goes nowhere. Check the link light or the wireless connection first.
- The wrong network segment. A switch port assigned to the wrong VLAN puts the client on a subnet whose DHCP scope doesn't exist or isn't reachable.
- No relay to a remote server. Routers don't forward broadcasts. When the DHCP server sits on another subnet, the router interface facing the clients needs a DHCP relay agent (often configured as an IP helper address) to pass the DISCOVER along. A new VLAN without one is a classic cause.
- The server can't answer. The DHCP service is stopped, the scope for that subnet is out of addresses or not activated, or the server itself is down.
- Something blocks DHCP traffic. Clients send to UDP port 67 and servers reply to UDP port 68. A firewall rule or a switch security feature that drops those packets stops the exchange midway.
Checking it on Windows
ipconfig /all shows whether DHCP is enabled on the adapter and which address it has. After you fix the cause, ipconfig /release followed by ipconfig /renew asks for a new lease right away instead of waiting for the next retry. If the renew still fails, the problem is still somewhere between the PC and the DHCP server.
How to read it in a scenario
A 169.254 address points at DHCP, not at DNS or the gateway setting. A client with a wrong DNS server or a wrong default gateway still receives a normal lease; it just fails later, when it tries to resolve names or leave the subnet. If every client on one new segment shows 169.254 while other segments are fine, think relay or VLAN before you think server.
Private ranges such as 192.168.0.0/16 are a different thing from link-local addresses. Private IPv4 address ranges, explained.