Internet down? Check DNS, Wi-Fi or the line

When the internet goes down, everyone at home suddenly becomes the network department. This guide gives you the questions in the order that finds the fault fastest, so you can stop rebooting things at random.

The short answer

Work from your device outward: link, IP address, gateway, internet by address, name lookup, app. The first step that fails names the layer that is broken. One comparison splits most cases in two: if pinging an IP address works but looking up a name does not, you have a DNS problem. Microsoft's ping documentation describes the same logic [2]. The commands below exist on Windows, Linux and macOS. Our rule for the end: buy nothing until a test shows a defective part.

How it works

1. Start with the scope. Ask four questions before you type a command. Do all devices fail, or one? Do all sites fail, or one? Does it fail on cable and on Wi-Fi? Does a phone on mobile data reach the same site? Apple's support page for a Mac that is online but gets no websites follows the same path: check the Wi-Fi connection, restart, check VPN and security software, restart the router, and if another network works, ask the provider about an outage [16]. Our addition: write the answers down. One failing device points at the device, all failing devices point at the router, the line or the DNS server.
2. Work from the device outward. The Apple ping manual gives the method: run ping first on the local host, then on hosts and gateways further and further away [26]. The table "The ladder at a glance" below the list turns that into six rungs. Stop at the first rung that fails and fix that one before you look further.
3. Link: cable or Wi-Fi. On a cable, check that the plug sits, that the port light is on, and try a second cable and port. On Wi-Fi, confirm that you joined the right network. On Windows, netsh wlan show interfaces lists the wireless interfaces [7]. On Linux, nmcli device wifi list shows channel, rate and signal of every network in range [15]. On a Mac, hold Option, click the Wi-Fi icon and choose Open Wireless Diagnostics. It analyses a connection that reaches the router but loads no pages, and it does not change your settings [17]. We give no signal thresholds because we found no standard source for "good enough". Compare the same spot with a second device instead. Being joined to Wi-Fi is not the same as having internet, because the network must also let your device out [16].
4. IP address. On Windows, ipconfig /all shows the full TCP/IP configuration for all adapters, including DNS servers [1]. On Linux, ip address show up lists the addresses of active interfaces [8]. On a Mac, networksetup -getinfo "Wi-Fi" shows IP address, subnet mask and router for that network service. The service name may differ, and networksetup -listallnetworkservices lists them [21]. Home networks normally use addresses from the private ranges 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 [32]. An address that starts with 169.254 is a link-local address that a device assigns itself when no address configuration is available, for example when no DHCP server answers [33]. Microsoft calls the Windows version APIPA [1]. Then the fault sits between device and router, so look at cable, Wi-Fi and the router's DHCP server. To ask for a new address on Windows, run ipconfig /release and then ipconfig /renew. Microsoft warns that /release disables TCP/IP on adapters that get their address automatically, so do not run it over a remote session [1]. On a Mac, use System Settings, Network, your service, Details, TCP/IP, Renew DHCP Lease [18]. On Linux, reconnect the connection in your network manager (our assessment, no single command applies to all distributions).
5. Gateway. The default gateway is the router address to which your device sends everything that is not local. Windows ipconfig shows it as Default Gateway [1]. On Linux, ip route show lists it as the line that starts with default via [9]. On a Mac, route -n get default prints it [22]. Then ping it: ping /n 4 <gateway> on Windows [2], ping -c 4 <gateway> on Linux and macOS [10][26][20]. An answer means the path to the router works. No answer means the problem is between device and router: cable, Wi-Fi or the router itself. A device can be set not to answer ping, so treat one silent gateway as a strong hint, not as proof, and combine it with step 3 and the router status page.
6. Internet by address. Ping a public resolver by IP address, so DNS is not involved. Cloudflare lists 1.1.1.1 and 1.0.0.1 for its resolver [27]. A reply means your connection reaches the internet at IP level. No reply while pages load normally means something filters ping, so ignore it. No reply and nothing loads sends you to the router status page and the path trace. Use -4 or -6 (/4 and /6 on Windows) to test IPv4 and IPv6 separately [2][10].
7. DNS: system resolver against direct query. Ask twice. First through the normal path of your system, then directly at a public resolver, and compare. On Windows, nslookup example.com uses the default DNS server and nslookup example.com 1.1.1.1 uses the one you name [3]. In PowerShell, Resolve-DnsName example.com -Server 1.1.1.1 does the second part [4]. On Linux, resolvectl query example.com goes through systemd-resolved and prints protocol and interface, and --cache=no skips the local cache [12]. dig @1.1.1.1 example.com asks that server directly, while dig without @ uses the servers from /etc/resolv.conf [14], which on systemd-resolved systems is often the local stub at 127.0.0.53 [13]. On a Mac, dscacheutil -q host -a name example.com resolves through the standard system calls [24]. To see which DNS servers your device uses, run ipconfig /all on Windows [1], resolvectl status on Linux [12], and scutil --dns on a Mac [23] or open the DNS tab in the network settings [19]. Clear caches last. ipconfig /flushdns discards cached and negative entries on Windows [1], and resolvectl flush-caches does the job on Linux [12]. Apple's own man page says its cache flush is for extreme cases only [24]. The table "Reading the results" below explains what the two answers mean.
8. Secure DNS in the browser. Browsers can bypass the system's DNS. In Chrome, Secure DNS is on by default in automatic mode and falls back to unencrypted lookup if it has problems. With a custom provider it does not fall back, and error messages may say that the server's IP address could not be found. Check the provider setting or turn Secure DNS off [28]. Firefox offers protection levels, and in Max Protection sites do not load when secure DNS is not available [29]. If nslookup works but only one browser fails, test with secure DNS off, with another browser, and without VPN or security software, which Apple also lists as a cause [16].
9. Pi-hole or AdGuard Home as the cause. The typical pattern: names fail, pinging an IP address works, and every device asks the same local DNS box that is off, overloaded or cut off from its upstream. Run step 7 against the box and against 1.1.1.1: dig @<box-ip> example.com and dig @1.1.1.1 example.com. If the box fails and 1.1.1.1 answers, the box is your problem. pihole status shows the running state of Pi-hole's DNS and blocking services [30]. pihole disable 5m pauses blocking for five minutes and pihole enable turns it on again [30]. That helps when one site is blocked, not when the DNS service is down. AdGuard Home can pause protection for fixed periods, from 30 seconds to until tomorrow, according to a maintainer thread, and its query log shows what happened to a name [31]. Our guide on Pi-hole and AdGuard Home covers design and repair. A second DNS server on the clients keeps names working when the box is down, but the clients may then use it at any time and skip your filter. That trade-off is yours.
10. Router and modem status page. Open the gateway address from step 5 in a browser. Labels differ by brand, so look for: the Internet or WAN status, the WAN IP address, the connected time or uptime, the line synchronisation on DSL, cable or fibre, and an event log. A status of disconnected points to the line or the provider side, so check the provider's outage page and contact them. A status of connected while your device cannot reach 1.1.1.1 points at router settings or the provider. Many short uptimes mean repeated reconnects, so write down the times. A WAN address in the private ranges [32] or in 100.64.0.0/10 [34] means another device, often at the provider, translates addresses in front of you. That is called carrier-grade NAT. It is not an outage, but incoming connections will not work. Our CGNAT guide for game servers covers that case. Apple also advises installing router firmware updates and restarting the router [16].
11. Trace the path. Run tracert /d 1.1.1.1 on Windows [6] or traceroute -n 1.1.1.1 on Linux and macOS [11][25]. Both options skip name lookups [6][11]. The first line should be your gateway. If the trace stops right after it, look at the router and the line. A row of asterisks is not automatically a fault: Microsoft notes that some routers do not return the expected message and are invisible in the trace [6]. What counts is whether the trace reaches the target and where it stops every time. In PowerShell, Test-NetConnection 1.1.1.1 -TraceRoute does the same [5].
12. Replace hardware only with evidence. Replace a cable only if swapping cable or port fixes the problem. Suspect a Wi-Fi adapter only if the same device works on a cable while other devices keep a good Wi-Fi connection in the same spot. If every device struggles in one spot, that is coverage, and our guides on LAN, Wi-Fi and powerline and on mesh, repeater and access point apply. Suspect the router only if its log shows repeated failures on several days and your provider has checked the line. If the provider owns the modem, ask them to swap it. We rate no provider, and no step above asks you to buy anything.

