How to check if a Linux service is listening on a port

A Linux service can appear active while clients still fail because the daemon never opened the expected network port. Checking the listener from the local socket table confirms whether the process has bound the port before troubleshooting firewall rules, routing, proxies, or client credentials.

The ss utility reads socket state from the running kernel. For a service listener, filter on the local source port with sport = :PORT because the service owns that port on the host. Adding process details usually requires administrative privileges, and the process column helps separate the expected daemon from a different program using the same number.

Listening status is local to the current network namespace. A listener bound to all local addresses has a different exposure boundary from one bound only to loopback, and the address family matters when clients use IPv4 or IPv6. A successful nc check proves only the TCP handshake from the tested address, not protocol login, firewall reachability from another host, or application-level health.

Steps to check if a Linux service is listening on a port with ss and nc:

Confirm the expected service port and transport protocol.

The examples use ssh.service on TCP port 22. Replace the port and protocol with the value from the service configuration, runbook, or service documentation.
Query the TCP listener by local source port.
```
$ sudo ss --tcp --listening --numeric --processes 'sport = :22'
State  Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0      128          0.0.0.0:22        0.0.0.0:*    users:(("sshd",pid=3456,fd=6))
```
No matching row means the service is not listening on that port in the current network namespace. For a UDP service, switch --tcp to --udp; UDP listeners commonly show UNCONN instead of LISTEN.
Related: How to check Linux service status
Compare the local address with the intended exposure.

0.0.0.0:22 accepts IPv4 connections on all local interfaces. Use 127.0.0.1:22 for local-only services, and check IPv6 output separately when clients connect through ::1 or [::].
Test a local TCP handshake to the listener.
```
$ nc -vz 127.0.0.1 22
Connection to 127.0.0.1 22 port [tcp/ssh] succeeded!
```
A successful local handshake does not prove that remote clients can reach the port through host firewalls, container publishing, cloud security groups, or upstream network filters.
Check the service logs when the listener is missing or bound to the wrong address.

Start with the unit state and recent logs before changing firewall rules, because a daemon that failed to bind cannot accept traffic even when the network path is open.
Related: How to troubleshoot a Linux service outage

Author: Mohd Shakir Zakaria
Mohd Shakir Zakaria is a cloud architect with deep roots in software development and open-source advocacy. Certified in AWS, Red Hat, VMware, ITIL, and Linux, he specializes in designing and managing robust cloud and on-premises infrastructures.