What’s Listening on Your Linux PC? Check Local Ports with ss

A development server, printer service, or home-server app can wait for connections without showing a window. Linux’s ss command helps you see those local sockets and, when permissions allow, the processes using them.

This is a read-only inventory of your own machine. A listening port alone proves neither public reachability nor malicious activity. The goal is to identify what you expect and record anything that needs an explanation.

Before you start

You need a Linux terminal and ss, supplied by iproute2. Start as your normal user. In a container or virtual machine, you may be inspecting that environment rather than the physical host. Linux network namespaces have separate socket tables.

Validation: These options were documentation-checked and partially tested on Debian 13.6, Linux 6.18.57, with ss utility, iproute2-6.15.0. The restricted test environment produced permission warnings, so this was not a clean production-host validation. Details appear below.

1. Check that ss is available

ss --version

You should see an iproute2 version string. If you get “command not found,” consult your distribution’s iproute2 documentation. A missing tool says nothing about whether your computer has listeners.

2. List TCP listeners

ss -ltnp

The ss manual documents these options: l selects listeners, t selects TCP, n keeps ports numeric, and p requests process information. Expect rows marked LISTEN when matching sockets are present.

Read Local Address:Port first. In an illustrative entry such as 127.0.0.1:8000, 8000 is the port. Each row represents a socket, not necessarily a different app.

• 127.0.0.1 or [::1]: IPv4 or IPv6 loopback. Direct connections normally stay within the same host/network namespace. A proxy or forwarding arrangement can still expose the application elsewhere.
• 0.0.0.0: an IPv4 wildcard binding across local interfaces.
• [::], sometimes displayed as *: an IPv6 wildcard binding.
• A specific local address: the socket is bound to that address. A LAN address does not automatically mean internet-facing.

These meanings follow the Linux IPv4 and IPv6 documentation. Wildcard bindings deserve understanding, not panic. Firewalls, routing, router forwarding, and cloud rules also affect reachability.

Do not mistake a wildcard in Peer Address:Port for an observed remote client. For process details, look for a name and pid= value in Process. A port number is only a clue to application identity.

3. Check both address families

ss -4 -ltnp
ss -6 -ltnp

The first command selects IPv4 sockets; the second selects IPv6. Compare both rather than relying on IPv4 alone.

An IPv6 wildcard socket can also accept IPv4 connections, depending on socket settings and system policy. The kernel’s bindv6only documentation explains this dual-stack behavior. An empty IPv4 list therefore does not establish that IPv4 connections are impossible.

4. Include UDP

ss -lunp

Here, u selects UDP instead of TCP. Bound, unconnected UDP sockets commonly appear as UNCONN, as they did in our test. UDP is connectionless; these are not established TCP-style sessions. This command omits connected UDP sockets and is not a complete record of UDP activity.

5. Record one useful finding

Pick a row and note its protocol, local address, port, process name, and PID when available. Match it to an app you use or its documentation. For an unfamiliar entry, ask your administrator or investigate the named service before deciding on changes. Do not stop services or change firewall rules just because a port appears.

Success check: You can explain one reported socket, or have a precise record to investigate. Treat the output as a snapshot: sockets can appear and disappear, and a familiar name does not prove safety.

If output is missing or incomplete

• Blank process details: permissions and access to process file descriptors can limit visibility. This does not mean no process exists or malware is present. An authorized administrator can help.
• Headers but no rows: without warnings, no matching sockets were reported in this context at that moment.
• Permission or netlink warnings: treat the inventory as incomplete, even if rows appear. Do not interpret missing rows as absence.

What we tested, and cleanup

On October 30, 2026, temporary loopback-only IPv4 and IPv6 TCP/UDP sockets appeared with the expected states, process details, and family filtering. All four test sockets were closed. However, every socket-listing command in that test emitted Cannot open netlink socket: Operation not permitted despite returning exit code 0. Validation was partial; we did not establish a complete host inventory or test external reachability.

The reader commands above only inspect state. They change no services, firewall rules, or network configuration. There is nothing to undo.

Sources

• Debian iproute2 ss manual and matching ss implementation: command options and UDP state filtering.
• Linux IPv4 manual and IPv6 manual: local addresses.
• Linux kernel IP sysctl documentation: IPv6 dual-stack policy.
• Linux UDP manual: connectionless sockets.
• Network namespaces and process file descriptors: inspection scope and permissions.