contact@linuxtpoint.com
Linuxtpoint
Candid photograph of a Linux server terminal with a soft olive-green glow against a dark slate background, conveying a calm technical atmosphere.

Step-by-step guides for system administrators — covering command-line basics, web server setup, and preparation material for technical interviews.

Browse Tutorials

Using Netstat And Ss To Monitor Linux Network Connections

Network connections reveal what a Linux host is doing beyond its running processes. By inspecting listening ports, established sessions, and connection states, an administrator can troubleshoot a web server, check firewall behaviour, or spot an unexpected service.

netstat remains familiar to many system administrators, while ss is the faster and more modern utility found on current RHEL, CentOS Stream, and Fedora systems. Both display sockets, but they differ in availability, performance, and the level of detail they provide.

This matters on systems ranging from a small office server in Brisbane to a production virtual machine hosted in Sydney. Australian administrators also regularly investigate NBN-related connectivity, carrier-grade NAT, and the effect of regional links when a service appears reachable locally but not from another state.

The examples below use standard command-line tools and practical checks. Run them with a normal account first, then add sudo when process ownership or full socket information requires elevated privileges.

Checking Listening Ports With Netstat

On older installations, netstat is supplied by the net-tools package. Install it on a RHEL-compatible system with:

sudo dnf install net-tools

To display TCP and UDP sockets that are listening, use:

sudo netstat -tulnp

The options request TCP, UDP, listening sockets, numeric addresses and ports, plus the owning process. Numeric output avoids delays caused by reverse DNS lookups. A line such as 0.0.0.0:80 means the service is listening on every IPv4 interface, whereas 127.0.0.1:8080 is available only from the local machine.

Useful netstat checks include:

A web administrator in Melbourne might use this output to confirm that Nginx is bound to port 443, while a database service remains restricted to localhost. The result should always be compared with the intended firewall policy rather than treated as proof that remote access is working.

Using Ss For Faster Socket Inspection

ss is normally installed with the iproute tools and is preferred on modern distributions. Its basic listening-port command is:

sudo ss -tulnp

For established TCP sessions, run:

ss -tan state established

To identify which process owns each socket, add -p. To show listening sockets in a compact form, use ss -ltn; adding -4 or -6 limits the result to IPv4 or IPv6. This is useful when a daemon works over IPv4 but has an incorrect IPv6 binding.

The following filters are especially practical:

ss reads socket information efficiently from the kernel, which makes it more suitable for busy servers. When an Nginx reverse proxy is handling traffic from clients across Perth, Adelaide, and regional networks, a quick ss query can show whether connections are reaching the proxy or stopping upstream.

Reading Connection States And Addresses

TCP states provide clues about the stage of a connection. LISTEN indicates a service waiting for clients, ESTABLISHED represents an active session, and TIME-WAIT is normal after a connection closes. A large number of SYN-RECV entries may indicate a busy service, a slow client, or a possible SYN flood.

IPv4 addresses can be private, public, or local to the host. Addresses in ranges such as 10.0.0.0/8 commonly belong to internal networks, while 127.0.0.1 is loopback. On Australian residential connections, carrier-grade NAT can mean that an NBN customer does not receive a directly reachable public IPv4 address, so testing inbound access from inside the same network can be misleading.

Check both ends of a session where possible:

ss -tnp | grep ':443'
sudo ss -ltnp

If a service listens on 0.0.0.0 but remote clients still fail, inspect firewalld, cloud security groups, and upstream router rules. A Sydney VPS may have a permissive local firewall while its hosting provider blocks the port externally.

Combining Socket Data With Firewall Checks

Socket tools show what the kernel sees; they do not replace firewall inspection. On Fedora or RHEL, check active firewalld zones with:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

Compare allowed services and ports with the listeners reported by ss. For example, port 8080 may be open in the process list but intentionally blocked from the public network because it is reserved for an internal application server.

A short diagnostic sequence helps avoid guesswork:

When documenting results for a team, include the command, timestamp, hostname, and timezone. Recording Australian Eastern Standard Time or Australian Eastern Daylight Time clearly prevents confusion between an overnight incident in Sydney and the corresponding time in Perth.

Building A Repeatable Monitoring Routine

For routine administration, save focused commands rather than repeatedly scanning large outputs. This example checks HTTPS listeners and established connections:

#!/usr/bin/env bash
printf 'Host: %s\n' "$(hostname -f)"
date
printf '\nHTTPS listeners:\n'
sudo ss -ltnp 'sport = :443'
printf '\nEstablished TCP sessions:\n'
ss -tan state established

The script can support a scheduled audit, but output should be protected because process names, addresses, and connection details may expose operational information. For broader Linux administration references, the Linux tutorials collection provides related command-line and server-maintenance material.

Do not confuse a socket count with an application health check. A service may have an open listening port while returning errors, exhausting worker processes, or failing to reach its database. Pair ss data with systemctl status, application logs, curl, and, where appropriate, packet captures.

A lightweight workflow can also help separate server faults from client-side problems. Compare local and remote tests, check DNS resolution, and verify whether the destination uses IPv4 or IPv6. Mobile users and field staff may follow different network paths, so a connection that works over a Melbourne office link may fail on a regional mobile network; general networking app guides can provide a separate perspective for device-side checks.

The key point is simple: use ss as the primary modern socket viewer, keep netstat available for legacy systems and familiar reports, and interpret every port and state alongside firewall rules, process ownership, and real connectivity tests.