Network Troubleshooting: Diagnose and Fix Connection Issues

March 15, 2026 · 6 min read

A Systematic Approach

When network connectivity fails, the worst thing you can do is start randomly changing settings. Effective troubleshooting follows a systematic, bottom-up approach based on the OSI model. Start with the physical layer and work your way up through network, transport, and application layers.

The key question at each layer is: "Does this layer work?" If yes, move up. If no, you've found your problem area. This methodical approach saves hours of guesswork and gets you to the root cause faster.

Here's the fundamental troubleshooting sequence:

1. Physical connectivity — Are cables connected? Is Wi-Fi associated? Are link lights on?
2. Local network — Do you have an IP address? Can you reach your gateway?
3. Internet connectivity — Can you reach external IP addresses?
4. DNS resolution — Can you resolve domain names?
5. Application layer — Is the specific service or port accessible?

Ping: Testing Connectivity

Ping is the most fundamental network diagnostic tool. It sends ICMP Echo Request packets to a target and measures the response time, telling you whether a host is reachable and how fast the connection is.

# Basic ping test
ping google.com

# Ping with specific count (useful for scripts)
ping -c 4 google.com

# Ping with timestamp
ping -D google.com

# Ping with specific packet size (test MTU issues)
ping -s 1472 -M do google.com

# Flood ping for stress testing (requires root)
sudo ping -f -c 1000 192.168.1.1

Reading Ping Results

Understanding ping output is crucial for diagnosis:

• Response time (RTT) — Under 20ms for local network, under 100ms for domestic servers, under 200ms for intercontinental connections. Higher values indicate latency issues.
• Packet loss — Any loss above 0% indicates problems. 1-5% causes noticeable degradation in real-time applications (VoIP, gaming). Above 10% makes most applications unusable.
• TTL (Time to Live) — Indicates how many network hops the packet survived. Starting TTL of 64 suggests a Linux/macOS target, 128 suggests Windows.
• "Destination Host Unreachable" — Your local router can't find a path to the target. Check routing tables and gateway configuration.
• "Request Timed Out" — Packets sent but no response received. The host may be down, firewall may be blocking ICMP, or there's a routing issue.

Use our online Ping tool to test connectivity from our servers when you want to check if the problem is on your end or the destination's end.

Traceroute: Mapping the Path

While ping tells you if a destination is reachable, traceroute shows you the exact path packets take to get there, revealing every router (hop) along the way. This is invaluable for identifying where in the network a problem occurs.

# Standard traceroute (Linux/Mac)
traceroute example.com

# Windows equivalent
tracert example.com

# Use TCP instead of ICMP (bypasses some firewalls)
sudo traceroute -T -p 443 example.com

# Use specific number of queries per hop
traceroute -q 1 example.com

# MTR: combines ping and traceroute (real-time view)
mtr example.com

# MTR with report mode (10 cycles)
mtr -r -c 10 example.com

Interpreting Traceroute Output

Each line in traceroute output represents a hop (router) along the path. Here's what to look for:

• Consistent low latency — Normal operation. Each hop adds a small amount of latency.
• Sudden latency spike at one hop — If subsequent hops also show high latency, that hop is likely the bottleneck. If only that hop is slow but subsequent ones recover, the router may simply deprioritize ICMP responses (not a real problem).
• Asterisks (* * *) — The hop didn't respond. Many routers are configured to drop ICMP packets for security. If the final destination responds, intermediate timeouts are usually harmless.
• Routing loops — Seeing the same IP addresses repeating indicates a routing misconfiguration in the network.

Use our online Traceroute tool to trace routes from our infrastructure, helping you determine whether latency issues are in your local network or further upstream.

DNS Troubleshooting

DNS issues are among the most common causes of "internet is down" complaints. Often, the network itself works fine, but name resolution fails, making it seem like nothing is accessible.

# Quick DNS test: can you reach an IP directly?
ping 8.8.8.8          # If this works but ping google.com doesn't = DNS issue

# Check DNS resolution
nslookup example.com
dig example.com

# Test with alternative DNS server
nslookup example.com 1.1.1.1
dig @8.8.8.8 example.com

# Check your configured DNS servers
cat /etc/resolv.conf              # Linux/Mac
ipconfig /all                      # Windows

# Flush DNS cache
sudo dscacheutil -flushcache       # macOS
sudo systemd-resolve --flush-caches # Linux (systemd)
ipconfig /flushdns                  # Windows

Common DNS Fixes

