How to monitor active TCP connections on Linux using the ss command

Why the ss command replaced the classic netstat

When an application in a production environment begins to experience slowness or communication failures, the primary suspect is usually the network layer. In the past, system administrators relied on the traditional netstat command to investigate what was happening. However, netstat became obsolete because it read information slowly from the procfs directory, creating bottlenecks on servers under heavy load. To solve this problem, the ss utility was introduced as the modern replacement, extracting socket data directly from the Linux kernel with high efficiency. If you need to dive deeper into your analysis by capturing raw traffic passing through interfaces, check out our guide on how to use tcpdump to capture network packets on Linux during complex scenarios.

Understanding fundamental TCP connection states

To perform quick diagnostics, you must understand the lifecycle of a TCP connection, which manages data flow ensuring packets arrive in the correct order. When we run the ss command, we encounter technical terms indicating the current state of each socket (a communication endpoint between two programs over the network). The ESTAB (Established) state means the connection is active and data is flowing normally between servers. Meanwhile, the TIME-WAIT state indicates that the connection has closed, but the operating system keeps the channel open as a safety measure to catch any delayed packets. Identifying these patterns prevents false alarms and directs the investigation to the right place.

How to list all active TCP connections on your machine

Basic usage of the ss command is extremely straightforward, but it requires parameters to avoid visual clutter in the terminal. A socket is simply a digital input and output port where processes talk to each other across the network. If we type just the command name without filters, it will output a massive list of all active connections and UNIX domain sockets on the system. To focus strictly on the TCP protocol and speed up diagnosis, we use specific modifiers on the command line. In practice, this means we can quickly filter what matters without wasting time interpreting irrelevant data.

1. Open your Linux server terminal with appropriate privileges for network reading.
2. Run the basic command filtering only TCP connections with the protocol parameter.
3. Analyze the generated list to check remote IP addresses and active local ports.

ss -t -a

In this example, the <-t> flag restricts the output exclusively to the TCP protocol, while the <-a> flag forces the utility to show both established connections and listening ports for incoming requests. If you notice that server slowness is not caused by the network but by internal processing, checking overall consumption with the article on High CPU on Linux? How to reduce usage with the htop command helps isolate other bottlenecks.

Identifying open ports and suspicious services on the server

In production environments, knowing which ports are open and which programs own them is a critical matter of operational security. A process listening on an unwanted port can represent a security breach or a forgotten service left behind after testing. The ss command allows you to cross-reference this information by displaying the PID (Process Identifier, a unique number assigned by the system to each running program) associated with each socket. When we combine listening flags with process displays, we can track down exactly which application is consuming ports or spawning stuck connections on the machine.

ss -l -t -p

Using the <-l> flag restricts the listing only to sockets in listening mode, meaning ports ready to accept external connections. The <-p> flag adds the process name and respective PID, facilitating the immediate termination of problematic services. If your open ports audit also involves checking sensitive files and permissions on the server disk, refer to the companion article on how to audit Linux file permissions using the find command.

Diagnosing stuck connections and network bottlenecks

Stuck connections or accumulations in states like SYN-RECV or CLOSE-WAIT are usually the primary symptoms of resource leaks in web applications and databases. The SYN-RECV state indicates that the server received an initial connection request but has not yet completed the three-way handshake, which can point to denial-of-service attacks or traffic overload. Conversely, the CLOSE-WAIT state reveals that the remote application closed the connection, but the local program has not yet released the corresponding file descriptor. Monitoring these counters regularly with advanced filters in ss allows you to anticipate service outages and fine-tune timeouts surgically.

Final considerations on network monitoring in Linux

Mastering the ss command transforms the routine of engineers and system administrators, replacing guesswork with precise diagnostics based on real kernel data. The ability to inspect sockets, track associated processes, and filter TCP states in fractions of a second is indispensable for maintaining the stability of modern infrastructures. By integrating this tool into your daily monitoring arsenal and combining it with complementary packet and hardware resource analysis, you ensure rapid incident response and a much more resilient network operation.