Check open ports on Linux
A practical checklist for finding which ports are open on a Linux machine or across your network, from local sockets to a full nmap scan.
What this covers
Whether you're troubleshooting a service that won't respond, auditing a server, or just curious what's listening, checking open ports is a two-layer job: what this machine is serving, and what the network can reach. This guide walks through both, using only commands appropriate for a Linux terminal.
See what's listening locally with ss
Start on the machine itself: ss lists every listening TCP/UDP socket together with the owning process, so you immediately know which services hold which ports. Run it with sudo so process names aren't hidden. You've got what you need when you can match each LISTEN line to a port and a process name.
See which services listen on which ports and who is connected — the modern netstat replacement.
$ sudo ss -tulpnIdentify the processes behind the ports
If ss shows a port held by a process you don't recognize, take a full process snapshot to see its owner, CPU/memory footprint and full command line. This helps you decide whether a listener is legitimate before you go further. Done when every unfamiliar port maps to a process you understand.
Use the classic ps aux command to list every process on the system with owner, CPU, memory, and command columns.
$ ps auxOptionally discover which hosts are up first
If your goal is to check ports across a network rather than on one known machine, run a ping sweep first to list the live hosts in the subnet. This avoids wasting a full port scan on machines that are offline. Done when you have a shortlist of IP addresses to scan.
Run a ping sweep that lists online machines without wasting time on port scanning — the forgotten first step of any network audit.
$ sudo nmap -sn 192.168.1.0/24Scan the host's full port range with nmap
For an external view — what the rest of the network can actually reach — run a version scan across all 65535 ports on the target host. This catches services ss might miss from another angle and shows service versions you can compare against known issues. Only scan machines you administer. Done when you have a complete list of open ports and service versions.
Enumerate every open port and running service version on a machine you administer.
$ nmap -sV -p- 192.168.1.10How to confirm it worked
You can list every listening socket with its owning process on the host, and an nmap scan from another machine returns the same set of open ports with service versions.
Sources
- ss(8) — Arch Manual PagesEvidence: Same options documented for ss, another utility to investigate sockets.
- ss(8) — Debian bookwormEvidence: Documents -t/--tcp, -u/--udp, -l/--listening, -p/--processes and -n/--numeric for the socket statistics tool.
- Ubuntu Manpage: ps - report a snapshot of the current processesEvidence: "ps displays information about a selection of the active processes"; the u option selects the user-oriented format with USER, %CPU, %MEM, and COMMAND headers.
- ps - report a snapshot of the current processesEvidence: The ps page documents the a, u, and x options ("u Display user-oriented format" including USER, %CPU, %MEM, and COMMAND columns) and describes ps as reporting "a snapshot of the current processes".
- Host Discovery — Nmap Reference GuideEvidence: Documents -sn (ping scan, no port scan) and default discovery probes per target type.
- nmap(1) — Debian manpageEvidence: Debian manpage describes nmap's -sV version detection and -p- to scan ports 1-65535
- nmap(1) — Ubuntu manpageEvidence: Ubuntu manpage documents -sV service/version detection and -p- (all 65535 ports) port specification
Last verified: 2026-09-21
Related guides
Find the process leaking file descriptors with ss and lsof, then raise the limit with ulimit and make it persist across logins.
A terminal-first workflow to diagnose high CPU usage on Linux, identify the responsible process or service, and fix it without losing your work.
Diagnose high I/O wait on Linux: find the saturated disk and the process causing it, then lower its I/O priority so the system responds again.