One of the more confusing networking problems is the one where everything appears to be working.
The computer is connected to Wi-Fi. The network icon looks normal. An IP address is assigned. You can even ping a device on the local network.
Yet a website does not open, an application cannot connect to its server, or a service keeps timing out.
When this happens, restarting everything can sometimes help, but it does not explain what went wrong. A better approach is to test the connection one layer at a time and use each result to narrow down the problem.
Start By Finding Out What Actually Fails
Before changing settings, define the problem.
Is every website unavailable, or only one website? Does the problem affect one computer or every device on the network? Can local devices communicate? Does the problem happen in a browser but not from the command line?
These questions matter because different symptoms point toward different parts of the network.
For example, if several devices cannot reach the internet, investigating one laptop's browser settings is probably not the first thing to do. On the other hand, if every other device works normally, the problem may be local to that computer.
A useful troubleshooting session begins with a simple statement such as:
"This computer has a network connection, but it cannot reach external websites."
That is much easier to investigate than simply saying that "the internet is broken."
Check The Local Network First
The first technical step is to find out whether the device can communicate with the local network.
On Windows, ipconfig can show the assigned IP address, subnet mask, and default gateway. On Linux and macOS, commands such as ip addr or ifconfig can provide similar information.
Look for an address that makes sense for the network.
You should also identify the default gateway. The gateway is normally the device responsible for forwarding traffic from the local network toward other networks.
If the computer has no usable IP address or does not have a gateway, testing external websites is not very useful yet. The local configuration needs attention first.
This simple check prevents a common troubleshooting mistake: trying to diagnose an internet problem before confirming that the computer has a functional local network connection.
Test The Gateway Before Testing The Internet
Once the local configuration looks reasonable, test the default gateway.
A common way to do this is with ping.
For example:
ping 192.168.1.1
The address will be different depending on the network.
A successful response does not prove that the internet is working. It only gives you evidence that the computer can communicate with the gateway.
That distinction is important.
If the gateway cannot be reached, the next investigation should focus on the local connection. Wi-Fi signal problems, VLAN configuration, cabling, firewall rules, incorrect addressing, and other local issues can all prevent successful communication.
If the gateway responds, you have eliminated several possible problems and can move to the next part of the path.
Separate DNS Problems From Connectivity Problems
DNS causes a surprising number of confusing network symptoms.
A user may say that a website is unavailable, even though the computer can reach the internet normally. The problem may simply be that a domain name is not being resolved correctly.
You can test this by trying to reach a known IP address and then comparing the result with a hostname lookup.
Commands such as nslookup or dig can help:
nslookup example.com
or:
dig example.com
If the lookup fails while other network tests work, DNS deserves closer attention.
This is also why changing DNS settings randomly is not a good first step. First determine whether DNS is actually involved.
A useful troubleshooting process should eliminate possibilities rather than changing several variables at the same time.
Use Traceroute When You Need To See The Path
Sometimes a connection works locally and DNS works correctly, but traffic still does not reach its destination.
That is when a route-tracing tool can provide additional information.
Windows provides tracert, while Linux and macOS commonly provide traceroute.
For example:
tracert example.com
The output can show the sequence of network hops between your computer and the destination.
Do not expect every hop to respond. Some routers intentionally ignore or limit traceroute traffic. A timeout at one hop does not automatically mean that the connection is broken.
Instead, look at the overall pattern.
If traffic reaches several intermediate networks and then consistently stops, the location of the failure may be further away from your computer. If the trace fails immediately after the local gateway, the local network or upstream connection deserves more attention.
Traceroute is most useful when you understand it as evidence about the path, not as a simple pass-or-fail test.
Check Whether The Application Is The Real Problem
Not every connection problem is a network problem.
Suppose a browser cannot load one particular site, while other sites work normally. DNS resolves correctly, the gateway responds, and other internet services are available.
At this point, continuing to change network settings may make the situation worse.
The problem could involve the browser, cached data, a proxy configuration, TLS negotiation, an application-specific firewall rule, or the remote service itself.
This is why testing with more than one tool is useful.
If a command-line request succeeds while a browser fails, the difference between those two paths can provide a valuable clue.
The same principle applies to applications. If one application cannot connect while other applications work normally, investigate the application before assuming the entire network is failing.
Change One Thing At A Time
One of the easiest ways to make troubleshooting harder is to change several settings simultaneously.
For example, a person might restart the router, change DNS servers, disable a firewall, reinstall a network adapter, and modify proxy settings all within a few minutes.
If the problem disappears, there is no clear explanation for why it disappeared.
A better method is to make one controlled change, test again, and record the result.
You do not need a complicated ticketing system for small problems. Even a short note can help:
Gateway reachable: yes
DNS lookup: yes
External ping: blocked
Browser: website unavailable
Second browser: website unavailable
This gives you a much clearer picture than relying on memory.
It also makes it easier to reverse a change when necessary.
A Simple Troubleshooting Order
When a network connection behaves strangely, a useful sequence is:
1. Define the exact symptom
2. Check the local IP configuration
3. Test the default gateway
4. Test name resolution
5. Test external connectivity
6. Examine the route if necessary
7. Test the affected application
8. Change one variable at a time
The purpose of this sequence is not to memorize a list of commands.
It is to move from the closest and simplest part of the connection toward the more distant and complicated parts.
If the computer cannot reach its gateway, there is little value in investigating the remote web server. If DNS does not resolve a hostname, there may be no reason to troubleshoot the browser yet. If every network test succeeds but one application still fails, the application deserves attention.
Final Thoughts
Network troubleshooting becomes much easier when you stop treating connectivity as a single thing.
A working network involves several pieces: local addressing, the gateway, routing, DNS, transport connections, applications, and the remote service. A failure in any one of them can produce a similar message to the user: "It is not working."
The goal of troubleshooting is therefore not to find a command that magically fixes the problem.
The goal is to collect enough evidence to identify where the failure occurs.
Start close to the device, test each stage, record what works, and avoid changing several things at once. With that approach, even unfamiliar network problems become much more manageable.
