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 working gateway with a failed upstream connection

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.

An Ethernet link is only the first checkpoint

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.

VLANs, docks and partial IPv6 connectivity

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.

Trace DHCP, gateway and WAN failures in order

  • 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.

Avoid confusing a link light with internet access

  • 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.

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.

Technical references