A 169.254 IPv4 address is a link-local address, not a normal public internet address. On a Windows Ethernet connection where you expected router-supplied configuration, it is a reason to inspect the address-assignment situation before changing DNS servers. It is not proof, on its own, that your ISP is down or that the cable is faulty.
The key is context. Some links intentionally use local addressing. A computer may also have several interfaces with different addresses. Start by identifying the Ethernet interface that belongs to the problem rather than treating every 169.254 entry as an error.
Understand the scope of the address
RFC 3927 defines automatic IPv4 link-local configuration in the 169.254/16 range for communication on a local link. It is not a substitute for ordinary routed address configuration. This limited role explains why seeing an address does not necessarily mean the computer has the internet connection you expected.
Do not turn the range into a diagnosis of a particular device. An addressing result tells you something about configuration state. It does not identify every step that led there, and it does not say that a different active interface cannot reach the internet.
Collect the current configuration
Microsoft’s ipconfig reference documents displaying adapter addresses, subnet masks and gateways, with fuller configuration through ipconfig /all. Open Command Prompt and inspect the output:
ipconfig /allFind the relevant Ethernet adapter’s section. Record its description, IPv4 address, subnet mask, gateway and whether DHCP is enabled, keeping each value attached to that adapter. Do not publish the complete output unnecessarily; it contains address and device information beyond the single issue.
If the interface is disconnected or clearly belongs to a virtual device, record that before interpreting the address. If you cannot match the section to the physical adapter, resolve that identity question first. Mixing Wi-Fi’s gateway with Ethernet’s address creates a configuration that never actually existed.
Ask what configuration was expected
On a typical home network, you may expect the router to provide settings automatically. Confirm that expectation rather than copying it into every environment. A work, lab or direct device connection may have a different design that an administrator needs to explain.
Do not copy a neighbour’s address or invent a static gateway to make the numbers look familiar. Duplicate or incompatible settings can create a new problem. Changing DNS cannot, by itself, supply a missing address or route. The DNS explanation helps separate name resolution from the earlier connection requirements.
Use a controlled physical-network comparison
- Record the computer, adapter, cable, port and intended network. Note whether a dock or switch is involved.
- Check the physical arrangement and the device’s normal connection indicators without assuming a lit indicator proves full functionality.
- If practical, compare one known supported port or cable while keeping the rest of the setup unchanged.
- Read the same adapter’s configuration again. Note whether the address state changes and whether the intended network becomes usable.
- If another device can use the same network, record its success without copying its unique address settings.
This is an addressing investigation before a performance investigation. There is no benefit in repeatedly running an internet speed test while the relevant connection has no usable internet path. A failed test at that stage is not a measured speed of zero.
Renewal is not the same as guessing settings
The Microsoft reference also documents renewal for DHCP-configured interfaces. If automatic configuration is expected and you are authorised to manage the connection, follow the supported renewal procedure for the correct adapter. Be aware that connection-management commands can interrupt access; use an available recovery path.
Do not paste a long bundle of release, reset and registry commands as the first response. Keep the initial output so that any later state can be compared. If a managed network requires authentication or a specific setup, the administrator’s procedure takes precedence over a generic home-network example.
Move forward only when the state is clear
If the address becomes the expected configuration but internet access still fails, that is a new checkpoint, not evidence that the earlier observation was meaningless. Compare the intended gateway, ordinary services and the original task. The connected-without-internet guide addresses the wider symptom.
If Ethernet works but remains slow, the slow Ethernet guide follows the next question. Keep recognition, address assignment, access and throughput as separate observations so that a fix at one stage is not mistaken for proof of every other stage.
If Wi-Fi remains active during the investigation, explicitly record that too. A website opening through another available connection does not demonstrate that the Ethernet configuration you are inspecting became usable.
For support, supply the adapter identity, expected network design, relevant configuration fields and the outcome of one controlled comparison. State whether other interfaces or devices can connect. That gives the recipient a concrete address-assignment question instead of an unsupported conclusion about an outage or a defective cable.