“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 — A wired link can be electrically healthy while DHCP, routing, DNS, the WAN, or the upstream ISP is failing. Use this order to find the broken layer.
- One Device Cannot Connect to Wi-Fi While Everything Else Works — When one phone, laptop, TV, or console fails while other clients are healthy, focus on that client, its saved profile, security compatibility, and DHCP state before touching the whole network.
- Wi-Fi Works Near the Router but Becomes Slow or Unstable in Another Room — Distance problems are usually about signal quality, interference, building materials, placement, and client capability—not the speed printed on the router box.
- 2.4 GHz Wi-Fi Works but 5 GHz Does Not: What to Check — If one band works and another does not, examine client support, band steering, channel selection, DFS behavior, security mode, and radio settings before blaming the ISP.
- Router Admin Page Opens but the Username or Password Is Rejected — Reaching the login page proves the address is correct; rejected credentials are a separate authentication problem that should be solved without password guessing.
- Router Reboots Randomly: Power, Heat, Firmware, Load, or ISP? — Random restarts are different from Wi-Fi drops or WAN outages. Prove whether the router actually rebooted, then investigate power, temperature, firmware, hardware, and workload.
- Why 169.254.x.x Appears: IPv4 Link-Local (APIPA) Explained — A 169.254 address is usually a fallback local address selected when normal IPv4 configuration is unavailable. It is a clue about DHCP—not an internet gateway.
- CGNAT and 100.64.0.0/10 Explained: Why Port Forwarding May Stop at the ISP — Carrier-grade NAT lets providers share public IPv4 addresses across customers. It changes what “my router WAN IP” means and can block unsolicited inbound connections.
- ARP Explained: How IPv4 Devices Find the MAC Address Behind a Local IP — ARP maps an IPv4 address to a link-layer address on the local network. Understanding it explains duplicate-IP warnings, gateway reachability, and many “same subnet but cannot connect” problems.
- MTU and MSS Explained: Why Some Sites Work While Large Transfers Fail — Maximum Transmission Unit and TCP Maximum Segment Size affect packet sizing. Misconfiguration can create partial connectivity that looks like DNS, VPN, or firewall trouble.
- NAT Loopback (Hairpin NAT) Explained for Home Servers — Hairpin NAT lets a client inside your LAN reach an internally hosted service using the same public hostname or public IP that outside users use.
- IPv6 Link-Local Addresses (fe80::/10) Explained — IPv6 interfaces automatically use link-local addressing for essential neighbor and router discovery. Seeing fe80:: does not mean IPv6 is broken or globally reachable.
When device-specific instructions take priority
General networking concepts apply broadly, but router addresses, passwords, reset timing, firmware files, ISP provisioning, and app workflows can differ by exact model, hardware revision, region, and provider firmware. When a general guide and your device disagree, identify the exact unit and follow the instructions that match that hardware and current network role.
How to use this hub efficiently
Start with the symptom or decision you actually have. If the router page will not open, do not begin with Wi-Fi channel tuning. If one room is slow, do not begin with a factory reset. Move from the closest observable layer outward, make one relevant change at a time, and use the linked guides to narrow the problem without erasing useful evidence.
The minimum evidence set for an outage
Capture five things before resetting equipment: client IP, default gateway, whether the gateway responds, whether a known public IP is reachable, and whether DNS resolves a known domain. Add modem/ONT or cellular signal status and an ISP outage check. Those observations usually tell you whether the failure is local addressing, LAN routing, WAN reachability, DNS, or provider-side service.
Why “reboot everything” can hide the cause
A reboot may restore service but erase transient evidence. When the problem is recurring, record status and logs first so the next failure can be compared.
Build a repeatable troubleshooting baseline
Before the next failure, save a healthy-state snapshot: client IP and gateway, WAN status, DNS choice, firmware version and a simple wired/Wi-Fi speed and latency check. When something changes, compare against the baseline. This is much more useful than immediately rebooting or resetting every device.
Separate local access from internet access
A router admin page can work while the ISP is down, and the internet can work while a guest network blocks local administration. Treat these as different tests. That distinction is especially important on mesh systems, provider gateways and networks with more than one router.
Security boundary
Never provide a router password, Wi-Fi key, ISP account password, payment PIN or one-time code to a third-party help page. Credentials belong only in the local device or the official vendor/provider workflow.
How to use this hub efficiently
This page is a navigation and learning hub, not a substitute for exact-device documentation. Start with the symptom or task, then move to the IP, brand, model, ISP or troubleshooting guide that matches the equipment you actually have. When two guides disagree, prefer the one scoped to the exact model/provider and the newest first-party source.
Accuracy rule
Network defaults are conditional. Firmware, operating mode, ISP customization and owner changes can alter addresses, credentials and menu paths. The site therefore distinguishes verified defaults from discovery steps and avoids turning one product’s value into a universal answer.
Keep a small network record
Record the router/gateway model, operating mode, LAN subnet, ISP handoff, important reservations and the location of backups. That simple record makes future upgrades and troubleshooting much safer than relying on remembered defaults.
Choose the guide that matches the layer you are working on
Router problems become much easier when the job is separated into client, Wi-Fi, LAN addressing, gateway/routing, DNS, WAN/provider and application layers. Use this hub to move to the narrowest relevant guide instead of changing settings across several layers at once.
Verify before a destructive change
Factory reset, bridge mode, VLAN edits, firmware changes and LAN-subnet changes can remove working access. Before making one of those changes, save the existing value, confirm a recovery path and keep a local wired connection available where practical.
Use current device-specific evidence
A standard explains how a protocol works; a manufacturer or ISP source explains how a specific device exposes it. Both matter. The site intentionally avoids converting one router’s menu or password into a universal instruction.