An Ethernet icon that says “connected” proves surprisingly little. It usually means the network interface has negotiated a physical link with a switch, router, dock, or wall jack. Internet access still depends on several higher layers: the device needs a usable IP configuration, a route to a gateway, working name resolution, and an upstream path that can actually reach the internet. Treating all of those as one problem leads to random reboots and needless factory resets.
A concrete example
Suppose a PC receives 192.168.1.74/24 with gateway 192.168.1.1. The gateway opens normally, but a public IP does not respond and every other device is also offline. That evidence largely clears the PC, cable, DHCP, and LAN routing. Attention should move to the router WAN, modem/ONT, provider outage, PPPoE/DHCP state, or upstream line rather than the browser.
What the symptom really tells you
The fastest method is to prove one layer at a time. Start with link speed and addressing, then test the local gateway by IP, then a known public IP, and only after that test DNS names. A failure that begins before the gateway points inward toward the LAN. A gateway that responds while public IPs fail points toward WAN routing, modem/ONT state, authentication, or the provider. Public IPs working while names fail is usually a resolver problem rather than an Ethernet problem.
Diagnose before you change settings
Troubleshooting is most reliable when each test removes a group of possible causes. Keep the scope of the failure in view: one client, one radio band, one room, the whole LAN, or the upstream internet connection. Record what changed and what stayed healthy. That approach is slower than guessing for the first thirty seconds and dramatically faster than recovering from unnecessary resets, random DNS changes, or security downgrades.
Deeper technical context
A managed switch or ISP gateway can make this problem less obvious. A port may belong to the wrong VLAN, a docking station may negotiate at an unexpected speed, or a router may hand out an address from one subnet while the intended gateway lives on another. IPv6 can also make a broken IPv4 path look partially functional because some destinations continue to work. For stubborn cases, record the IPv4 address, mask, gateway, DNS servers, IPv6 status, and the result of each test instead of changing several settings at once. That creates a small fault tree you can actually reason from.
A useful diagnostic sequence
- Check the negotiated Ethernet speed and whether the interface shows an address, subnet/prefix, default gateway, and DNS servers.
- If the address begins with 169.254 on IPv4, treat DHCP as the first suspect; renew the lease and test a different cable or LAN port before changing router settings.
- Ping or open the default gateway. If the gateway is unreachable, compare the device subnet with the gateway subnet and check VLAN, switch, dock, and cabling assumptions.
- If the gateway works, test a public IP such as a resolver address. Success here proves basic routing even if websites still fail by name.
- Test DNS separately. Compare automatic DNS with a known resolver only as a diagnostic step; do not permanently change DNS until you know why the supplied resolver failed.
- Check another device on the same Ethernet path. One-device failures and whole-network failures have very different likely causes.
What the evidence should tell you
Each test should narrow the fault domain. Do not treat a successful step as “nothing found”; it is evidence that the layers it exercised are probably healthy.
- Check the negotiated Ethernet speed and whether the interface shows an address, subnet/prefix, default gateway, and DNS servers. If this succeeds, move outward to the next layer.
- If the address begins with 169.254 on IPv4, treat DHCP as the first suspect; renew the lease and test a different cable or LAN port before changing router settings. If this fails, stay at this layer until the reason is understood.
- Ping or open the default gateway. If the gateway is unreachable, compare the device subnet with the gateway subnet and check VLAN, switch, dock, and cabling assumptions. Compare the result with a known-good client or path before changing global settings.
- If the gateway works, test a public IP such as a resolver address. Success here proves basic routing even if websites still fail by name. If this succeeds, move outward to the next layer.
- Test DNS separately. Compare automatic DNS with a known resolver only as a diagnostic step; do not permanently change DNS until you know why the supplied resolver failed. If this fails, stay at this layer until the reason is understood.
- Check another device on the same Ethernet path. One-device failures and whole-network failures have very different likely causes. Compare the result with a known-good client or path before changing global settings.
How to verify your conclusion
Do not stop at the first result that seems to confirm your theory. Repeat the decisive test after the change, compare it with a known-good client or path, and check that unrelated functions still work. For router changes, verify local management access, DHCP addressing, default gateway, DNS resolution, internet reachability and the specific feature you intended to fix. Keep the old setting in your notes until the network has remained stable long enough to trust the new state.
Security and recovery notes
Use these steps only on networks and devices you own or are authorized to administer. Never weaken authentication, expose a management interface to the public internet, or publish router credentials merely to make troubleshooting easier. A normal reboot is very different from a factory reset: rebooting preserves configuration, while a reset can erase ISP, Wi-Fi, VPN, reservation, forwarding and segmentation settings. Prefer the least destructive test that can answer the question.
Common mistakes that create bad conclusions
- Assuming a green link light means the internet must be working.
- Factory-resetting the router before checking whether only one Ethernet client is affected.
- Changing DNS when the device cannot even reach its default gateway.
- Testing only websites, which mixes routing, DNS, TLS, and browser behavior into one ambiguous result.
When to escalate the problem
Escalate only after you can describe the boundary clearly. For an ISP case, record whether wired and wireless clients fail, whether the router can reach its gateway/upstream service, modem or ONT status, timestamps, and whether the public connection recovers without local changes. For a device-vendor case, record the exact model, hardware revision, firmware, client operating system, and the shortest sequence that reproduces the failure. Better evidence usually produces better support than a list of settings that were changed at random.
Questions people usually ask
Why does Ethernet say connected without internet?
Because link negotiation is only the first layer. Addressing, gateway routing, DNS, WAN service, and the provider must all work after the cable link is established.
Should I reset the router?
Not as a first step. A reset erases configuration and can create more work. Use a reboot only after basic tests, and reserve a factory reset for a documented recovery case.
Can bad DNS make Ethernet look offline?
Yes. If public IP addresses work but domain names do not, routing may be fine while DNS resolution is failing.
What does 169.254.x.x mean?
It usually means the device self-assigned an IPv4 link-local address because it did not obtain a normal DHCP lease.
Standards and primary references
The explanation above is original editorial content. These references are linked for the underlying protocol or standards context, not as text to copy.
Bottom line
The useful outcome is not merely knowing the term or completing a setting change; it is being able to explain why the network behaved that way and reproduce the result safely. If the evidence points to a different layer than the one discussed here, follow the evidence rather than forcing the original theory.