How to Troubleshoot Network Connectivity (Step by Step)

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, ruling out one layer at a time until they isolate the problem. That systematic approach is what turns a thirty-minute frustration into a three-minute fix.

This guide walks you through that exact workflow. We will start with the simplest physical checks and 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 based on the results. By the end, you will have a repeatable process for diagnosing virtually any network connectivity issue you encounter.

The Troubleshooting Mindset: Bottom-Up, Not Random

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 a cable that is unplugged, a Wi-Fi toggle that got switched off, or a router that needs a reboot. It feels too obvious to check, which is exactly why people skip it and 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 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 combination (like Fn + F2) can toggle Wi-Fi off without any on-screen notification.
• Is Airplane Mode off? This one catches more people than you would expect — especially on Windows laptops that can enable it with an accidental keyboard shortcut.
• Are you connected to the right network? If you are at home but your device auto-connected to a neighbor’s open network, or you are on a guest network instead of the corporate SSID, that will cause problems.

The Reboot — Yes, Really

Restarting your device and your router is a cliché because it genuinely 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, wait 30 seconds (to let capacitors fully discharge and the ISP-side session time out), then turn it back on. Wait two minutes for it to fully boot. This single step resolves an outsized percentage of home and small-office connectivity problems.

Step 2
Verify Your IP Configuration

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 — 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. If you are unfamiliar with the difference between the public IP your ISP assigns and the private IP your router assigns, our guide on public vs. private IP addresses explains it 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. This means 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, release and renew the DHCP lease (ipconfig /release then ipconfig /renew on Windows), or manually assign a static IP in the correct range if you know the network configuration. Our subnet calculator can help you determine the correct address range and mask.

Step 3
Ping Your Default Gateway

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, your IP configuration is wrong (wrong subnet), a VLAN mismatch, or a switch between you and the router has failed. 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 but 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 the destination is 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 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 try pinging a second external IP to rule out the possibility that the specific server you tested is down:

ping 1.1.1.1
ping 9.9.9.9

Step 5
Test DNS Resolution

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, because 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. If you are unfamiliar with the different DNS record types, our guide on DNS records explained covers what each type does, and our article on how DNS works walks through the full resolution process.

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 systemd-resolve --flush-caches

Switch to a Public DNS Server

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

Step 6
Trace the Route with Traceroute

When you can reach your gateway but not an external destination, or when connectivity is slow and you want to know where the bottleneck is, traceroute is the tool that 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 — 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: If it never reaches the destination and just shows * * * for 30 hops, the destination is unreachable. The last hop that did respond is the last device 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 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 (telnet):

telnet mail.example.com 993

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 → Advanced Settings → 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: If the destination is a cloud server (AWS, Azure, GCP), check the security group or network ACL rules. These are a frequent source of “it 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 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 is working 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 about how this works in our reverse DNS guide.
• Subnet Calculator — If you suspect a subnet mask mismatch, enter your IP and mask to see the network range, broadcast address, and number of usable hosts. A mismatch here is a common cause of “can reach some devices but not others on the same network.”
• 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 much faster.
• Port Number Reference — Look up any port number to find the service that uses it, the protocol (TCP/UDP), and whether it should be open on your network.

Common Scenarios: Quick Diagnosis

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

The Complete Troubleshooting Flowchart

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. If succeeds: continue.
6. tracert [destination] — locate the bottleneck. Identify the hop where packets stop or latency spikes.
7. telnet / 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