• Switch DNS servers — If your ISP's DNS is slow or unreliable, switch to public DNS: Cloudflare (1.1.1.1), Google (8.8.8.8), or Quad9 (9.9.9.9).
• Check /etc/hosts — Incorrect entries in the hosts file can override DNS resolution and cause unexpected behavior.
• Clear browser DNS cache — Browsers maintain their own DNS cache separate from the OS. In Chrome, visit chrome://net-internals/#dns and click "Clear host cache."
• Check for DNS hijacking — If DNS queries return unexpected IPs, your DNS traffic might be intercepted. Use DNS over HTTPS to prevent this.

Common Network Problems

Slow Internet Speeds

Slow speeds can result from many factors. Here's a diagnostic checklist:

# Test actual throughput
speedtest-cli
curl -o /dev/null -w "Speed: %{speed_download}\n" https://speed.cloudflare.com/__down?bytes=100000000

# Check for bandwidth-hogging processes
nethogs          # Linux: shows bandwidth per process
nettop           # macOS: network activity monitor

# Check network interface errors
ifconfig eth0    # Look for errors, dropped packets
ip -s link show  # Detailed interface statistics

# Check for duplex mismatch
ethtool eth0     # Verify speed and duplex settings

Intermittent Connectivity

Connections that drop randomly are often the hardest to diagnose. Common causes include:

• Wi-Fi interference — Neighboring networks, microwaves, Bluetooth devices. Use a Wi-Fi analyzer to find the least congested channel.
• IP address conflicts — Two devices with the same IP cause intermittent failures. Check DHCP logs and consider using static IPs for critical devices.
• Failing hardware — Bad cables, dying network cards, overheating switches. Test with known-good equipment.
• MTU issues — Mismatched Maximum Transmission Unit sizes cause packet fragmentation or drops. Test with ping -s 1472 -M do target.

Can't Access Specific Websites

When only certain sites are unreachable:

# Is the site actually down?
curl -I https://example.com

# Check from different DNS
dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

# Check if your IP is blocked
curl -x "" https://example.com  # Direct connection
curl https://example.com         # Through proxy (if configured)

# Test specific port
nc -zv example.com 443
telnet example.com 80

Advanced Diagnostics

Packet Capture with tcpdump

When basic tools aren't enough, packet capture lets you see exactly what's happening on the wire:

# Capture all traffic on an interface
sudo tcpdump -i eth0

# Capture only traffic to/from a specific host
sudo tcpdump -i eth0 host 192.168.1.100

# Capture specific port traffic
sudo tcpdump -i eth0 port 443

# Save capture for analysis in Wireshark
sudo tcpdump -i eth0 -w capture.pcap

# Show HTTP requests
sudo tcpdump -i eth0 -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'

Network Socket Analysis

# List all listening ports
ss -tulnp              # Linux
netstat -tulnp         # Linux (legacy)
lsof -i -P -n         # macOS

# Check established connections
ss -tnp state established

# Find which process is using a port
lsof -i :8080
fuser 8080/tcp

Building a Troubleshooting Toolkit

Every network administrator should have these tools ready:

• ping / ping6 — Basic connectivity and latency testing for IPv4 and IPv6.
• traceroute / mtr — Path analysis and hop-by-hop latency measurement.
• dig / nslookup — DNS query and resolution debugging.
• curl / wget — HTTP-level testing with headers, timing, and redirect following.
• tcpdump / Wireshark — Deep packet inspection for complex issues.
• ss / netstat — Socket and connection state analysis.
• ip / ifconfig — Interface configuration and statistics.
• iperf3 — Bandwidth and throughput testing between two points.

Automation Script

Here's a quick diagnostic script that runs through the fundamental checks:

#!/bin/bash
echo "=== Network Diagnostic Report ==="
echo "Date: $(date)"
echo ""
echo "--- Interface Info ---"
ip addr show | grep "inet "
echo ""
echo "--- Default Gateway ---"
ip route | grep default
echo ""
echo "--- Gateway Ping ---"
GW=$(ip route | grep default | awk '{print $3}')
ping -c 3 $GW
echo ""
echo "--- External Ping ---"
ping -c 3 8.8.8.8
echo ""
echo "--- DNS Resolution ---"
dig +short google.com
echo ""
echo "--- Traceroute ---"
traceroute -m 15 -q 1 8.8.8.8
echo ""
echo "=== Report Complete ==="

Key Takeaways

• Follow a systematic bottom-up approach: physical → network → DNS → application layer.
• Ping tests basic connectivity and latency; traceroute reveals the exact network path and identifies bottleneck locations.
• DNS problems are the most common cause of apparent "internet outages"—always test IP connectivity separately.
• MTR combines ping and traceroute for real-time network path analysis, ideal for intermittent issues.
• Build and maintain a troubleshooting toolkit with automated diagnostic scripts for rapid response.