The ladder at a glance

A command sequence for all three systems

This is a method, not a report on our systems. Replace <gateway> with the address from step 5. example.com is a name reserved for examples. Use a site you actually need if you want to test it.

Windows (Command Prompt or PowerShell):

ipconfig /all
ping /n 4 <gateway>
ping /n 4 1.1.1.1
nslookup example.com
nslookup example.com 1.1.1.1
tracert /d 1.1.1.1

Linux:

ip address show up
ip route show
ping -c 4 <gateway>
ping -c 4 1.1.1.1
resolvectl status
resolvectl query example.com
dig @1.1.1.1 example.com +short +tries=1 +timeout=3
traceroute -n 1.1.1.1

macOS (Terminal):

networksetup -listallnetworkservices
networksetup -getinfo "Wi-Fi"
route -n get default
ping -c 4 <gateway>
ping -c 4 1.1.1.1
scutil --dns
dscacheutil -q host -a name example.com
dig @1.1.1.1 example.com +short +tries=1 +timeout=3
traceroute -n 1.1.1.1

Reading the results

An example of the third row, as an illustration: the gateway answers, 1.1.1.1 answers, nslookup example.com times out, and nslookup example.com 1.1.1.1 returns an address. The router hands out a Pi-hole as DNS server, and that Pi-hole is not running. Start it, then decide whether a second DNS server or a status monitor makes sense. Our guide on Uptime Kuma shows how to watch such a box.

Checklist

• Answer the four scope questions and write them down before you change anything.
• Test with a cable, even for a minute, to separate Wi-Fi from the rest.
• Check that your address does not start with 169.254, and renew it if it does.
• Ping the default gateway with a limited count, and note whether it answers.
• Ping 1.1.1.1 and compare it with a name lookup on the same device.
• Query a public resolver directly and compare the answer with your system's answer.
• Turn secure DNS off in the browser for one test, and test without VPN.
• Pause or stop your Pi-hole or AdGuard Home on a test device, and check its query log.
• Open the router status page, and note WAN status, WAN address and uptime with the time.
• Swap one part at a time, and replace hardware only after a swap proves it defective.