Checking listening TCP sockets with ss confirms whether a service is actually bound to the expected port before firewall rules, reverse proxies, or application logs become the focus. It is a fast first check when a daemon should be accepting connections but clients still fail to connect.
The ss utility reads socket state from the kernel and, with -ltnp, limits the output to listening TCP sockets, prints numeric addresses and ports, and shows the owning process when the kernel allows it. The result is a short table that highlights which local address and port each listener is bound to.
Wildcard listeners such as 0.0.0.0:80 or [::]:443 accept connections on all matching local interfaces, while loopback listeners such as 127.0.0.1:5432 stay local to the host. Process details from -p are permission-sensitive, so a regular user may see the socket but not the owning program until the command is re-run with sudo.
Related: How to show socket summary with ss
$ ss -ltnp
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 5 0.0.0.0:8080 0.0.0.0:* users:(("python3",pid=3080,fd=3))
The -l, -t, -n, and -p flags limit the output to listening TCP sockets, keep addresses numeric, and request process details.
Entries such as 0.0.0.0:8080 listen on all local IPv4 interfaces, while 127.0.0.1:8080 accepts connections only from the local host.
$ ss -ltnp
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 5 0.0.0.0:8080 0.0.0.0:*
$ sudo ss -ltnp
State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess
LISTEN 0 5 0.0.0.0:8080 0.0.0.0:* users:(("python3",pid=3080,fd=3))
Without elevated privileges, ss -p usually shows process details only for sockets owned by the current user.