Network Troubleshooting Toolkit

When something goes wrong with network connectivity on your VPS — a website won't load, DNS isn't resolving, connections are timing out, or packets are being dropped — you need the right tools to diagnose the problem. This guide covers every essential network troubleshooting utility available on Linux, with practical examples for both Debian/Ubuntu and AlmaLinux/RHEL.

What You'll Learn

Test connectivity with ping

Query DNS records with dig and nslookup

Trace routes with traceroute and mtr

Inspect sockets and ports with ss and netstat

Capture and analyze packets with tcpdump

Manage interfaces and routes with the ip command

Installing the Tools

Most of these tools are pre-installed. If any are missing:

Debian / Ubuntu

sudo apt install dnsutils traceroute mtr-tiny net-tools tcpdump curl

AlmaLinux / RHEL

sudo dnf install bind-utils traceroute mtr net-tools tcpdump curl

Quick Reference

Problem	Tool	Quick Command
Is the host reachable?	ping	ping -c 4 example.com
Is DNS resolving?	dig	dig example.com
What's my DNS config?	nslookup	nslookup example.com
Where is the path failing?	traceroute	traceroute example.com
Packet loss on which hop?	mtr	mtr example.com
What ports are open?	ss	ss -tlnp
Who's connected?	ss / netstat	ss -tnp state established
What's on the wire?	tcpdump	sudo tcpdump -i eth0 port 80
What's my IP / interface?	ip	ip addr show
Is the HTTP endpoint up?	curl	curl -Ivo /dev/null example.com

1. ping / ping6

The simplest connectivity test. Sends ICMP echo requests and measures round-trip time and packet loss.

Basic ping usage

# Send 4 pings (Linux pings forever by default without -c)
ping -c 4 example.com

# Ping with a specific packet size (test MTU issues)
ping -c 4 -s 1472 example.com

# Ping an IPv6 address
ping6 -c 4 example.com

# Ping with 0.2 second interval (faster)
sudo ping -c 20 -i 0.2 example.com

# Ping and show timestamps
ping -c 4 -D example.com

Example output

PING example.com (93.184.216.34) 56(84) bytes of data.
64 bytes from 93.184.216.34: icmp_seq=1 ttl=56 time=11.2 ms
64 bytes from 93.184.216.34: icmp_seq=2 ttl=56 time=11.1 ms
64 bytes from 93.184.216.34: icmp_seq=3 ttl=56 time=11.3 ms
64 bytes from 93.184.216.34: icmp_seq=4 ttl=56 time=11.2 ms

--- example.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 11.100/11.200/11.300/0.071 ms

💡 Tip: Some hosts block ICMP (ping). If ping fails but curl works, the host is up — it's just filtering ICMP.

2. dig (DNS lookup)

dig (Domain Information Groper) is the most powerful DNS query tool. It shows full query details including TTL, authoritative servers, and response flags.

Basic dig queries

# Look up A record (IPv4 address)
dig example.com

# Short answer only
dig +short example.com

# Look up specific record types
dig example.com AAAA        # IPv6 address
dig example.com MX          # Mail servers
dig example.com NS          # Nameservers
dig example.com TXT         # TXT records (SPF, DKIM, etc.)
dig example.com CNAME       # Canonical name
dig example.com SOA         # Start of Authority
dig example.com ANY         # All records (may not always work)

Advanced dig usage

# Query a specific DNS server
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com

# Trace the full DNS delegation chain
dig +trace example.com

# Check reverse DNS (PTR record)
dig -x 93.184.216.34

# Show only the answer section
dig +noall +answer example.com

# Check if DNS is using DNSSEC
dig +dnssec example.com

# Query with TCP instead of UDP
dig +tcp example.com

# Check TTL (time to live) — how long until the record expires
dig +noall +answer +ttlid example.com

Example dig output

; <<>> DiG 9.18.28 <<>> example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; ANSWER SECTION:
example.com.        3600    IN    A    93.184.216.34

;; Query time: 11 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Feb 25 10:00:00 UTC 2026
;; MSG SIZE  rcvd: 56

Reading dig Output

Field	Meaning
status: NOERROR	Query successful. `NXDOMAIN` = domain doesn't exist, `SERVFAIL` = DNS server error
flags: qr rd ra	qr=response, rd=recursion desired, ra=recursion available, aa=authoritative answer
3600	TTL in seconds — how long the record is cached
SERVER	The DNS resolver that answered your query

3. nslookup

nslookup is a simpler DNS query tool. While dig is preferred for detailed diagnostics, nslookup is useful for quick lookups and is available on Windows, Mac, and Linux.

nslookup usage

