How to Troubleshoot Network Connectivity (Step by Step)

Last updated: June 9, 2026

Your network is down. Maybe the browser says “This site can’t be reached.” Maybe Slack goes offline while your coworker’s machine works fine. Maybe everything feels slow but nothing is completely broken. The instinct is to start changing settings, rebooting things, and hoping something works. But hope is not a diagnostic methodology.

The professionals who troubleshoot network connectivity for a living, network engineers, sysadmins, help desk techs, don’t guess. They follow a sequence. They start at the bottom of the networking stack and work upward. They rule out one layer at a time until they isolate the problem. That systematic approach turns a thirty-minute frustration into a three-minute fix.

This guide walks you through that exact workflow. We start with the simplest physical checks. From there we progress through IP configuration, gateway connectivity, external reachability, DNS resolution, route tracing, and firewall diagnostics. Every step includes the actual commands you would run, what the output means, and what to do next. It also covers two modern gotchas older guides miss. One is browser DNS over HTTPS. The other is that Windows no longer ships with telnet.

The Troubleshooting Mindset: Bottom-Up, Not Random

Effective network troubleshooting works from the bottom of the stack upward, ruling out one layer at a time. Lower layers support higher ones, so a broken physical link makes everything above fail. Start at the bottom, test each layer, and rule out the simple stuff first.

Effective network troubleshooting borrows its logic from the OSI model. You do not need to memorize all seven layers, but the principle matters: lower layers support higher ones. If the physical connection is broken, nothing above it (IP, TCP, DNS, HTTP) can possibly work. If the IP configuration is wrong, pinging a remote server is pointless. If routing works but DNS is broken, websites will not load even though the internet connection is technically fine.

This means you always start at the bottom and work up. Each step either passes (move to the next layer) or fails (you have found the problem layer). It is a process of elimination, and it works every time because you are not skipping anything.

The other rule is equally important: rule out the simple stuff first. The most common cause of “the network is down” is mundane. A cable is unplugged, a Wi-Fi toggle got switched off, or a router needs a reboot. It feels too obvious to check. That is exactly why people skip it. They waste twenty minutes running packet captures before noticing the Ethernet cable is loose. Check the obvious. Then move on.

Step 1
Check Physical Connections

Before touching the command line, check the hardware. This is the most skipped step and the one that most often solves the problem. Verify cables are seated, link lights are on, Wi-Fi is enabled, and airplane mode is off. Then reboot the router and modem.

Before you touch the command line, look at the hardware. This is the most skipped step in network troubleshooting and the one that solves the problem most often.

Wired Connections

• Is the Ethernet cable plugged in at both ends? Check the port on your device and the port on the switch, router, or wall jack. Cables can work loose over time, especially in busy environments.
• Are the link lights on? Most network adapters and switches have LED indicators. A solid or blinking green light typically means a good connection. No light means no physical link.
• Try a different cable. Cables fail. Connectors get damaged. A different cable eliminates this variable in seconds.
• Try a different port on the switch or router. Dead ports happen.

Wireless Connections

• Is Wi-Fi enabled? Check your operating system’s network settings. On laptops, a physical switch or function key (like Fn + F2) can toggle Wi-Fi off. It often gives no on-screen notification.
• Is Airplane Mode off? This one catches more people than you would expect. Windows laptops can enable it with an accidental keyboard shortcut.
• Are you connected to the right network? Maybe your device auto-connected to a neighbor’s open network. Or you are on a guest network instead of the corporate SSID. Either will cause problems.

The Reboot — Yes, Really

Restarting your device and your router is a cliché because it works. Routers, especially consumer models, can develop stale DHCP leases, overflowed NAT tables, or firmware glitches that a power cycle clears. Turn off the router and wait 30 seconds. That lets capacitors discharge and the ISP-side session time out. Then turn it back on and wait two minutes for it to fully boot. This single step resolves an outsized share of home and small-office connectivity problems.

Step 2
Verify Your IP Configuration

Without a valid IP address, subnet mask, default gateway, and DNS server, your device cannot communicate. Even a perfect cable will not help. Run ipconfig on Windows or ip addr show on Linux to check all four. An address starting with 169.254 means DHCP failed and the device used an APIPA fallback.

If the physical connection looks good, the next question is whether your device has a valid IP configuration. Without a properly assigned IP address, subnet mask, default gateway, and DNS server, your device cannot communicate on the network. That holds even if the cable is perfect.

Check Your IP Address

Windows:

ipconfig /all

macOS / Linux:

ifconfig
# or on modern Linux:
ip addr show

