Linux Network Troubleshooting: Mastering ss, netstat, and tcpdump

When a microservice suddenly stops talking to its database or a web server starts throwing 502 errors, the panic is real. During a recent incident where I was debugging an Nginx 502 Bad Gateway: How to Troubleshoot Upstream Issues, I had to look past the application logs and get into the raw socket state of the host. If you’re stuck, you need to know exactly which tools to reach for to diagnose network connection Linux issues without guessing.

The Modern Standard: Why the ss Command Rules

For years, we all lived in the netstat era. It was reliable, but it was slow on busy servers because it parsed /proc/net/tcp to gather information. The ss command (socket statistics) is the modern successor. It’s part of the iproute2 package and retrieves data directly from the kernel space, which makes it significantly faster when you're querying thousands of open sockets.

If you’re comparing netstat vs ss, the choice is clear for modern environments. ss provides more detailed TCP information, including congestion window sizes and retransmission counts, which are lifesavers when debugging intermittent latency.

Here is how I usually check what’s listening on my servers:

Bash
# Show listening TCP ports with process names
ss -tulpn

• -t: TCP sockets
• -u: UDP sockets
• -l: Listening sockets
• -p: Show processes (requires sudo)
• -n: Don't resolve service names (faster)

When to use netstat vs ss

While ss is the modern choice, netstat is still found on many legacy systems. If you find yourself on an older CentOS 6 box, you might be forced to use netstat.

Getting Granular with a tcpdump Tutorial

Sometimes, the socket state looks perfect, but the packets just aren't getting through. This is where tcpdump becomes non-negotiable. It’s the Swiss Army knife of network packet analysis.

When I need to verify that traffic is actually hitting a specific interface, I run a basic capture:

Bash
# Capture traffic on port 80
sudo tcpdump -i eth0 port 80 -nn -v

The -nn flag is crucial—it prevents tcpdump from trying to resolve IP addresses to hostnames and ports to service names, which speeds up the capture and keeps your terminal from lagging.

If you're investigating Docker Compose Networking: How to Fix Service Connectivity Issues, you might need to sniff traffic on a specific virtual bridge interface. I’ve spent hours chasing packets only to realize I was listening on eth0 while the container traffic was routed through br-1234. Always double-check your interface with ip addr before starting a capture.

Putting it all together

When I'm in the middle of a production fire, my workflow follows a logical path:

1. Check the socket state: Use ss -tulpn to ensure the service is actually listening on the correct interface.
2. Verify process ownership: Use Linux Process Management: Using lsof and fuser for Zombie Processes if you suspect a port conflict or a hung process.
3. Capture the flow: Use tcpdump to see if the SYN packets are arriving or if they’re getting dropped by a firewall or routing rule.

FAQ: Common Troubleshooting Questions

Q: Why does ss show a socket as ESTAB but I can't connect? A: You might have a firewall (iptables or nftables) dropping packets, or there could be a routing issue where the server receives the request but the return path is blocked. Check your iptables -L rules.

Q: Is tcpdump safe to run in production? A: Yes, but be careful. Capturing everything on a high-traffic interface will fill your disk and spike CPU usage. Always use filters (like port numbers or source/destination IPs) to narrow the scope.

Q: What is the best way to read a tcpdump file later? A: Use the -w flag to write to a file: sudo tcpdump -i any port 443 -w capture.pcap. You can then move that file to your local machine and open it in Wireshark for a much better visual analysis.

I still occasionally forget to use the -n flag in tcpdump, leading to a terminal full of reverse-DNS lookups that slow everything down. Next time, I’ll remember that the kernel is usually faster than the network, and my tools should reflect that. Troubleshooting is rarely about having the perfect command; it's about having a repeatable process that helps you rule out variables one by one.