Checking whether a Linux service is listening on the expected port confirms that it successfully bound a network socket and is ready to accept connections. This quick check helps separate application startup failures from routing, firewall, and proxy issues during troubleshooting.
The kernel maintains a socket table for TCP and UDP, including the local address, port, and current state. The ss utility queries this table and can show listener details plus the owning process when sufficient privileges are available.
Listening status does not guarantee end-to-end reachability because a service can bind only to 127.0.0.1/::1, listen on IPv6 only, or be blocked by host firewall rules. Socket-activated services can appear as owned by systemd until the first connection, and administrative privileges are typically required to display process names reliably.
Related: How to troubleshoot a Linux service outage
Related: How to list open ports on Linux
$ sudo ss --listening --tcp --udp --numeric --processes | head -n 12
Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
tcp LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1337,fd=3),("systemd",pid=1,fd=87))
tcp LISTEN 0 4096 [::]:22 [::]:* users:(("sshd",pid=1337,fd=4),("systemd",pid=1,fd=88))
LISTEN indicates a TCP listener, and UNCONN is a common state for UDP sockets.
$ sudo ss --listening --tcp --udp --numeric --processes | grep ':22 '
tcp LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1337,fd=3),("systemd",pid=1,fd=87))
tcp LISTEN 0 4096 [::]:22 [::]:* users:(("sshd",pid=1337,fd=4),("systemd",pid=1,fd=88))
A bind on 0.0.0.0 or [::] listens on all interfaces, while 127.0.0.1 or ::1 limits access to the local host.
$ nc -vz 127.0.0.1 22 Connection to 127.0.0.1 22 port [tcp/ssh] succeeded!
A successful TCP connect proves only that the port accepts a handshake, and protocol-level checks may still be required for full service validation.