Look at the output for your active network adapter. You need four things. The public IP your ISP assigns differs from the private IP your router assigns. Our guide on public vs. private IP addresses explains the difference in detail.

The APIPA Problem: 169.254.x.x

If your IP address starts with 169.254, your device is using an APIPA (Automatic Private IP Addressing) address. It tried to contact a DHCP server, received no response, and assigned itself a link-local address as a fallback. You have local physical connectivity, but DHCP is not working. Either the DHCP server (usually your router) is down, unreachable, or out of available leases.

Fixes: reboot the router, or release and renew the DHCP lease. On Windows that is ipconfig /release then ipconfig /renew. You can also assign a static IP in the correct range if you know the configuration. Our subnet calculator can help you determine the correct address range and mask.

Step 3
Ping Your Default Gateway

With a valid IP and a good physical connection, test the nearest network device: your default gateway. Ping the gateway address from Step 2. Success means your local network works and the problem is upstream. Failure points to a router, subnet, or switch problem on your own network.

You have a valid IP address and your physical connection is good. Now test whether your device can actually reach the nearest network device, your default gateway (router).

ping 192.168.1.1

(Replace 192.168.1.1 with whatever your gateway address is from Step 2.)

Interpreting the Results

Success — Replies come back:

Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64
Reply from 192.168.1.1: bytes=32 time<1ms TTL=64

Your local network is working. The problem is upstream. Move to Step 4.

Failure — Request Timed Out:

Request timed out.
Request timed out.
Request timed out.
Request timed out.

Your device cannot reach the router. Possible causes: the router is down, or your IP configuration is wrong (wrong subnet). A VLAN mismatch or a failed switch between you and the router can also cause it. Go back to Steps 1 and 2.

Failure — Destination Host Unreachable:

Reply from 192.168.1.50: Destination host unreachable.

This means your own device, or another router in the path, knows the destination exists on the local network. It just cannot reach it. Often caused by an IP address conflict, an incorrect subnet mask, or an ARP resolution failure.

Notice the key difference. Request Timed Out means packets were sent but no reply came back. Destination Host Unreachable means the sending device decided it was unreachable before the packet left. Different causes, different fixes.

Step 4
Ping an External IP Address

If the gateway responds, test whether you can reach beyond your local network. Use a well-known public IP like 8.8.8.8. Success means you have internet connectivity, so any remaining problem is likely DNS. Failure points to a problem between your router and your ISP, such as a WAN outage.

If the gateway responds, test whether you can reach something beyond your local network. Use a well-known public IP that is almost always online:

ping 8.8.8.8

This is Google’s public DNS server. It is globally distributed, highly available, and responds to ICMP ping requests. If you prefer not to use Google, Cloudflare’s 1.1.1.1 works the same way.

If this succeeds: You have internet connectivity. Your device can reach the outside world. If websites still are not loading, the problem is almost certainly DNS. Your device can reach IP addresses but cannot translate domain names. Go to Step 5.

If this fails: You can reach your router but not the internet. This points to a problem between your router and your ISP. Check whether the router’s WAN interface has an IP address (log into the router admin page). Check whether the modem’s lights indicate a connection. If nothing on your network can reach the internet, this is likely an ISP outage or a modem/WAN configuration issue.

You can also ping a second external IP. That rules out the chance the specific server you tested is down:

ping 1.1.1.1
ping 9.9.9.9

Step 5
Test DNS Resolution

This step determines whether your device can translate domain names into IP addresses. DNS failures are among the most common causes of internet-not-working complaints. Connectivity is fine, but nothing loads by name. If ping 8.8.8.8 works but ping google.com fails, you have confirmed a DNS problem.

This is the step where you determine whether your device can translate domain names like google.com into IP addresses. DNS failures are one of the most common causes of internet-not-working complaints. The underlying connectivity is fine, but nothing loads by name.

Quick Test: Ping a Domain

ping google.com

If this fails but ping 8.8.8.8 succeeds, you have confirmed a DNS problem. Your connection works. Name resolution does not.

Dig Deeper with nslookup or dig

Windows:

nslookup google.com
nslookup google.com 8.8.8.8

macOS / Linux:

dig google.com
dig @8.8.8.8 google.com

The second command in each pair forces the query through a specific DNS server (8.8.8.8). If your default DNS server fails but 8.8.8.8 works, you have isolated the issue to your configured DNS server. It is either down, unreachable, or misconfigured.

For a more thorough investigation, use our DNS lookup tool to query specific record types and compare results. Unfamiliar with the different DNS record types? Our guide on DNS records explained covers what each type does. Our article on how DNS works walks through the full resolution process.

When Your Browser and nslookup Disagree: DNS over HTTPS

