Network Troubleshooting Guide: A Practical Order for Finding the Problem

Network troubleshooting becomes much easier when you stop jumping randomly between settings and test the problem in a fixed order.

The goal is to isolate the failure: device, local link, IP configuration, gateway, DNS, Internet path, or application.

This guide gives you the order I use, then links to the detailed tools and commands already covered on the site.

1. Define the exact problem

Before running commands, answer these questions:

• Is one device affected or many?
• Is the problem wired, Wi-Fi, or both?
• Can the device reach local resources?
• Can it reach the Internet by IP address?
• Can it resolve domain names?
• Is the problem constant or intermittent?
• Did anything change before the issue started?

This prevents you from wasting time troubleshooting DNS when the Ethernet cable is disconnected.

2. Check the physical and link layer

Start with the simple things.

• Check Ethernet cables and switch ports.
• Confirm link lights.
• Check negotiated speed.
• For Wi-Fi, check signal strength and whether the device joined the correct SSID.
• Try another known-good cable or port if the issue is suspicious.

If the interface has no link, higher-level tests will not help.

3. Check IP configuration

Verify that the device has a valid IP address, subnet mask, default gateway, and DNS server.

On Windows:

ipconfig /all

On Linux:

ip addr

ip route

If a Windows client shows an address in the 169.254.x.x range when it should receive DHCP, that usually means it failed to get a DHCP lease.

4. Ping the local device first

Test the local TCP/IP stack:

ping 127.0.0.1

Then test the device’s own IP address. After that, ping another device on the same subnet.

If local-subnet communication fails, there is no reason to troubleshoot the Internet yet.

5. Ping the default gateway

If the device can communicate locally, test the default gateway.

ping 192.168.1.1

Replace the address with your real gateway.

If local devices respond but the gateway does not, investigate VLANs, Wi-Fi isolation, switch configuration, firewall rules, or the gateway itself.

6. Test Internet connectivity by IP address

Next, test a known public IP address.

If public IP connectivity works but websites do not open by name, DNS becomes the main suspect.

Be aware that some systems block ICMP, so a failed ping alone does not always prove the destination is unreachable. Use more than one test when needed.

7. Test DNS separately

Use nslookup or dig to check name resolution.

I have a detailed walkthrough here: How to Use nslookup and dig for DNS Troubleshooting.

Typical checks include:

nslookup example.com

or:

dig example.com

You can also query a specific DNS server to compare results.

If your DNS server itself is wrong or unreliable, see How to Change Your DNS Server.

8. Use traceroute when the route matters

If the local network and DNS are working but a remote destination is unreachable or unusually slow, traceroute can help show where the path changes or stops responding.

On Windows:

tracert example.com

On Linux:

traceroute example.com

Do not assume every non-responsive hop is broken. Routers can rate-limit or ignore traceroute probes while still forwarding real traffic normally.

9. Use iPerf for throughput problems

If the complaint is “the network is slow,” ping is not enough.

Use iPerf to measure actual network throughput between two endpoints without mixing in disk speed or application behavior.

My full guide is here: How to Use iPerf for Network Testing and Troubleshooting.

This is especially useful for NAS troubleshooting because it lets you separate network performance from storage performance.

10. Compare wired and Wi-Fi results

If a device is slow over Wi-Fi, connect it temporarily by Ethernet.

If wired performance is good, the NAS, server, and Internet connection may be fine. The problem may instead be Wi-Fi signal, channel congestion, interference, client capability, or access-point placement.

For a broader home setup, see the Home Network Setup Guide.

11. Check for duplicate IP addresses

Duplicate static addresses can create intermittent connectivity that looks random.

If the problem started after manually assigning an IP, confirm that the address is outside the DHCP pool or properly reserved.

Check the router/DHCP leases and ARP tables if you suspect a conflict.

12. Check firewall and security rules

If one service fails while the rest of the network works, check host firewalls, NAS firewall rules, router ACLs, VLAN policies, and security software.

A successful ping does not mean SMB, HTTPS, SSH, or another application port is allowed.

13. Check the application layer

Once network connectivity is proven, troubleshoot the application itself.

• If the NAS responds to ping but a share does not open, check SMB service and permissions.
• If a website resolves and responds but the application still fails, check the application port and service.
• If remote access works by IP but not hostname, check DNS or Dynamic DNS.

For Dynamic DNS, see How to Set Up Dynamic DNS.

14. Troubleshoot remote access carefully

Remote access problems involve both the internal network and the Internet-facing configuration.

Check:

• Public IP or CGNAT situation
• VPN configuration
• Dynamic DNS
• Firewall rules
• Port forwarding if you intentionally use it
• Whether the internal service is actually listening

I generally prefer VPN-based access over exposing management services directly.

See Access Your Home Network Remotely for the broader remote-access discussion.

15. Watch for packet loss and latency, not just bandwidth

A connection can have good headline bandwidth and still feel bad if latency is high or packets are being lost.

For intermittent problems, run longer ping tests and compare results during normal and problematic periods.

Look for patterns: only during backups, only at busy hours, only on one Wi-Fi band, or only when a certain switch or access point is involved.

16. Change one thing at a time

This sounds basic, but it matters.

If you change DNS, reboot the router, replace the cable, change VLAN settings, and update drivers at the same time, you may fix the problem without knowing what caused it.

Make one meaningful change, test again, and record the result.

A practical troubleshooting order

1. Define the scope.
2. Check cable/Wi-Fi/link state.
3. Check IP, subnet, gateway, and DNS.
4. Test local communication.
5. Test the gateway.
6. Test the Internet by IP.
7. Test DNS.
8. Use traceroute if the route is suspicious.
9. Use iPerf if throughput is the problem.
10. Check firewall and application services.
11. Compare a second device or connection method.
12. Change one thing and retest.

Useful tools and guides

• iPerf Network Testing Guide
• nslookup and dig DNS Troubleshooting
• Bulk DNS Lookup Tool
• IPv4 Subnet Calculator
• NAS Performance Troubleshooting Guide

Conclusion

The fastest way to troubleshoot a network is usually not knowing more commands—it is testing in the correct order.

Prove the local link first, then IP configuration, gateway access, Internet connectivity, DNS, route, throughput, and finally the application. Once you know which layer fails, the number of possible causes drops dramatically.