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
| Problem | Tool |
|---|---|
| Site unreachable | ping → traceroute → mtr |
| Port not listening | ss -tlnp, lsof -i |
| Packets are being lost | mtr --report google.com |
| Need to know the route | traceroute / ip route |
| Server's open ports | nmap localhost |
| Debugging a specific service | tcpdump 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
| Message | Cause |
|---|---|
| ping: connect: Network is unreachable | The server has no default route — usually after manually editing the routing table or a DHCP failure on the interface |
| traceroute: command not found | The traceroute package is not part of the minimal Debian/Ubuntu image by default — install it separately |
| bind: Address already in use | The 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 device | The 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 outside | The 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 hop | Many 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