How to track active TCP connections on Linux with ss

Why the ss command replaced the old netstat

When a server starts responding slowly or rejecting new requests, the first reaction of any system administrator is to inspect the logical wires that keep the machine talking to the rest of the world. In the past, the standard tool for this task was netstat, a classic utility that read network information directly from static text files in the system's virtual directory. In practice, this means it had to scan dozens of text entries every time you requested a report, making the operation heavy and slow on high-traffic servers.

The ss command, which stands for socket statistics, arrived to solve this exact performance bottleneck. It talks much more directly to the Linux operating system kernel, extracting network data at the exact speed it gets processed. For anyone investigating an urgent failure, this agility prevents the diagnostic tool itself from freezing the machine. If you have ever tried how to inspect network routes with the mtr command on Linux to understand packet paths, you will notice that ss follows the same philosophy of surgical precision at the local level.

Understanding what a network socket is in practice

To get the most out of any diagnostic command, it is worth recalling the basic concept of a socket, which is simply the endpoint of a digital phone line where computers talk to each other. Think of it like an electrical outlet on the wall: on one side is the application, like a web server or a database, and on the other is the cable carrying information to another computer on the local network or the internet. When we say an active socket exists, it means there is an established channel exchanging data packets at that exact second.

The TCP protocol, which guarantees orderly and lossless delivery of messages, creates a controlled dialogue where each packet is acknowledged. When many people access a system simultaneously, hundreds or thousands of these channels remain open at the same time. The administrator's challenge is managing to see this crowd of connections without getting lost in overwhelming data, which is precisely where smart filters and options in the ss command come in handy.

How to list all active TCP connections on the server

Running the utility without any parameters on your terminal screen will generate a massive list with hundreds of lines flying past too fast for any human to read. In practice, to isolate only the traffic that matters, we use specific letter combinations that act as selection keys. The most basic command to focus exclusively on conversations using the TCP protocol comes with flags filtering listening and established connection states.

To see what is happening right now on your machine, open your terminal and type the instruction that separates the signal from the noise. Check the practical example below that filters active TCP connections and listening ports:

ss -t -a

In this block, the letter t indicates we want only the TCP protocol, while the letter a asks to show both channels already talking and those just waiting for someone to call. If you notice a port stuck for no apparent reason, knowing how to release busy ports on Linux via terminal is the logical next step to restore the affected service.

Identifying open ports and suspicious services

Leaving ports open unnecessarily is like leaving your front door unlocked while traveling. A misconfigured server can expose internal services to the public internet, attracting attackers or malicious bots. By using ss with the numeric mode enabled, we prevent the system from wasting time trying to translate IP addresses into domain names, which dramatically speeds up responses and ensures you see raw numbers.

To cleanly list all ports listening for incoming connections, we use a server-focused combination. Follow the command structure revealing which applications have their ears glued to the network:

ss -l -n -t

Here, the letter l restricts the report only to sockets in listening state, meaning ports ready to accept new visitors. Combining this with the numeric parameter n ensures we see ports like 80 or 443 instead of generic names. If you want to cross-reference this information to confirm your perimeter security is locked down, it is worth learning how to scan open ports on local network with Nmap to audit external behavior.

Analyzing stagnant connections and the TIME-WAIT state

Often, a server feels sluggish not because the CPU is overloaded, but because old connections refused to die and keep consuming memory. When a TCP conversation ends, it goes through a waiting period called TIME-WAIT, which ensures no stray lost packet arrives late to mess up the next chat. In practice, if thousands of clients disconnect rapidly, these accumulated sockets can exhaust available ports on the machine.

To filter and count only connections stuck in this closing state, we can use an integrated state filter inside the ss command itself. Here is how to isolate this specific scenario before it takes down your application:

ss -t state time-wait

If this number reaches tens of thousands, it means your application opens and closes connections too aggressively, requiring tweaks to Linux kernel parameters like socket reuse. Monitoring these states regularly prevents unpleasant surprises during peak traffic hours.

Final considerations on network monitoring

Mastering the ss command transforms how you view the health and behavior of your server infrastructure. Instead of guessing where the bottleneck lies when an application stutters, you can inspect exact data flows, identify neglected ports, and eliminate stagnant connections in seconds. Combining this checking habit with a consistent audit routine ensures a stable, secure environment ready to grow without fear.

Daily practice with the terminal is what separates a reactive administrator from a professional who anticipates failures before they hit users. Keep testing these filters in staging environments, tweak parameters based on your business load, and keep your servers under absolute control.