ss vs netstat: quale comando per le porte su Linux

Usa ss — è lo standard attuale su ogni distro Linux moderna, e lì netstat è legacy. Su Ubuntu, Fedora e Debian il binario netstat ora arriva in un pacchetto opzionale net-tools, mentre ss è incluso in iproute2 e installato ovunque. ss è anche più veloce sui server sotto carico perché legge le statistiche dei socket direttamente dal kernel invece di scandire _/proc_ un file alla volta. L’inghippo è la sintassi: -tulpn non significa la stessa cosa ovunque, quindi questa guida ti dà la mappatura esatta dei flag, i comandi che vale la pena ricordare e le risposte alle domande che arrivano quando sei in mezzo a un incidente alle 2 di notte.

netstat è deprecato?

Su Linux, di fatto sì. Il pacchetto net-tools — che contiene netstat, ifconfig e route — da anni non segue più le funzionalità moderne del kernel, e non è più installato di default su nessuna delle distribuzioni principali. Esiste ancora, gira ancora, e non c’è nulla da disinstallare, ma le novità arrivano solo in iproute2 (il pacchetto dietro ss e ip).

Tre conseguenze pratiche:

1. Assente sulle installazioni fresh. Un server Ubuntu 24.04 o Fedora di default non ha netstat finché non installi net-tools a mano. È il motivo per cui così tanta gente cerca l’equivalente di netstat — il binario semplicemente non c’è più.
2. Nessuna informazione socket moderna. netstat è precedente a funzionalità come TCP fast open, statistiche socket a livello di subflow e attribuzione dei socket ai cgroup. ss le riporta nativamente.
3. L’eccezione Windows. Su Windows, netstat è vivo e vegeto — netstat -ano resta il modo standard per mappare un PID a una porta in ascolto. Il discorso della deprecazione vale solo su Linux.

Che cos’è il comando ss su Linux?

ss sta per “socket statistics”. Scarica la vista del kernel su ogni socket TCP, UDP e Unix: stato, indirizzi, porte, processi, timer e profondità delle code. La forma di lavoro è:

# Tutto ciò che è in ascolto, con il processo proprietario
sudo ss -tulpn

Flag per flag, si legge: TCP (-t), UDP (-u), solo socket in ascolto (-l), mostra i processi (-p), output numerico — niente lookup DNS (-n). Il sudo conta per -p: senza root vedi le porte ma non ottieni i nomi dei processi per i socket che non ti appartengono.

Altri due one-liner che coprono la maggior parte del lavoro:

# Tutte le connessioni stabilite da/verso la porta 443, con i processi
sudo ss -tnp 'sport = :443 or dport = :443'

# Tabella riassuntiva: quanti socket in ogni stato
ss -s

Quella sintassi di filtro è un vero upgrade rispetto all’approccio grep-e-prega di netstat — gira dentro il kernel, quindi è esatta e non un confronto di testo.

Come vedere quale processo usa una porta?

Questo è il motivo numero uno per cui si prende in mano uno dei due tool. Con ss:

sudo ss -ltnp 'sport = :8080'

Output d’esempio su una macchina con un dev server in esecuzione:

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

Il campo users:(...) ti dà direttamente nome del processo e PID — senza bisogno di un secondo comando. Se la porta è occupata ma nessun processo compare, di solito stai guardando un socket trattenuto da un altro network namespace (un container). Dall’host lancia sudo ss -ltnp e cerca la porta con la colonna processo vuota, poi abbianala con docker ps oppure entra nel namespace del container con nsenter.

Preferisci uno strumento dedicato? sudo lsof -i :8080 -sTCP:LISTEN fa lo stesso lavoro e si comporta identico su macOS e sulla maggior parte dei BSD, ed è per questo che sopravvive nei runbook. Su Linux, però, ss è già lì.

Quali sono le differenze tra ss e netstat?

Stesso lavoro, impiantistica diversa: netstat scandisce _proc/net/tcp_ in userspace, mentre ss usa netlink per chiedere direttamente al kernel — ecco perché ss risponde in millisecondi su un server con 50mila socket aperti e netstat no. Nel quotidiano, la differenza sono i flag. Ecco la mappatura da attaccare sul monitor:

Vuoi	netstat	ss
Porte TCP in ascolto + processo	netstat -tlpn	ss -tlpn
Tutte le connessioni TCP + UDP	netstat -tulpna	ss -tulpna
Tabella di routing	netstat -r	ip route
Statistiche delle interfacce	netstat -i	ip -s link
Riepilogo socket del kernel	—	ss -s
Filtrare per porta dentro il kernel	—	ss -tnp 'sport = :22'

Nota che le prime due righe sono identiche: per puro caso i flag corti di ss coincidono con quelli di netstat nei casi comuni, quindi la memoria muscolare sopravvive quasi intatta al passaggio. Le righe in fondo sono dove netstat non ha risposta — i compiti di routing e interfacce sono migrati al comando ip, e le righe di riepilogo e filtro esistono solo in ss.

Quando ha ancora senso usare netstat?

Due casi onesti. Primo, la portabilità: su una flotta mista di macchine Linux, AIX o BSD datate, netstat è l’unica sintassi presente ovunque. Secondo, la continuità della memoria muscolare nei runbook vecchi — se un runbook dice netstat -tlpn e la macchina ha net-tools installato, funziona ancora benissimo.

Per tutto il resto, default a ss e aggiorna il runbook. Un compagno utile quando riscrivi quei runbook su un server è il cheat sheet di journalctl, che si abbina naturalmente ai controlli delle porte quando stai diagnosticando un servizio che non parte: /en/blog/2026-09-02/journalctl-cheat-sheet.

Perché il comando ss non viene trovato?

Perché o sei su una distro molto vecchia (era pre-2007, prima che iproute2 diventasse standard) oppure — molto più probabile — non sei su Linux per niente. ss non è un comando macOS; macOS include lsof e netstat ma niente ss. Idem per i BSD, per lo più. Su Windows usa netstat -ano o Get-NetTCPConnection di PowerShell.

Se sei davvero su Linux e ss manca, installa iproute2:

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

La risposta in 30 secondi

ss invece di netstat su Linux, sempre: è preinstallato, più veloce e sa filtrare dentro il kernel. netstat -tlpn diventa ss -tlpn, la caccia al processo diventa sudo ss -ltnp 'sport = :PORT', e le tabelle di routing ormai spettano a ip route. Tieni netstat per gli script cross-platform e per la vecchia memoria muscolare; tieni questa pagina per la mappatura dei flag.