# Basic lookup
nslookup example.com

# Query a specific DNS server
nslookup example.com 8.8.8.8

# Look up specific record types
nslookup -type=MX example.com
nslookup -type=TXT example.com
nslookup -type=NS example.com
nslookup -type=AAAA example.com

# Reverse DNS lookup
nslookup 93.184.216.34

Example output

Server:    127.0.0.53
Address:   127.0.0.53#53

Non-authoritative answer:
Name:   example.com
Address: 93.184.216.34

💡 dig vs nslookup: Use dig for detailed debugging (TTL, delegation traces, DNSSEC). Use nslookup for quick "does this domain resolve?" checks.

4. traceroute

traceroute shows the path packets take from your server to a destination, listing every router (hop) along the way. Useful for identifying where in the network path a problem occurs.

traceroute usage

# Basic traceroute
traceroute example.com

# Use ICMP instead of UDP (more likely to get through firewalls)
sudo traceroute -I example.com

# Use TCP on port 443 (best for firewalled paths)
sudo traceroute -T -p 443 example.com

# IPv6 traceroute
traceroute6 example.com

# Limit to 20 hops (default is 30)
traceroute -m 20 example.com

# Don't resolve hostnames (faster)
traceroute -n example.com

Example output

traceroute to example.com (93.184.216.34), 30 hops max, 60 byte packets
 1  gateway (10.0.0.1)  0.5 ms  0.4 ms  0.4 ms
 2  isp-router (203.0.113.1)  1.2 ms  1.1 ms  1.3 ms
 3  * * *
 4  core-router (198.51.100.5)  8.5 ms  8.4 ms  8.6 ms
 5  edge-router (192.0.2.10)  11.2 ms  11.1 ms  11.3 ms
 6  93.184.216.34  11.5 ms  11.4 ms  11.6 ms

Reading traceroute Output

Output	Meaning
* * *	The hop didn't respond — it may be blocking ICMP/UDP. Not always a problem.
!H	Host unreachable
!N	Network unreachable
!X	Administratively filtered (firewall)

5. mtr (My Traceroute)

mtr combines ping and traceroute into a single tool, continuously probing each hop and showing real-time packet loss and latency statistics. It's the best tool for diagnosing intermittent network issues.

mtr usage

# Interactive mode (live updating display)
mtr example.com

# Report mode — run 100 cycles then print results
mtr -r -c 100 example.com

# Use TCP on port 443
mtr -T -P 443 example.com

# Don't resolve hostnames
mtr -n example.com

# Wide report with both hostnames and IPs
mtr -rw example.com

# Generate a report suitable for sending to support
mtr -rwzbc 200 example.com > mtr-report.txt

Example mtr report

HOST: my-vps                      Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- gateway                     0.0%   100    0.5   0.5   0.3   1.2   0.1
  2.|-- isp-router                  0.0%   100    1.2   1.3   1.0   2.5   0.2
  3.|-- ???                        100.0   100    0.0   0.0   0.0   0.0   0.0
  4.|-- core-router                 0.0%   100    8.5   8.6   8.2   9.1   0.2
  5.|-- edge-router                 2.0%   100   11.2  11.3  11.0  15.2   0.5
  6.|-- example.com                 2.0%   100   11.5  11.4  11.1  14.8   0.4

Reading mtr Output

Column	Meaning
Loss%	Percentage of packets lost at this hop
Snt	Packets sent
Last	Most recent round-trip time (ms)
Avg	Average round-trip time
Best / Wrst	Best and worst round-trip times
StDev	Standard deviation — high values indicate jitter

📖 In-depth guide: For a comprehensive deep dive into mtr including advanced analysis, bidirectional testing, and how to read complex patterns, see our dedicated MTR Network Diagnostics guide.

💡 Key insight: If packet loss appears at one hop but not at subsequent hops, the router is just deprioritizing ICMP responses — that's not a real problem. Only worry when loss persists from a hop all the way to the destination.

6. ss (Socket Statistics)

ss is the modern replacement for netstat. It's faster, more detailed, and available on all modern Linux distributions. Use it to see what ports are open, what's listening, and who's connected.

Listing listening ports

# Show all TCP listening ports with process names
sudo ss -tlnp

# Show all UDP listening ports
sudo ss -ulnp

# Show both TCP and UDP
sudo ss -tulnp

# Flags:
#   -t  TCP
#   -u  UDP
#   -l  Listening sockets only
#   -n  Don't resolve service names (show port numbers)
#   -p  Show the process using each socket

Example output

