“No internet” is a symptom shared by many unrelated failures. The fastest diagnosis checks the chain in order: client link, address configuration, default gateway, DNS, router WAN, modem/ONT state, provider path and the remote service. A test should tell you which layer still works.
Use scope as evidence
One device failing is different from every wired and wireless device failing. One website failing is different from every public IP being unreachable. Public IP reachability with broken domain names points toward DNS; a 169.254 address points toward local IPv4 configuration; a healthy gateway with a dead WAN points upstream.
Avoid destructive first steps
A factory reset can erase exactly the settings needed to restore service. Reboot only when it can answer a question, and reset only when documentation or clear evidence makes it necessary. Capture configuration and provider requirements first.
Diagnostic guides
- Ethernet Connected but No Internet: Diagnose the Failure Layer by Layer
- One Device Cannot Connect to Wi-Fi While Everything Else Works
- Wi-Fi Works Near the Router but Becomes Slow or Unstable in Another Room
- 2.4 GHz Wi-Fi Works but 5 GHz Does Not: What to Check
- Router Admin Page Opens but the Username or Password Is Rejected
- Router Reboots Randomly: Power, Heat, Firmware, Load, or ISP?
- Why 169.254.x.x Appears: IPv4 Link-Local (APIPA) Explained?
- CGNAT and 100.64.0.0/10 Explained: Why Port Forwarding May Stop at the ISP
- ARP Explained: How IPv4 Devices Find the MAC Address Behind a Local IP
- MTU and MSS Explained: Why Some Sites Work While Large Transfers Fail
- NAT Loopback (Hairpin NAT) Explained for Home Servers
- IPv6 Link-Local Addresses (fe80::/10) Explained
Five observations that narrow most outages
Write down the client IP, default gateway, whether the gateway responds, whether a public IP is reachable, and whether a domain name resolves. Add the router WAN state and modem/ONT indicators. Those checks usually tell you whether to stay on the client/LAN or move upstream to the provider.
Preserve evidence before rebooting recurring faults
A reboot can restore service while erasing logs, session state, or timing clues. For intermittent problems, capture status first so the next outage can be compared instead of treated as a brand-new mystery.