Linux Network Troubleshooting: ss, netstat and tcpdump Guide

When a Linux server has network problems, the answer is almost always in three tools: ss for socket-level state, tcpdump for packet-level evidence, and netstat on legacy systems. This guide covers the essential commands, filters and interpretation - plus a systematic workflow that separates application, transport and network layer faults.

ss: Socket Statistics

ss -tlnp                      ! listening TCP sockets with owning process
ss -tunap                     ! all TCP/UDP connections with process info
ss -s                         ! summary statistics
ss -t state established
ss -t state time-wait
ss -t state close-wait        ! often indicates application bugs
ss -tn dport = :443           ! filter by destination port
ss -tn dst 192.168.1.50       ! filter by address
ss -ti dst 192.168.1.50       ! internal TCP info (RTT, cwnd, retrans)

ss reads socket data directly from kernel netlink, making it faster than netstat (which parses /proc/net) and it ships with iproute2 on modern distributions.

Legacy netstat and Equivalents

netstat -tlnp      ! TCP listeners with PIDs      (ss -tlnp)
netstat -ulnp      ! UDP listeners with PIDs      (ss -ulnp)
netstat -an        ! all connections, numeric     (ss -an)
netstat -s         ! protocol statistics (TCP retransmits, UDP errors)
netstat -i         ! interface statistics
netstat -r         ! routing table                (ip route)

tcpdump: Packet Capture

sudo tcpdump -i ens3 -nn -s 0 -w /tmp/capture.pcap port 80
sudo tcpdump -i ens3 -nn host 192.168.1.50
sudo tcpdump -i ens3 -nn 'tcp and dst port 80 and src net 10.0.0.0/8'
sudo tcpdump -i ens3 -nn 'tcp[tcpflags] & (tcp-syn) != 0'   ! SYN packets
sudo tcpdump -i ens3 -nn -A -s 0 'tcp port 80' | grep -E 'GET|POST|HTTP/'
tcpdump -nn -r /tmp/capture.pcap

Always apply a BPF filter to limit data volume; use -w file.pcap for long captures and analyze them later in Wireshark.

Advanced Diagnostic Tools

mtr -n 8.8.8.8                          ! ping + traceroute combined
nmap -sV 192.168.1.50                   ! service version detection
curl -o /dev/null -s -w "HTTP %{http_code} in %{time_total}s
" https://example.com
openssl s_client -connect example.com:443 -servername example.com
iperf3 -c 192.168.1.50 -t 30 -P 4       ! bandwidth test

Diagnostic Workflow

# 1. Is the service listening?
sudo ss -tlnp | grep :80
# 2. Can you connect locally?
curl -v http://localhost:80
# 3. Is the firewall blocking?
sudo iptables -L -n -v | grep 80
# 4. Can you reach the server at all?
ping -c 3 192.168.1.50
# 5. Is there a path to the server?
traceroute -n 192.168.1.50
# 6. Capture packets to see what is happening
sudo tcpdump -i ens3 -nn host 192.168.1.50 and port 80
# 7. Check connection states for anomalies
ss -tn state close-wait | wc -l     ! many CLOSE-WAIT = app bug
ss -tn state time-wait | wc -l      ! many TIME-WAIT = high connection rate

Start with ss for a socket overview, drill into tcpdump for packet evidence, and correlate socket state counts with kernel metrics when the problem is systemic.

Related articles: Linux 网络故障排查：思路、工具与实战场景, Linux 网卡 Bonding 配置实战, and SONiC troubleshooting: packet drops and link issues.

原文链接：https://kindatechnical.com/linux-administration/network-diagnostics-ss-netstat-tcpdump.html