State    Recv-Q   Send-Q   Local Address:Port   Peer Address:Port   Process
LISTEN   0        511      0.0.0.0:80            0.0.0.0:*           users:(("nginx",pid=1234,fd=6))
LISTEN   0        511      0.0.0.0:443           0.0.0.0:*           users:(("nginx",pid=1234,fd=7))
LISTEN   0        128      0.0.0.0:22            0.0.0.0:*           users:(("sshd",pid=789,fd=3))
LISTEN   0        80       127.0.0.1:3306        0.0.0.0:*           users:(("mariadbd",pid=456,fd=20))

Viewing active connections

# Show all established TCP connections
ss -tnp state established

# Show connections to a specific port
ss -tnp state established '( dport = :443 )'

# Count connections per IP (find heavy users or attackers)
ss -tn state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

# Show socket memory usage
ss -tm

# Show TCP connection details (window size, RTT, etc.)
ss -ti

# Show all sockets (including Unix domain sockets)
ss -a

# Filter by source or destination
ss -tn dst 10.0.0.0/24
ss -tn src :443

7. netstat (Legacy)

netstat is the older version of ss. It's still widely used and found in many guides. It requires the net-tools package.

netstat usage

# Show all listening TCP ports with processes
sudo netstat -tlnp

# Show all listening UDP ports
sudo netstat -ulnp

# Show all active connections
sudo netstat -tnp

# Show listening and established connections
sudo netstat -tunap

# Show routing table
netstat -rn

# Show interface statistics
netstat -i

# Count connections by state
netstat -ant | awk '{print $6}' | sort | uniq -c | sort -rn

💡 Tip: Prefer ss over netstat on modern systems. ss is faster (reads directly from kernel), pre-installed, and has more powerful filtering.

8. tcpdump (Packet Capture)

tcpdump captures raw network packets for detailed analysis. It's the most powerful diagnostic tool when you need to see exactly what's happening on the wire.

Basic tcpdump usage

# Capture all traffic on eth0
sudo tcpdump -i eth0

# Capture only 100 packets
sudo tcpdump -i eth0 -c 100

# Don't resolve hostnames (faster output)
sudo tcpdump -i eth0 -n

# Capture on all interfaces
sudo tcpdump -i any

Filtering Traffic

tcpdump filters

# Only HTTP traffic (port 80)
sudo tcpdump -i eth0 -n port 80

# Only HTTPS traffic
sudo tcpdump -i eth0 -n port 443

# Only DNS traffic
sudo tcpdump -i eth0 -n port 53

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

# Only traffic FROM a specific source
sudo tcpdump -i eth0 -n src 10.0.0.5

# Only traffic TO a specific destination
sudo tcpdump -i eth0 -n dst 10.0.0.5

# Combine filters with and/or
sudo tcpdump -i eth0 -n 'port 80 and host 10.0.0.5'
sudo tcpdump -i eth0 -n 'port 80 or port 443'

# Only SYN packets (new connections)
sudo tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-syn != 0'

# Only ICMP (ping) traffic
sudo tcpdump -i eth0 -n icmp

Saving and Reading Captures

Save and read captures

# Save to a file (can open in Wireshark later)
sudo tcpdump -i eth0 -n -w capture.pcap

# Save with a packet count limit
sudo tcpdump -i eth0 -n -c 1000 -w capture.pcap

# Read a saved capture
tcpdump -r capture.pcap

# Read with filters
tcpdump -r capture.pcap port 443

# Show packet contents in hex and ASCII
sudo tcpdump -i eth0 -n -X port 80 -c 5

# Show full packet details (verbose)
sudo tcpdump -i eth0 -n -vvv port 80 -c 5

⚠️ Caution: tcpdump can capture sensitive data (credentials, tokens) in unencrypted traffic. Only use it for troubleshooting, and delete capture files when done. HTTPS traffic will show headers but encrypted payloads.

9. ip Command

The ip command (from iproute2) is the modern replacement for ifconfig and route. It manages interfaces, addresses, routes, and more.

Viewing network information

# Show all interfaces and their IP addresses
ip addr show
ip a          # short form

# Show a specific interface
ip addr show eth0

# Show only IPv4 addresses
ip -4 addr show

# Show only IPv6 addresses
ip -6 addr show

# Show link status (up/down, MTU, MAC address)
ip link show

# Show routing table
ip route show
ip r          # short form

# Show the default gateway
ip route show default

# Show which interface/route will be used to reach a destination
ip route get 8.8.8.8

# Show ARP/neighbor table
ip neigh show

Temporary network changes (non-persistent)

# Bring an interface up/down
sudo ip link set eth0 up
sudo ip link set eth0 down

# Add an IP address
sudo ip addr add 10.0.0.10/24 dev eth0

