Link-local addressing

169.254.0.0/16 is IPv4 link-local address space. Many clients can select such an address when usable DHCP configuration is unavailable. It is not a public internet address. Rather than diagnosing a precise failure from the prefix alone, inspect how the connection was configured.

Initial checks

Verify that the cable or Wi-Fi connection is active. Check whether other devices on the same network obtain normal addresses. If only one fails, inspect its client settings; if all fail, investigate the router and DHCP service. An unintended second DHCP server can also cause inconsistent settings.

Avoid arbitrary static addresses

Manually entering an address might temporarily reach some local resources while hiding the underlying fault. You need to know the correct subnet, gateway, and an unused address. First determine why automatic configuration failed. Receiving no public geolocation for this address is expected behavior.

One client or the whole network?

If a laptop has a 169.254 address while a phone on the same Wi-Fi works, begin with the laptop’s configuration. If all clients show the symptom, investigate DHCP and access-point connectivity. Do not copy the working device’s address onto the failing one, as that creates a conflict. Change and test one variable at a time.

Further reading

IPv4 link-local addressing — RFC 3927 ↗

Put it into practice

Inspect one public IP, or compare a list of addresses with the bulk lookup tool. Location results are approximate.

Single lookup ↗ Bulk lookup ↗