Here is a modern gotcha that trips up even experienced troubleshooters. You run nslookup google.com, it resolves perfectly, but the browser still shows a DNS error. Or the reverse: the browser loads sites while nslookup fails. The two are testing different resolvers.

Modern browsers (Chrome, Edge, Firefox) default to DNS over HTTPS (DoH). They send DNS queries encrypted over port 443 to their own resolver. This bypasses your operating system and router DNS entirely. Tools like nslookup and dig use the system resolver instead. So the browser and the command line can disagree about whether a name resolves.

This matters because the fix changes depending on which resolver is broken. A failing DoH resolver is fixed in the browser. A failing system resolver is fixed in your OS or router settings. Knowing the browser uses a separate path saves you from “fixing” the wrong thing.

Flush Your DNS Cache

Sometimes your device has cached a stale or incorrect DNS entry. Flushing the cache forces fresh lookups.

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux (systemd-resolved):

sudo resolvectl flush-caches

Older distros that have not adopted resolvectl still accept the deprecated sudo systemd-resolve --flush-caches.

Switch to a Public DNS Server

If your configured DNS is the problem, switch to a public resolver temporarily. That restores connectivity while you fix the root cause:

Step 6
Trace the Route with Traceroute

Traceroute shows the path your traffic takes, hop by hop. Use it when you can reach your gateway but not an external destination, or when a connection is slow. It reveals where packets stop or where latency spikes. That tells you whether the problem is local, at your ISP, or near the destination.

Sometimes you can reach your gateway but not an external destination, or a connection is slow. When you want to know where the bottleneck is, traceroute shows you the path.

Windows:

tracert google.com

macOS / Linux:

traceroute google.com

Reading the Output

Traceroute sends packets with incrementally increasing TTL (Time to Live) values. Each router along the path decrements the TTL by one. When the TTL hits zero, that router sends back an ICMP “Time Exceeded” message, revealing its identity. The result is a hop-by-hop map of the route your traffic takes.

tracert 8.8.8.8

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2     8 ms     7 ms     9 ms  10.0.0.1
  3    12 ms    11 ms    12 ms  72.14.215.85
  4    14 ms    13 ms    13 ms  108.170.248.161
  5    15 ms    14 ms    14 ms  dns.google [8.8.8.8]

Trace complete.

What to look for:

• Asterisks (* * *): That hop did not respond. One or two non-responding hops in the middle are normal, since many routers are configured to drop ICMP. But if every hop after a certain point shows asterisks, that is where packets are dying.
• Sudden time jumps: If latency goes from 15ms to 200ms at a specific hop, that is likely the bottleneck. A congested link, a geographic jump (packets crossing an ocean), or a poorly performing router.
• The trace stops entirely: the output shows repeated timeouts for all 30 hops and never reaches the destination. That destination is unreachable. The last hop that responded is as far as your traffic reached.

Traceroute tells you where the problem is. If packets die at hop 2 (your ISP’s first router), it is an ISP issue. If they die at hop 12 (somewhere in a data center), it is a problem with the destination’s network. If latency spikes at hop 3, your ISP has a congested link.

Step 7
Check for Port and Firewall Issues

Sometimes general connectivity works but one specific application cannot connect. This usually means a firewall is blocking the port that application needs, or the service is not running. Test a specific port with Test-NetConnection on Windows or netcat on macOS and Linux. The result shows whether the port is open, blocked, or refused.

Sometimes general connectivity works fine. You can ping, resolve DNS, and browse the web, but a specific application cannot connect. Email is not syncing, SSH is refused, a database client times out. This usually means a firewall is blocking the specific port that application needs. Or the service on the other end is not running.

Test a Specific Port

Windows (PowerShell): The classic telnet client is no longer installed by default on Windows 10 or 11. The modern method is PowerShell’s Test-NetConnection:

Test-NetConnection mail.example.com -Port 993

Look at the TcpTestSucceeded line. True means the port is open and reachable. False means it is blocked or nothing is listening. If you prefer telnet, you can still enable it under Windows Features, but Test-NetConnection needs no setup.

macOS / Linux (netcat):

nc -zv mail.example.com 993

If the connection succeeds, the port is open and the service is listening. If it times out, a firewall is likely blocking traffic to that port. If it is refused, the port is reachable but no service is listening on it.

Common Culprits