# Remove an IP address
sudo ip addr del 10.0.0.10/24 dev eth0

# Add a static route
sudo ip route add 10.0.1.0/24 via 10.0.0.1

# Delete a route
sudo ip route del 10.0.1.0/24

# Flush all addresses on an interface
sudo ip addr flush dev eth0

⚠️ Warning: Changes made with ip are temporary and lost on reboot. For permanent changes, see our Static IP Configuration guide.

10. curl & wget

While not strictly network diagnostic tools, curl and wget are essential for testing HTTP/HTTPS connectivity, checking response codes, and measuring response times.

curl for diagnostics

# Check HTTP status code
curl -o /dev/null -s -w "%{http_code}
" https://example.com

# Show response headers
curl -I https://example.com

# Verbose output — show TLS handshake, headers, timing
curl -v https://example.com

# Measure connection timing
curl -o /dev/null -s -w "DNS: %{time_namelookup}s
Connect: %{time_connect}s
TLS: %{time_appconnect}s
First byte: %{time_starttransfer}s
Total: %{time_total}s
" https://example.com

# Test from a specific IP (useful for load balancer debugging)
curl --resolve example.com:443:93.184.216.34 https://example.com

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

# Test a specific port
curl -v telnet://example.com:3306

# Check your public IP
curl ifconfig.me

wget for connectivity tests

# Download and discard (just test connectivity)
wget -q --spider https://example.com && echo "OK" || echo "FAIL"

# Download with timing info
wget --server-response https://example.com -O /dev/null 2>&1 | head -20

11. Common Troubleshooting Scenarios

"Website is down"

Systematic diagnosis

# 1. Is DNS resolving?
dig +short yourdomain.com

# 2. Is the server reachable?
ping -c 4 yourdomain.com

# 3. Is the web server listening?
sudo ss -tlnp | grep -E ':80|:443'

# 4. Is the port accessible from outside?
curl -Ivo /dev/null https://yourdomain.com

# 5. Check the web server logs
sudo journalctl -u nginx -n 50
sudo tail -50 /var/log/nginx/error.log

"DNS isn't resolving"

DNS debugging

# 1. Check current DNS resolver
cat /etc/resolv.conf

# 2. Test with the configured resolver
dig yourdomain.com

# 3. Test with a public resolver (bypass local DNS)
dig @8.8.8.8 yourdomain.com
dig @1.1.1.1 yourdomain.com

# 4. Trace the delegation chain
dig +trace yourdomain.com

# 5. Check if it's a local caching issue
sudo systemd-resolve --flush-caches   # systemd-resolved
# or
sudo systemctl restart systemd-resolved

"Connection keeps timing out"

Timeout debugging

# 1. Is the port actually open?
sudo ss -tlnp | grep :8080

# 2. Is the firewall blocking it?
sudo iptables -L -n | grep 8080    # iptables
sudo ufw status                     # UFW
sudo firewall-cmd --list-all        # firewalld (AlmaLinux/RHEL)

# 3. Test the connection locally on the server
curl -v localhost:8080

# 4. Test from your machine
curl -v your-vps-ip:8080

# 5. Is something between you and the server blocking it?
sudo tcpdump -i eth0 -n port 8080 -c 20

"High latency / packet loss"

Latency and loss diagnosis

# 1. Quick ping test
ping -c 20 yourdomain.com

# 2. Full path analysis with mtr
mtr -rwzbc 200 yourdomain.com

# 3. Check if it's local resource exhaustion
ss -s                    # Socket summary
cat /proc/net/sockstat   # Kernel socket stats

# 4. Check for network interface errors
ip -s link show eth0

Next Steps

You now have a complete toolkit for diagnosing network issues on your VPS. Here are some related topics:

Networking

→ MTR Network Diagnostics → Private Networks → DNS Zones → SSH Tunneling & Port Forwarding

Security & Firewalls

→ UFW Basics → Fail2Ban Guide → DDoS-Filtered IP

Back to Cloud VPS Docs Deployment Guides

📋 Guide Contents

What You'll Learn

Installing the Tools

Quick Reference

1. ping / ping6

2. dig (DNS lookup)

Reading dig Output

3. nslookup

4. traceroute

Reading traceroute Output

5. mtr (My Traceroute)

Reading mtr Output

6. ss (Socket Statistics)

7. netstat (Legacy)

8. tcpdump (Packet Capture)

Filtering Traffic

Saving and Reading Captures

9. ip Command

10. curl & wget

11. Common Troubleshooting Scenarios

"Website is down"

"DNS isn't resolving"

"Connection keeps timing out"

"High latency / packet loss"

Related Documentation

Next Steps

Networking

Security & Firewalls