Is the problem Wi-Fi, your router, DNS, or your ISP?

When “the internet is down,” several different things may have failed. Treating them as one problem makes troubleshooting slower.

A useful mental model is:

Wi-Fi → Router → Website lookup → Internet

Each stage depends on the one before it, and each failure looks a little different.

1. Wi-Fi: can your Mac maintain a usable local wireless link?

A weak or unstable Wi-Fi link can cause high delay, failed requests, and short disconnects even when the ISP connection itself is healthy.

Clues include poor signal quality, large changes in latency while staying on the same network, or problems that disappear when moving closer to the access point.

This is local. Restarting DNS or blaming the ISP will not fix a weak radio path.

2. Router or local network: can your Mac reach the local gateway?

Your router is normally the first network hop outside the Mac. If the Mac has Wi-Fi but cannot reliably reach its gateway, the problem is still inside the local network.

That can point toward the router, access point, local switching, or the Mac’s current network path.

Onlink’s diagnosis model calls this a router or local network problem rather than pretending it knows which piece of hardware failed.

3. Website lookup: does DNS work?

DNS translates names such as example.com into network addresses.

A DNS failure can make the internet look offline because normal website names stop resolving, while direct internet reachability may still work. That distinction is important: if the wider internet is reachable but name lookup fails, changing DNS settings or investigating the resolver makes more sense than replacing the router.

For a deeper walkthrough, read What DNS problems look like on a Mac.

4. Internet: does traffic get beyond the local network?

If Wi-Fi looks usable, the gateway responds, and DNS is not the main failure, but direct internet or HTTPS checks fail, the likely problem moves outward toward the ISP or wider internet path.

“Likely ISP/internet issue” is still an evidence-based category, not proof that a particular provider device or upstream network caused the incident.

That distinction matters. Good diagnosis should narrow the problem without inventing certainty.

What Onlink checks

Manual Diagnose can inspect the active network interface, Wi-Fi state when available, local gateway, DNS, DNS-independent IPv4 reachability, IPv6 reachability, HTTPS, repeated direct probe quality, and loaded responsiveness.

Automatic incident diagnosis is intentionally lighter. During a detected incident it can capture relevant Wi-Fi state, gateway availability, DNS, direct IPv4, IPv6, and HTTPS evidence without launching a full speed test.

That gives the incident a useful “where did the path stop working?” view while keeping background traffic small.

The result can still be unclear

Real networks are messy. A VPN can change routing. Captive portals can intercept traffic. Multiple failures can happen at once. Some probes may be unavailable.

When evidence does not support one cause, Cause unclear is a better result than a confident guess.

If the problem disappears before you can investigate it, incident history becomes more useful than a manual check performed after recovery.

The goal is not to turn every Mac user into a network engineer. It is to reduce one vague complaint — “the internet is broken” — into a smaller, actionable part of the connection path.