• Windows Firewall: Check Windows Defender Firewall, then Advanced Settings, then Inbound Rules. Look for rules blocking the application or port. You can temporarily disable the firewall for testing (re-enable it immediately after).
• Linux iptables/nftables: Run sudo iptables -L -n to list current firewall rules. Look for DROP or REJECT rules affecting the port in question.
• Cloud security groups: For a cloud server (AWS, Azure, GCP), check the security group or network ACL rules. These are a frequent source of “works from one machine but not another” issues.
• ISP-level blocking: Some ISPs block common ports like 25 (SMTP) to prevent spam. This is especially common on residential connections.

For a comprehensive reference on which ports common services use, see our port number reference page. Our guide on common network ports explains why these ports matter and how they are used in practice.

Advanced: Using Our Diagnostic Tools

Each step in this workflow maps to a free NetworkCheckr tool that provides deeper insight. My IP Address, DNS Lookup, Reverse DNS, and the Subnet Calculator each answer a question raised above. So do the IP Binary Converter, Port Number Reference, Bandwidth Calculator, and SSL Certificate Checker.

Each step in this troubleshooting workflow maps to a tool that can provide deeper insight. Here is how to use them in your diagnostics:

• My IP Address — Quickly verify your public IP address. If this shows an IP, you definitely have internet connectivity. Compare it with the WAN IP your router reports to check for double NAT.
• DNS Lookup — Query any domain for specific record types (A, AAAA, MX, CNAME, TXT). Use this to verify whether DNS resolution works from the server side, independent of your local DNS cache or configuration.
• Reverse DNS Lookup — Enter an IP address to find its hostname. Useful for identifying unknown IP addresses in traceroute output or firewall logs. Read more in our reverse DNS guide.
• Subnet Calculator — Suspect a subnet mask mismatch? Enter your IP and mask to see the network range, broadcast address, and usable hosts. A mismatch is a common cause of “can reach some devices but not others.”
• IP Binary Converter — Convert IP addresses to binary to verify whether two devices are actually on the same subnet. Understanding the binary structure of IP address formats makes subnet troubleshooting faster.
• Port Number Reference — Look up any port number to find the service that uses it and the protocol (TCP/UDP). It also shows whether the port should be open on your network.
• Bandwidth Transfer Calculator — Is a transfer taking longer than expected? Plug in the file size and your link speed. The tool shows whether the wait time is realistic or a real bottleneck.
• SSL Certificate Checker — If a site fails to load over HTTPS, check the certificate. It may have expired, have the wrong Subject Alternative Names, or never been issued. Certificate problems are a common but misdiagnosed cause of failed page loads.

Common Scenarios: Quick Diagnosis

Most connectivity problems fall into recognizable patterns. Examples include Wi-Fi connected with no internet, slow connections, intermittent drops, and one unreachable site. VPN issues and a device that will not connect are common too. Each maps to a workflow step, so matching your symptom jumps you to the cause.

Here are the most frequent network connectivity problems and where they fall in the troubleshooting workflow:

The Complete Troubleshooting Flowchart

The entire process is a decision tree. At each step, the result tells you exactly where to go next. Work through physical checks, IP configuration, gateway ping, external ping, DNS test, traceroute, and port test in order. Each step either passes and sends you onward, or fails and pinpoints the problem layer.

Here is the entire process as a decision tree. At each step, the result tells you exactly where to go next:

1. Physical check — cables, Wi-Fi, airplane mode, link lights. If bad: fix the physical issue. If good: continue.
2. ipconfig / ip addr — check for valid IP. If 169.254.x.x or blank: DHCP issue, reboot router, release/renew. If valid: continue.
3. ping [gateway] — test local connectivity. If fails: local network issue (wrong subnet, switch problem, router down). If succeeds: continue.
4. ping 8.8.8.8 — test internet reachability. If fails: ISP issue, WAN problem, or routing problem. Run traceroute. If succeeds: continue.
5. ping google.com — test DNS. If fails: DNS problem. Flush cache, switch DNS servers, check browser DoH. If succeeds: continue.
6. tracert [destination] — locate the bottleneck. Identify the hop where packets stop or latency spikes.
7. Test-NetConnection / nc — test specific ports. If blocked: firewall or security group issue. If refused: service is not running.

Follow this sequence every time. It works for home networks, corporate environments, cloud infrastructure, and everything in between. The tools change slightly across operating systems, but the logic is universal.

Network troubleshooting is not about memorizing obscure commands. It is about knowing which question to ask next. Start at the bottom, test each layer, and let the results guide you. The network will tell you what is wrong if you ask the right questions in the right order.

Frequently Asked Questions

Seven questions cover the issues that come up most. They include Wi-Fi connected with no internet, what Request Timed Out means, and how to flush DNS. They also cover the default gateway, DNS-versus-IP pings, browser-versus-nslookup disagreements, and when to call your ISP.