Writing

APIPA and 169.254

Published 22 September 2026

A 169.254 IP address is not a configuration you can correct. It is a symptom. The machine asked for an address, nothing answered, and it gave up and named itself. Every minute spent trying to change that address is a minute not spent on the thing that actually broke.

What it is

APIPA (Automatic Private IP Addressing) is the fallback a host uses when DHCP produces nothing. It picks a random address from 169.254.0.0/16, checks with ARP that nobody else has it, and assigns it to itself. The behaviour is standardised as IPv4 link-local addressing in RFC 3927; APIPA is Microsoft's name for it, and macOS calls the same thing a self assigned IP.

It is designed for one narrow case: two machines plugged together with no DHCP server, wanting to talk. In that case it works. In every other case it is a failure notice.

Why you cannot fix the address

The instinct is to set a static IP and move on. That does sometimes restore connectivity, and it also buries the fault: you now have a machine with a hand-typed address on a network that hands them out, which will collide with something eventually or break the next time the subnet changes.

The address is the result. The question is why the DHCP request went unanswered.

What to check, in order

1. Is the link actually up? A host with no carrier cannot reach a DHCP server. A dead cable, a disabled switchport or a wireless association that never completed all produce 169.254, and they are the most common causes by a distance.
2. Does anything else on that segment have an address? One machine with 169.254 is that machine. Everything on the segment with 169.254 is the DHCP server or the path to it.
3. Is the DHCP server running and in scope? A pool that has run out hands back nothing at all, which looks identical to a server that is down.
4. Is there a relay in the path? DHCP discovery is a broadcast, and broadcasts do not cross a router. On a routed network the switch or router needs an ip helper-address pointing at the server. When a new VLAN "has no DHCP", this is almost always why.
5. Is something else answering first? A rogue DHCP server (often somebody's home router plugged in the wrong way round) can hand out addresses on a subnet that cannot route anywhere. That produces a working-looking address rather than 169.254, so if some machines get a wrong address and others get none, suspect this.

The check that takes ten seconds

Ask for a lease again and watch what happens, rather than reading the address and guessing:

# Windows
ipconfig /release && ipconfig /renew

# macOS: renew the lease for the active interface
sudo ipconfig set en0 DHCP

# Linux
sudo dhclient -v eth0

The verbose Linux form is the most useful of the three: it prints each DHCPDISCOVER and shows whether any OFFER comes back. No offer means nothing is listening or nothing is relaying, which is a completely different problem from an offer that is refused.

169.254.169.254 is not APIPA

This one catches people out, because the address sits squarely inside the APIPA range and means something entirely unrelated. 169.254.169.254 is the cloud instance metadata endpoint: AWS, Azure and Google Cloud all use it. A virtual machine queries it to learn its own configuration and credentials.

So seeing it in a log or a config is normal on a cloud instance and is not a DHCP failure. It is also why that address turns up in security advice: anything that fetches a URL on a server's behalf must be prevented from reaching it, or it becomes a route to the instance's credentials. That is exactly the defence built into the HTTP status checker and the port checker here: every resolved address is judged before a connection is opened, on every redirect hop.

Related addresses worth recognising

If it is only one machine

Check the obvious before the interesting: cable, port, wireless credentials. A machine that has just woken from sleep sometimes holds a stale link state and recovers on a disable and re-enable of the adapter.

If the address is correct but nothing resolves, that is a different fault entirely: see the flush DNS command for what a stale resolver looks like, and no route to host for telling a routing failure from a refused connection.