ss Command in Linux made easy

The ss command (Socket Statistics)in Linux is the modern Linux utility for viewing network sockets, active connections, listening ports, and the processes using them. Whether you're troubleshooting a service that won't start, checking open ports, or diagnosing network connectivity issues, ss provides the information quickly and efficiently. It has replaced netstat as the preferred socket inspection tool on most modern Linux distributions.

In this guide, you'll learn how to use the ss command through practical examples, understand its syntax and commonly used options, filter connections by protocol or port, identify which process owns a socket, and troubleshoot common networking problems with confidence.

Examples

ss stands for socket statistics. It shows you every socket your system currently has open, whether that's a TCP connection to a remote server, a UDP port waiting for traffic, or a local Unix domain socket that two processes on the same machine are using to talk to each other.

Under the hood, ss reads socket information straight from the kernel through netlink, instead of parsing /proc/net files line by line the way older tools did. That's the main reason it's noticeably faster on machines with thousands of connections, which matters a lot more than it sounds like once you're debugging a busy production box instead of your laptop.

Think of it as the tool you reach for the moment someone says "is anything listening on port 8080" or "why can't this server reach the database." It answers both in one line.

The basic shape of the command is:

The options control what kind of sockets you see and how much detail comes with them, things like -t for TCP, -u for UDP, -l for listening only. The FILTER part is optional and lets you narrow results down to a specific host, port, or connection state, so instead of scrolling through two hundred lines you can ask for exactly the ones you care about.

This is usually the first thing you run on a new server, just to see what's actually facing the network.

Drop -l and add -a and you get the full TCP picture, including connections already established with other machines.

Handy when you're chasing DNS or DHCP behaviour and don't want TCP noise mixed in.

If you just care about what's open to accept new connections, this cuts everything else out.

This is where the state filter earns its keep. You skip the listening sockets entirely and only see live, active conversations.

This is the one you'll use constantly during troubleshooting, when a deployment fails because a port is "already in use."

Instead of piping through grep, ss lets you write the filter directly, which is faster and won't accidentally match the wrong line.

On a busy box with thousands of sockets, scrolling through a full dump isn't useful. This gives you the numbers instead.

Useful when a monitoring alert says a server is talking to something unexpected and you need to confirm which local socket is involved.

A lot of local services, PHP-FPM and MySQL among them, talk over Unix sockets instead of network ports. This is how you check those.

Once you're comfortable with expressions, you can skip grep entirely and let ss narrow the list itself, port and protocol in one shot.

This one catches almost everyone at least once. Without root privileges, ss will still run, but it silently hides process information for sockets you don't own.

Without a tool like this, diagnosing a "connection refused" error turns into guesswork. You end up restarting services blind, hoping something fixes itself, instead of confirming in two seconds whether the port is even bound. ss turns a vague symptom into a specific, checkable fact.

It also matters because it scales. On a server handling real traffic with thousands of connections cycling through TIME-WAIT and ESTABLISHED states, an older tool crawling through /proc/net line by line can visibly lag, while ss reads the same data from the kernel almost instantly. For anyone doing server hardening work or auditing what's exposed, that speed difference is the reason ss became the default socket-diagnostic tool documented at man7.org instead of its predecessor.