Network problems always follow the same pattern: either something is unreachable, or it is reachable but slow. The diagnostic process works by isolating which part of the stack is failing. This guide covers the tools in the order you would typically use them.

The troubleshooting ladder

Start at the lowest layer and work up:

1. Is the interface up and does it have an IP? (ip addr)
2. Is the default gateway reachable? (ping <gateway>)
3. Can I reach a public IP? (ping 8.8.8.8)
4. Does DNS work? (ping google.com, dig google.com)
5. Is the specific service reachable? (curl, nc, nmap)
6. Where does the path break? (traceroute, mtr)
7. What is the traffic actually doing? (tcpdump)

Layer 1-2: interface and address

# Check interface state and IP addresses
ip addr show
ip link show

# An interface should show:
# state UP
# inet 192.168.x.x/24   (IPv4 address)

# If the interface is DOWN, bring it up
sudo ip link set eth0 up

# If no IP address, check DHCP
sudo dhclient eth0                    # request a DHCP lease
sudo networkctl renew eth0            # systemd-networkd
nmcli con up "Wired connection 1"     # NetworkManager

# Check for link-local address (169.254.x.x = no DHCP response)
ip addr show | grep 169.254

Layer 3: routing and gateway

# Show the routing table
ip route show

# What you need to see:
# default via 192.168.1.1 dev eth0   <-- default gateway exists
# 192.168.1.0/24 dev eth0 scope link <-- local subnet is connected

# No default route = cannot reach anything outside your subnet
# Add one temporarily:
sudo ip route add default via 192.168.1.1

# Find the gateway IP
ip route | grep default
ip route show 0.0.0.0/0

# Ping the gateway (layer 3 local reachability)
GATEWAY=$(ip route | awk '/default/ {print $3}')
ping -c 3 $GATEWAY

# Ping a public IP (tests routing beyond the gateway)
ping -c 3 8.8.8.8
ping -c 3 1.1.1.1

Layer 4+: DNS and application

# Test DNS resolution
ping -c 3 google.com
dig google.com +short
nslookup google.com

# If ping 8.8.8.8 works but ping google.com fails: DNS problem
# Check resolver config
cat /etc/resolv.conf
resolvectl status

# Test with a specific DNS server
dig @8.8.8.8 google.com
dig @1.1.1.1 google.com

# If those work but your configured DNS fails, change the nameserver
sudo nano /etc/resolv.conf
# nameserver 8.8.8.8

ping: basic reachability

# Send 4 ICMP echo requests
ping -c 4 8.8.8.8

# Continuous ping (Ctrl-C to stop)
ping 8.8.8.8

# Set interval (seconds between packets)
ping -i 0.2 -c 20 8.8.8.8          # fast ping, 5 per second

# Set packet size (useful for MTU testing)
ping -s 1400 -c 4 8.8.8.8

# Flood ping (root only, for testing)
sudo ping -f -c 1000 192.168.1.1

# Set timeout per packet
ping -W 1 -c 4 8.8.8.8             # 1 second timeout

# IPv6 ping
ping6 ::1
ping6 -c 3 2001:4860:4860::8888    # Google IPv6 DNS

Interpreting ping output

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=12.3 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=11.8 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss
rtt min/avg/max/mdev = 11.8/12.0/12.3/0.2 ms

• ttl: hops remaining; decrements by 1 at each router; a low TTL means many hops
• time: round-trip latency in milliseconds
• Packet loss percentage indicates unreliability between you and the target

traceroute: path inspection

traceroute reveals every router between you and the destination by sending packets with incrementally higher TTL values.

# Basic traceroute
traceroute google.com

# No DNS reverse lookups (faster)
traceroute -n 8.8.8.8

# Use ICMP instead of UDP (sometimes less filtered)
traceroute -I google.com

# Use TCP SYN packets (penetrates firewalls better)
traceroute -T -p 443 google.com

# Set max hops
traceroute -m 20 google.com

# IPv6 traceroute
traceroute6 2001:4860:4860::8888

