The Troubleshooting Mindset#
Network problems feel random, but they’re not. Every issue lives at a specific layer. If you work systematically from the bottom up, you’ll isolate the problem faster than guessing.
The approach:
1. Is the interface up? (Layer 1/2)
2. Do I have an IP address? (Layer 3)
3. Can I reach the gateway? (Layer 3)
4. Can I reach the internet? (Layer 3)
5. Does DNS resolve? (Layer 7 — but needed before step 6)
6. Can I reach the destination? (Layer 4)
7. Does the application respond? (Layer 7)Each step eliminates a category of problems. If step 3 works but step 4 doesn’t, the problem is routing — not your local config. DNS is tested before port connectivity because most real-world targets are referenced by hostname.
Step 1: Is the Interface Up?#
ip link showLook for state UP on your interface:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UPIf it says state DOWN:
# Bring it up
sudo ip link set eth0 up
# If using NetworkManager
nmcli device connect eth0Still down? Check physical connections — cable plugged in, Wi-Fi enabled, VM network adapter attached.
# Check if cable is physically connected (Ethernet)
ethtool eth0 | grep "Link detected"Step 2: Do I Have an IP Address?#
ip addr show eth0Look for an inet line:
inet 192.168.1.50/24 brd 192.168.1.255 scope global dynamic eth0No IP address? DHCP might have failed:
# Request a new lease
sudo dhclient eth0
# Or with NetworkManager
nmcli connection up "Wired connection 1"
# Check DHCP client logs
journalctl -u NetworkManager | grep -i dhcpStep 3: Can I Reach the Gateway?#
# Find your gateway
ip route show default
# default via 192.168.1.1 dev eth0
# Ping it
ping -c 4 192.168.1.1Gateway unreachable?
- Wrong subnet mask (your IP and gateway aren’t on the same network)
- Gateway is down
- ARP resolution failed
# Check ARP table — do you have the gateway's MAC?
ip neigh show | grep 192.168.1.1
# If missing, try arping
arping -c 2 -I eth0 192.168.1.1Step 4: Can I Reach the Internet?#
# Ping a public IP (bypasses DNS)
ping -c 4 8.8.8.8Gateway responds but 8.8.8.8 doesn’t?
- Firewall blocking outbound traffic
- ISP issue
- NAT/routing misconfiguration
# Trace where packets stop
traceroute 8.8.8.8
# or
mtr -r 8.8.8.8mtr combines ping and traceroute — shows packet loss at each hop:
HOST Loss% Snt Last Avg Best Wrst
1. 192.168.1.1 0.0% 10 1.2 1.1 0.9 1.5
2. 10.0.0.1 0.0% 10 5.3 5.1 4.8 6.2
3. ??? 100.0% 10 0.0 0.0 0.0 0.0100% loss at hop 3 means the problem is between hop 2 and 3 — not your machine.
Step 5: Does DNS Resolve?#
# Test DNS resolution
dig google.com +short
# If dig isn't installed
nslookup google.com
# Or the simplest test
host google.comDNS not resolving?
# Check what resolver you're using
cat /etc/resolv.conf
# or
resolvectl status
# Test with a known-good resolver directly
dig @8.8.8.8 google.com +short
dig @1.1.1.1 google.com +short| Result | Problem |
|---|---|
Works with @8.8.8.8 but not default | Your configured DNS server is broken |
| Doesn’t work with any resolver | Outbound UDP/53 or TCP/53 is blocked |
| Partial failures (some domains work) | DNS server has stale cache or zone issue |
Quick fix — temporarily use a public resolver:
# Test if this fixes the issue
echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.confStep 6: Can I Reach the Destination Port?#
# Test TCP connectivity to a specific port
nc -zv example.com 443
# With a timeout
nc -zv -w 5 example.com 443| Result | Meaning |
|---|---|
Connection succeeded | Port is open, service is reachable |
Connection refused | Host is up, but nothing is listening on that port |
Connection timed out | Firewall is dropping packets, or host is unreachable |
Connection refused vs timeout:
- Refused = the host received your packet and explicitly rejected it (the service isn’t running)
- Timeout = your packet never got a response (firewall, wrong IP, host down)
This distinction is critical — refused means network is fine, it’s an application problem.
Step 7: Does the Application Respond?#
# HTTP — check response code and headers
curl -I https://example.com
# Verbose — shows DNS, TCP, TLS, and HTTP details
curl -v https://example.com
# Show timing breakdown
curl -w "\nDNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://example.comThe timing breakdown tells you where the slowness is:
| Phase | High time means |
|---|---|
| DNS | Slow resolver |
| Connect | Network latency or congestion |
| TLS | Certificate issues or slow handshake |
| First byte | Server is slow processing the request |
tcpdump: When You Need to See Packets#
When higher-level tools don’t explain the problem, capture the actual traffic:
Basic captures#
# All traffic on an interface
sudo tcpdump -i eth0 -n
# Traffic to/from a specific host
sudo tcpdump -i eth0 host 10.0.1.50 -n
# Traffic on a specific port
sudo tcpdump -i eth0 port 443 -n
# Only show SYN packets (new connections)
sudo tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn) != 0' -nSave to file for Wireshark analysis#
sudo tcpdump -i eth0 -w /tmp/capture.pcap -c 500What to look for#
| Symptom in tcpdump | Likely problem |
|---|---|
| SYN sent, no SYN-ACK back | Firewall dropping, host down, wrong route |
| SYN-ACK received, then RST | Port closed or service crashed |
| Retransmissions | Packet loss, congestion, MTU issues |
| Connection established, no data | TLS failure or application-level issue |
Common Scenarios#
“I can’t reach the internet”#
# Quick diagnosis
ping -c 2 192.168.1.1 # Gateway?
ping -c 2 8.8.8.8 # Internet (no DNS)?
ping -c 2 google.com # DNS working?| Gateway | 8.8.8.8 | google.com | Problem |
|---|---|---|---|
| ✗ | ✗ | ✗ | Local config (IP, interface, cable) |
| ✓ | ✗ | ✗ | Routing or ISP |
| ✓ | ✓ | ✗ | DNS |
| ✓ | ✓ | ✓ | It works — problem is elsewhere |
“DNS isn’t resolving”#
# Confirm it's actually DNS
ping -c 2 8.8.8.8 # Works? Then network is fine
dig google.com # Fails? DNS issue confirmed
# Is the resolver reachable?
ping -c 2 $(grep nameserver /etc/resolv.conf | head -1 | awk '{print $2}')
# Try a different resolver
dig @1.1.1.1 google.com
# Check if port 53 is blocked
nc -zvu 8.8.8.8 53“Connection refused”#
# Is the service actually running?
ss -tlnp | grep :80
# If not listening, check the service
systemctl status nginx
journalctl -u nginx --since "5 min ago"
# Is it bound to the right address?
# 127.0.0.1:80 = local only
# 0.0.0.0:80 = all interfaces
ss -tlnp sport = :80“Connection timeout”#
# Is there a firewall blocking it?
sudo iptables -L -n | grep -i drop
sudo nft list ruleset | grep drop
# Can you reach the host at all?
ping -c 2 target-host
# Is the port open from a different machine?
# (test from another host to rule out local firewall)
# Trace where it stops
traceroute -p 80 target-host“It’s slow”#
# Where is the latency?
curl -w "DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://slow-site.com
# Check for packet loss
mtr -r slow-site.com
# Check for retransmissions
ss -ti dst slow-site.com | grep retrans
# Check MTU issues
ping -c 4 -M do -s 1472 slow-site.comQuick Reference#
| Question | Command |
|---|---|
| Is the interface up? | ip link show |
| Do I have an IP? | ip addr show |
| What’s my gateway? | ip route show default |
| Can I reach the gateway? | ping -c 4 GATEWAY |
| Can I reach the internet? | ping -c 4 8.8.8.8 |
| Does DNS work? | dig google.com +short |
| Is a port open? | nc -zv HOST PORT |
| What’s listening locally? | ss -tlnp |
| Where do packets stop? | traceroute HOST or mtr HOST |
| Show me the packets | sudo tcpdump -i eth0 host HOST -n |
| HTTP timing | curl -w "..." -o /dev/null -s URL |
| Check firewall rules | sudo iptables -L -n |
Best Practices#
- Always work bottom-up — don’t debug DNS if you can’t ping the gateway
- Use
pingto an IP (like 8.8.8.8) to separate network issues from DNS issues - Learn the difference between “refused” and “timeout” — they point to completely different problems
- Use
mtrinstead oftraceroute— it shows packet loss percentage at each hop - Use
curl -vfor HTTP issues — it shows every step of the connection - Capture packets with
tcpdumpwhen nothing else explains the problem — the answer is always in the packets - When troubleshooting from a remote server, don’t lock yourself out — test firewall changes with a timeout safety net
- Document what you checked — when escalating to someone else, “I confirmed the gateway responds but packets stop at hop 3” is far more useful than “the network is broken”