"The Internet is not working" is the most common and least useful sentence in networking. Behind it there may be an unplugged cable, an unresponsive DNS server, a provider fault or a single unreachable website. Rather than restarting everything at random, it pays to follow a method: start from your own device and move outwards one step at a time, checking each link in the chain with the right tool.
The method: from near to far
- Does the device have a valid network configuration?
- Can it reach the router?
- Can the router reach the Internet?
- Are names being resolved?
- Does the specific service respond?
The first negative answer tells you where to focus. Note what you try and what you get: you will need it if you have to call support.
1. The device's configuration
On Windows use ipconfig /all; on macOS and Linux ip addr or ifconfig, and ip route for the gateway. Check:
- IP address: if it starts with 169.254, the device got no reply from DHCP;
- default gateway: it must be the router's address, for example 192.168.1.1;
- DNS servers: they must be present and correct.
If the address belongs to an unexpected network, you may be connected to the wrong Wi-Fi, or there may be a second DHCP server on the network.
2. Reaching the router with ping
ping sends ICMP packets and measures the response time:
ping 192.168.1.1
- Steady replies under 1 ms on cable, or a few ms on Wi-Fi: the local network is working.
- Replies with widely varying times or losses: Wi-Fi problems, interference or a faulty cable.
- No reply: check the physical link, Wi-Fi, VLAN or the device's firewall.
On Windows ping sends four packets and stops; on Linux and macOS it continues until you interrupt it with Ctrl+C, then shows loss and statistics.
3. Getting out to the Internet
Try a well-known public IP address, for example that of a public DNS resolver:
ping 9.9.9.9
Using an IP rather than a name separates connectivity problems from DNS problems. If the router responds but the external address does not, the problem lies between the router and the Internet: the line, authentication with the provider or an outside fault. The router's panel usually shows the WAN connection status and the address received.
Bear in mind that some servers and firewalls deliberately do not answer ping: no reply from a single host does not prove it is unreachable.
4. Checking DNS
If IPs respond but websites will not open, suspicion falls on DNS:
nslookup example.com
nslookup example.com 9.9.9.9
The first command uses the configured resolver, the second a specific server. If the second works and the first does not, the problem is the network's resolver (often the router or the provider). On Linux and macOS dig gives more detail, including the TTL and which server answered.
5. Following the path with traceroute
traceroute (on Windows tracert) shows the routers crossed on the way to a destination, with the time for each hop:
tracert example.com
traceroute example.com
How to read it:
- the first hops are your router and the provider's network;
- a sharp rise in latency that persists across all subsequent hops marks the segment where the delay starts;
- asterisks or high times on a single hop, followed by normal hops, are usually not a problem: many routers give traceroute replies low priority;
- if the trace always stops at the same point, the problem may be there or just after it.
mtr and pathping: continuous traceroute
mtr on Linux and macOS, and pathping on Windows, repeat the measurement on every hop over many cycles, calculating average loss and latency. They are the best tools for intermittent problems, and their output is the most effective evidence to send to your provider.
6. The specific service
If the network works but an application does not, check that the service's port is reachable. In Windows PowerShell:
Test-NetConnection example.com -Port 443
On Linux and macOS you can use nc -vz example.com 443, or curl -I followed by the site's full address to see the HTTP response and its headers. An immediate refusal means the service is not listening; a wait that times out suggests a firewall along the path.
Typical problems and first hypotheses
| Symptom | First hypothesis |
|---|---|
| No sites, no external IP responds | Line or router |
| External IPs respond, names do not | DNS |
| Only one site fails | The site itself or the path to its network |
| Slow only on Wi-Fi | Coverage or interference |
| Slow at certain times | Provider network congestion or bufferbloat |
| Pages loading halfway | MTU problems, often linked to VPNs or tunnels |
In short
- Work outwards from the device, one link at a time.
- Use ipconfig or ip addr to check address, gateway and DNS.
- Pinging the router and a public IP separates local problems from line problems.
- nslookup and dig isolate DNS faults; traceroute and mtr show where delay and loss begin.
- Record commands and results: they are the basis of an effective report to your provider.