Reading traceroute output

traceroute to google.com (142.250.80.46), 30 hops max
 1  192.168.1.1     1.2 ms   1.1 ms   1.3 ms   <-- your gateway
 2  10.0.0.1        8.4 ms   8.2 ms   8.5 ms   <-- ISP router
 3  * * *                                        <-- filtered (normal)
 4  72.14.232.1    14.3 ms  14.1 ms  14.0 ms   <-- Google peering
 5  142.250.80.46   14.8 ms  14.6 ms  14.7 ms  <-- destination

*** at a hop usually means the router does not respond to TTL-expired probes. The problem is only real if *** appears at the destination or if latency suddenly jumps and stays high.

mtr: live traceroute with statistics

mtr combines traceroute and ping, updating continuously and tracking per-hop packet loss and latency.

# Interactive mode (q to quit)
mtr google.com

# No DNS lookups (faster)
mtr -n google.com

# Run for a fixed number of cycles, then print a report
mtr -n -r -c 100 google.com

# Report mode with wide output
mtr -n -r -w -c 100 google.com

# TCP mode (port 443)
mtr -T -P 443 google.com

# IPv6
mtr -6 google.com

Reading mtr output

Host               Loss%  Snt  Last  Avg  Best  Wrst StDev
1. 192.168.1.1      0.0%  100   1.2  1.1  0.9   1.4   0.1
2. 10.0.0.1         0.0%  100   8.3  8.2  8.0   9.1   0.2
3. ???              100.0% 100   0.0  0.0  0.0   0.0   0.0   <-- filtered
4. 72.14.232.1      0.0%  100  14.2 14.1 13.9  14.5   0.1
5. 142.250.80.46    0.0%  100  14.8 14.7 14.5  15.1   0.1

Packet loss at hop 3 that does not continue at hop 4 means hop 3 is filtering probe packets but still forwarding traffic normally — not a real problem. Loss that starts at a hop and continues through all subsequent hops indicates a real issue at that hop.

curl: HTTP and application-layer testing

# Test an HTTP endpoint
curl -v https://google.com

# Show response code and time
curl -w "\nHTTP %{http_code} in %{time_total}s\n" -o /dev/null -s https://google.com

# Test with timeout
curl --max-time 5 https://google.com

# Follow redirects
curl -L https://google.com

# Test bypassing DNS (connect to a specific IP)
curl --resolve google.com:443:142.250.80.46 https://google.com

# Test specific headers
curl -H "Host: google.com" https://142.250.80.46/

# Check connection details
curl -v -o /dev/null -s https://google.com 2>&1 | grep -E '^[<>*]'

# Test with a proxy
curl -x http://proxy:3128 https://google.com

tcpdump: raw packet capture

tcpdump captures packets on a network interface. It is the ultimate debugging tool when other approaches do not reveal the problem.

# Capture all traffic on eth0
sudo tcpdump -i eth0

# Specific port
sudo tcpdump -i eth0 port 80
sudo tcpdump -i eth0 port 443

# Traffic to/from a specific host
sudo tcpdump -i eth0 host 8.8.8.8

# Don't resolve names (faster, less noise)
sudo tcpdump -i eth0 -n port 80

# Save to a file for later analysis (with Wireshark, etc.)
sudo tcpdump -i eth0 -w capture.pcap port 443

# Read a saved capture file
tcpdump -r capture.pcap

# Show full packet contents in hex
sudo tcpdump -i eth0 -XX port 80

# Capture on any interface
sudo tcpdump -i any port 53

# DNS queries
sudo tcpdump -i any -n port 53

# Show TCP flags (SYN, ACK, RST, FIN)
sudo tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0'

# More complex filter: HTTP traffic to/from a specific host
sudo tcpdump -i eth0 -n 'host 8.8.8.8 and (port 80 or port 443)'

Common problems and their diagnosis

Can ping 8.8.8.8 but not google.com

