Treat the home router as several independent network functions
A SOHO gateway may combine a wireless access point, Ethernet switch, DHCP server, DNS forwarder, router, firewall, NAT, and WAN interface in one plastic box. That packaging creates a dangerous troubleshooting shortcut: “the router is broken.” Instead, identify which function is still working, which function first fails, and what shared dependency explains the symptom scope.
Evidence path: Scope → Access method → Intended IP state → Local gateway → WAN/provider state → Remote numeric IP → DNS → Exact service → Targeted change → Same-condition verification.
Five symptom scopes produce five different first branches
| Scope | Useful inference | High-value next comparison | Poor first reaction |
|---|---|---|---|
| One device | Shared infrastructure may be healthy | Same-network working peer | Reboot the gateway for everyone |
| Wi-Fi only | Wired path can control for WAN/LAN functions | Association/authentication/IP vs wired peer | Blame ISP immediately |
| One subnet/guest network | Segment-specific configuration is plausible | Gateway, DHCP, mapping, policy | Factory-reset everything |
| All clients; local still works | Shared outward dependency is suspect | WAN, numeric remote IP, DNS | Replace endpoint adapters |
| One destination/app | Network-wide outage is inconsistent | Exact name/IP/port/service from peers | Change global DNS/NAT blindly |
Swipe horizontally to see the full table.
Compare paths, not exact IP addresses
When one laptop fails while a second laptop on the same intended network works, compare SSID or Ethernet attachment, IP address and prefix, default gateway, DNS servers, and results to the same gateway and destination. The peer's success through the same access point and Internet edge is evidence against a total ISP outage.
Do not copy the peer's exact address. The useful comparison is configuration structure and behavior; duplicating the address creates an IP conflict.
“Connected to Wi-Fi” hides several separate checkpoints
Wireless troubleshooting should distinguish visibility, association, authentication, IP configuration, gateway reachability, and upstream access. Seeing an SSID proves only discovery. Association does not prove authentication. Authentication does not prove DHCP. A valid lease does not prove the AP uplink, gateway, DNS, or Internet.
Cannot see SSID
Start with radio/AP state, band/client capability, range, or SSID availability—not DHCP.
Sees SSID, cannot authenticate
Credentials, security mode, client compatibility, or authentication service become relevant.
Authenticated, no usable IP
Advance to DHCP, VLAN/network mapping, or address-assignment path.
When wired clients have full Internet access while multiple wireless clients fail authentication, the wired success demonstrates much of the LAN gateway, WAN, NAT, and ISP path. Focus on the wireless-specific branch.
Different lease failures imply different mechanisms
A 169.254/16 address indicates that expected normal IPv4 configuration was not obtained; it does not identify why. New clients failing while existing leased clients continue working is especially useful because it separates new address acquisition from total LAN forwarding.
| Observed state | Consistent causes | Next discriminating evidence |
|---|---|---|
| 169.254.x.x | DHCP exchange/path/server unavailable | DHCP server state, scope, exchange, access mapping |
| Correct IP, wrong gateway | Bad DHCP option or manual config | Lease details vs design/peer |
| Wrong subnet from valid server | Wrong network mapping/config | SSID/port/network mapping and server configuration |
| New devices fail; old leases work | Scope exhaustion or new-lease path problem | Scope utilization and DHCP transactions |
Renewing repeatedly is not a repair when the server keeps supplying the same incorrect options.
Local gateway success is a checkpoint, not proof of Internet access
If a client reaches its local gateway, it has demonstrated useful portions of endpoint configuration and local forwarding. If it then cannot reach a remote numeric IP, move outward toward WAN state, route/NAT/firewall, provider handoff, or upstream service. Rechecking Wi-Fi credentials after the gateway is already reachable usually adds little information.
If local peers work but the gateway fails, inspect the client's gateway value, local segmentation, gateway interface, and path to it.
Separate physical provider link, WAN addressing, default route, and upstream reachability
“WAN down” can describe several distinct states. The Ethernet/optical/provider handoff can lack link; the gateway can have link but no expected WAN address; it can have an address but lack a usable default route; or it can have all three while the provider next hop or upstream path fails.
Illustrative evidence ladder LAN client → gateway: PASS Gateway WAN link: UP Gateway WAN address: expected address present Default route: present Provider next hop: FAIL Local DNS test: irrelevant until upstream path is resolved Bounded conclusion: local LAN and several WAN control-plane states are proven; the first observed failure is beyond the configured WAN edge.
Translation is relevant only after the earlier path makes it plausible
Private IPv4 clients commonly depend on source NAT when accessing the public Internet. NAT therefore becomes a useful artifact after local gateway reachability and WAN state are established. It should not be the first explanation for every failed website.
A useful question is whether the gateway creates the expected translation/session for the exact outbound flow. If it does, move toward upstream return traffic or policy. If it does not, determine whether the packet reached the NAT function and whether the rule applies. DNS failure, a dead WAN, and a remote service outage can all look like “the Internet doesn't work” without being NAT failures.
Numeric-IP success changes the hypothesis set
If several clients can reach a remote numeric IP but fail when using hostnames, ordinary IP forwarding to that tested destination is working independently of name resolution. Inspect the resolver configured on the clients and query it directly. Distinguish timeout, explicit error, and an unexpected answer.
If the gateway's LAN address is configured as DNS, it may be acting as a forwarder. The client-to-gateway DNS exchange can succeed while the gateway's upstream resolver path fails—or the local forwarding service itself can fail while general routing remains healthy.
Use Can Ping IP but Not Domain Name and DNS Troubleshooting Guide for deeper name-resolution practice.
One successful query does not prove every resolver path
An alternate resolver succeeding is a useful control, but interpret it carefully. It shows the client can reach and use that alternate resolver under the test conditions. It does not by itself prove whether the configured resolver service, forwarding configuration, upstream selection, cache, or a specific record caused the original failure.
Preserve the original failed query, resolver address, result, and timestamp before changing DNS globally.
Do not convert destination-specific evidence into a network-wide diagnosis
If general browsing, DNS, and other remote services work but one application fails, test the exact destination name/IP and required transport port. Compare another client and, when appropriate, another destination using the same protocol. A remote service outage, local application problem, certificate issue, destination-specific policy, or route can survive after the general network path is already proven.
“Internet works” and “this application works” are different requirements.
Capture state while the failure exists
Intermittent problems disappear under observation. Record time, affected devices, Wi-Fi versus wired status, gateway reachability, WAN address/link, remote numeric-IP test, DNS result, and the exact application symptom while the event is active. A later healthy snapshot cannot explain an earlier outage.
Correlating several devices at the same timestamp is especially valuable. If wired and wireless clients simultaneously lose remote numeric-IP access while retaining the gateway, the shared outward dependency deserves attention. If only one client drops while peers remain stable, preserve the peer as a control.
A restart can restore service while destroying the best evidence
Restarting a gateway may renew a WAN lease, clear sessions, restart radios, restart DHCP/DNS services, or reset transient state. If connectivity returns, you have learned that the restart changed something—not which mechanism was wrong.
Before a restart, capture WAN address/link, uptime, DHCP scope state, DNS settings, relevant logs, NAT/session state if available, and the same connectivity tests you will run afterward. A factory reset is far more destructive because it can erase SSIDs, security settings, reservations, forwarding rules, DNS configuration, and logs.
Wired Internet works while two wireless clients cannot authenticate
A desktop on Ethernet has a valid address, reaches the gateway, resolves names, and opens remote sites. Two laptops see the SSID but fail authentication. The desktop's success demonstrates a functioning route through the LAN gateway, WAN, and provider path for that client.
The first unresolved dependency is wireless authentication. Inspect credentials, security mode compatibility, AP radio/security configuration, or an authentication backend if present. Replacing the modem is not matched to the observed split.
Local printer and gateway work for everyone, but remote numeric IPs fail
Three clients reach one another, a printer, and the gateway. The gateway reports its WAN physical link up but has no expected WAN address after a provider-device replacement. DHCP on the LAN is clearly functioning enough to configure the clients, and DNS is not yet the first branch because numeric remote reachability already fails.
Investigate WAN address acquisition, provider handoff requirements, and provider-device state. After restoration, verify remote numeric-IP reachability before using a hostname test.
Every client reaches remote IPs, but hostname queries to the gateway time out
The clients use the gateway as their DNS forwarder. Remote numeric-IP tests succeed, but direct queries to the gateway's resolver service time out. This preserves general IP forwarding while isolating a shared name-resolution dependency.
Inspect the gateway's DNS forwarding service and upstream resolver configuration. If policy permits, an approved alternate-resolver query can serve as a control. After repair, query the intended resolver directly and then open the application by name.
New devices get APIPA while existing leased devices still browse
Two existing devices retain valid leases and Internet access. A newly joined device receives 169.254.x.x, and a second new device behaves the same way. This is not consistent with a completely dead switch, gateway, or ISP path because existing clients continue using them.
Check DHCP scope capacity, DHCP service state, and new-client DHCP exchange. If the scope is exhausted, correct capacity/configuration according to design, obtain a fresh lease, and verify the complete option set—not merely the presence of an IP address.
Only one laptop is slow while a same-network peer is normal
Both laptops use the same Wi-Fi network and gateway. The peer has normal latency and throughput to the same destination while the affected laptop shows poor performance. That comparison makes a universal ISP capacity problem less consistent at that moment.
Advance toward the affected client's radio/link quality, retransmissions, local traffic, VPN/proxy, DNS timing, CPU/disk/security load, and application state. Keep the workload and destination constant when comparing.
For a deeper diagnostic sequence, use One Device Slow on the Network.
A gateway restart “fixes” the outage but does not prove the gateway hardware is bad
After an outage, restarting the gateway restores Internet access. That result is compatible with many mechanisms: a renewed WAN lease, restarted DNS forwarder, cleared session/NAT state, restarted radio, or transient software state. It does not uniquely identify failed hardware.
The better next step is to compare pre-restart and post-restart state and capture the same artifacts if the failure recurs.
Escalate with the first failed provider-side checkpoint
ISP escalation becomes stronger when multiple clients reach the local gateway, WAN configuration matches the intended service, the provider handoff indicates link, and the first unresolved or failed evidence is at the provider-facing next hop or service. Record timestamps, WAN addressing, provider-device indicators, and relevant tests.
Do not blame the ISP when wired Internet works and only Wi-Fi authentication fails, or when remote numeric IPs work and the local DNS forwarder does not. Those symptom scopes point to local functions.
Each successful test removes some causes—not all causes
| Evidence | What it supports | What remains unproven |
|---|---|---|
| Working same-network peer | Shared path works for that peer/test | Affected endpoint state and client-specific path |
| Gateway ping succeeds | Tested local ICMP exchange reaches gateway | WAN, DNS, NAT, remote service |
| Remote numeric IP succeeds | Tested IP path works without DNS | Name resolution and exact application |
| DNS query succeeds | Resolver returned an answer for that query | Application port/service health |
| WAN link is up | Physical/provider handoff has link indication | Valid WAN address, route, provider service |
| Website opens on one client | End-to-end path works for that client/service | Other clients, protocols, or access methods |
Repeat the original test, then protect a known-good function
| Repair | Positive verification | Control/negative verification |
|---|---|---|
| DHCP | Fresh client gets correct IP/prefix/gateway/DNS | Existing clients/scopes remain correct |
| Wi-Fi authentication | Authorized client joins and reaches intended network | Invalid credential remains rejected |
| WAN | Remote numeric IP works under restored WAN state | Local LAN services still work |
| DNS | Direct intended-resolver query succeeds, then app by name | Numeric-IP path remains healthy |
| NAT/policy | Required outbound flow creates expected state and succeeds | Unwanted inbound/policy behavior is not opened |
State scope, known-good checkpoints, first unresolved dependency, and next evidence
Observation: Ethernet clients reach the Internet; multiple wireless clients see the SSID but cannot authenticate. Bounded inference: the shared WAN/ISP path is demonstrably usable by the wired client, while the wireless clients fail before IP configuration. Next discriminating evidence: wireless authentication result, security mode, credential status, and AP authentication logs/state. Smallest justified change: correct only the identified wireless authentication configuration. Verification: an authorized wireless client authenticates and reaches the intended service while an invalid credential remains rejected.
24 SOHO troubleshooting flashcards
Practice symptom scope, wireless checkpoints, DHCP, gateway, WAN, NAT, DNS, service isolation, evidence boundaries, reboot reasoning, escalation, and verification.