Skip to main content

Linux Network Diagnostics: ping, traceroute, ss, tcpdump

VDS / VPS · 19.04.2026 · 5 min read
Illustration for “Linux Network Diagnostics: ping, traceroute, ss, tcpdump”

When a server is unreachable or running slowly, you need to know where to look for the problem. Here's a complete arsenal of commands for network diagnostics on a VPS.

1. ping — basic availability check

# Check host availability
ping google.com

# IPv6 ping
ping6 google.com

# Send 5 packets and stop
ping -c 5 8.8.8.8

# Ping with a 1400-byte packet size (MTU check)
ping -s 1400 -c 3 google.com

2. traceroute / tracepath — packet route

# Standard traceroute
traceroute google.com

# Use ICMP (like ping)
traceroute -I google.com

# Traceroute over IPv6
traceroute6 google.com

# tracepath — no root privileges required
tracepath google.com

3. mtr — the best tool for diagnosing packet loss

# Installation
sudo apt install mtr -y

# Interactive mode (updates in real time)
mtr google.com

# Single-page report (handy for support tickets)
mtr --report google.com

# 100 packets, numeric output only
mtr -r -c 100 -n google.com

4. ss and netstat — open ports and connections

# All open TCP ports (listening)
ss -tlnp

# All connections (TCP + UDP)
ss -tunap

# Legacy netstat (equivalent)
netstat -tlnp

# See who's listening on port 80
ss -tlnp | grep :80
# or
lsof -i :80

5. nmap — port scanning

# Installation
sudo apt install nmap -y

# Scan your own open ports
sudo nmap -sS -O localhost

# Check port availability on a remote host
nmap -p 80,443,22 192.168.1.1

# UDP scan
sudo nmap -sU -p 53,123 google.com

6. tcpdump — packet capture

# All traffic on interface eth0
sudo tcpdump -i eth0

# HTTP traffic on port 80 only
sudo tcpdump -i eth0 port 80

# Traffic from a specific IP
sudo tcpdump -i eth0 src 192.168.1.100

# Save to a file for analysis in Wireshark
sudo tcpdump -i eth0 -w /tmp/capture.pcap

Cheat sheet: what to use when

ProblemTool
Site unreachableping → traceroute → mtr
Port not listeningss -tlnp, lsof -i
Packets are being lostmtr --report google.com
Need to know the routetraceroute / ip route
Server's open portsnmap localhost
Debugging a specific servicetcpdump port N
💡 mtr for support: When writing a support ticket about network issues — always attach the output of mtr --report google.com and mtr --report YOUR_SERVER_IP (both sides). This gives the full picture.

Common Errors and What They Mean

MessageCause
ping: connect: Network is unreachableThe server has no default route — usually after manually editing the routing table or a DHCP failure on the interface
traceroute: command not foundThe traceroute package is not part of the minimal Debian/Ubuntu image by default — install it separately
bind: Address already in useThe port is already taken by another process; ss -tlnp | grep :PORT reveals which one, not nmap
tcpdump: You don't have permission to capture on that deviceThe command was run without sudo — packet capture requires CAP_NET_RAW, a regular user is not enough
nmap shows a port open from inside but closed from outsideThe firewall (ufw/iptables) blocks inbound connections from outside but allows traffic from localhost — a classic point of confusion during self-diagnosis
mtr shows 100% loss on just one intermediate hopMany provider routers deliberately deprioritize ICMP on transit nodes — this is not real packet loss; look at the loss on the last hop (the target) instead

When These Tools Are Not Enough

  • You need continuous monitoring with history and alerts, not a one-off snapshot — these commands capture a single moment; for history you need a dedicated service such as Zabbix or Prometheus
  • The problem is at the application level, not the network (a slow SQL query, a memory leak) — network tools show connectivity and an open port, not the cause of latency inside the backend
  • You need to meaningfully inspect encrypted TLS traffic — tcpdump captures the packets, but without the server's private key the HTTPS payload stays encrypted
  • The diagnosis needs to cover the client's network, not the server's — from the server you only see its side of the path, and the problem often sits in the client's own provider network

Bundling Diagnostics into One Report

For a support ticket, it's more useful to attach a single file with all the results at once instead of describing the symptoms in words. Continuous monitoring instead of one-off snapshots is covered in the articles on Netdata and on pairing Grafana with Prometheus.

# Collect basic diagnostics into a single file with one command
{
  echo "--- ping ---"; ping -c 4 8.8.8.8
  echo "--- route ---"; ip route show
  echo "--- listening ports ---"; ss -tlnp
  echo "--- mtr ---"; mtr --report -c 20 8.8.8.8
} > /tmp/netdiag-$(date +%Y%m%d-%H%M).txt
Was this article helpful?
← Back to Knowledge Base Ask Support