# DNS problem
cat /etc/resolv.conf                   # check nameservers
dig @8.8.8.8 google.com               # test with a known-good DNS
sudo resolvectl flush-caches           # clear local DNS cache
resolvectl status                      # check systemd-resolved

High latency on a specific hop in mtr

# Check if it persists across subsequent hops
# Transient high latency on one hop with normal latency after is not a problem
# Confirm with --report mode over many cycles
mtr -n -r -c 200 destination

Connection refused vs connection timeout

# "Connection refused" = something is listening but the port is actively rejecting
# the connection (service running, wrong port, or firewall sending RST)

# "Connection timed out" = packet is being dropped silently
# (firewall with DROP policy, route to nowhere, host is down)

nc -zv hostname 80    # reports which type of failure

Interface is up but no traffic flows

# Check for ICMP error messages
sudo tcpdump -i eth0 icmp

# Check if ARP is resolving
ip neigh show
ping -c 3 192.168.1.1        # gateway
arping -c 3 192.168.1.1      # ARP-level test

# Check for duplicate IP
arping -D 192.168.1.50       # -D returns nonzero if duplicate found

Frequently Asked Questions

What is the first thing to check when a Linux server cannot reach the internet?

Work through the network stack from the bottom up. First, verify the interface is up and has an IP: ip addr show. Then check that a default gateway exists: ip route show (look for a “default” entry). Ping the gateway to verify layer 2 connectivity: ping -c 3 . If the gateway responds, ping a public IP like 8.8.8.8 to test routing. If that works, test DNS resolution: ping google.com. This sequence isolates whether the problem is the interface, the gateway, routing, or DNS.

What is the difference between traceroute and mtr?

traceroute shows the path a packet takes from your machine to a destination, one hop at a time, by sending packets with incrementing TTL values and recording which router returns an ICMP Time Exceeded message. mtr (Matt’s Traceroute) does the same thing but continuously and interactively, updating the display in real time and calculating per-hop packet loss and latency statistics over many probes. mtr is far more useful for diagnosing intermittent packet loss because it shows which specific hop is dropping packets and by what percentage.

What does it mean when traceroute shows *** for a hop?

Three asterisks (***) mean that traceroute received no response from that hop within the timeout period. This is common and does not necessarily mean the network is broken. Many routers are configured to not respond to ICMP TTL-expired messages as a security measure, even while forwarding traffic normally. The problem is real only if *** appears for the final destination hop (meaning traffic is not reaching the target), or if you see packet loss in mtr at a specific hop that persists in subsequent hops too.

How does tcpdump help with network troubleshooting?

tcpdump captures actual network packets on an interface, letting you see the raw traffic. This is useful when you need to verify that a connection is actually being made (not just that a process thinks it is), confirm a firewall is not silently dropping packets, inspect the contents of unencrypted protocols, or diagnose TCP handshake failures. tcpdump requires root or the CAP_NET_RAW capability. For encrypted traffic (HTTPS, SSH), tcpdump shows the packets exist but not the decrypted content.

What is the curl test and why is it useful for debugging web connectivity?

curl is an HTTP client that shows exactly how a web request progresses, making it easier to isolate problems than a browser. curl -v https://example.com shows the DNS resolution time, TCP connection time, TLS handshake, HTTP request, and response headers. curl —resolve example.com:443:1.2.3.4 https://example.com bypasses DNS and tests a specific IP directly. curl -w ”%{http_code} %{time_total}\n” -o /dev/null -s url shows the response code and total time in one line, useful for monitoring.

How do I tell if a network problem is local (my machine) or upstream (the network/internet)?

The key technique is to isolate each segment. First, check local interface and gateway (ip addr, ip route, ping gateway). If the gateway responds, the problem is not local. Second, traceroute to the destination and look at which hop starts dropping packets. If packet loss begins at a hop outside your network, the issue is upstream. Third, try from a different machine on the same network — if both fail, the issue is your network or ISP; if only one machine fails, the issue is that machine. Fourth, compare results to a known-good external vantage point (e.g., ping from a cloud server).