ss vs netstat: welk Linux-commando voor ports?

Gebruik ss — dat is de huidige standaard op elke moderne Linux-distro, en netstat is daar legacy. Op Ubuntu, Fedora en Debian zit het netstat-binary tegenwoordig in een optioneel net-tools-pakket, terwijl ss in iproute2 zit en overal geïnstalleerd is. ss is ook sneller op drukke servers omdat het socket-statistieken rechtstreeks uit de kernel leest in plaats van /proc bestand voor bestand af te lopen. De catch is de syntax: -tulpn betekent niet overal hetzelfde, dus deze gids geeft de exacte flag-mapping, de commando’s om te onthouden, en antwoorden op de vragen die opkomen als je om 2 uur ‘s nachts midden in een incident zit.

Is netstat verouderd?

Op Linux: effectief ja. Het net-tools-pakket — met netstat, ifconfig en route — volgt al jaren geen moderne kernelfeatures meer en wordt op geen enkele grote distributie meer standaard geïnstalleerd. Het bestaat nog, het draait nog, en er is niets te de-installeren, maar nieuwe features landen alleen in iproute2 (het pakket achter ss en ip).

Drie praktische gevolgen:

1. Afwezig op verse installaties. Een kale Ubuntu 24.04- of Fedora-server heeft geen netstat tot je net-tools met de hand installeert. Daarom zoeken zoveel mensen het netstat-equivalent — het binary is er simpelweg niet.
2. Geen moderne socket-info. netstat is ouder dan features als TCP fast open, socket-statistieken op subflowniveau en cgroup-socket-toewijzing. ss rapporteert ze native.
3. De Windows-uitzondering. Op Windows leeft netstat prima — netstat -ano is daar nog steeds de standaardmanier om een PID aan een listening port te koppelen. Alleen het Linux-verhaal is deprecated.

Wat doet het commando ss op Linux?

ss staat voor “socket statistics”. Het dumpt de kernelweergave van elke TCP-, UDP- en Unix-socket: status, adressen, ports, processen, timers en queue-dieptes. De werkpaardvorm is:

# Everything listening, with the owning process
sudo ss -tulpn

Flag voor flag gelezen: TCP (-t), UDP (-u), alleen listening sockets (-l), processen tonen (-p), numerieke output — geen DNS-lookups (-n). De sudo is belangrijk voor -p: zonder root zie je ports maar geen procesnamen voor sockets die niet van jou zijn.

Nog twee eenregelaars die het meeste werk dekken:

# All established connections to/from port 443, with processes
sudo ss -tnp 'sport = :443 or dport = :443'

# Summary table: how many sockets in each state
ss -s

Die filtersyntax is een echte verbetering ten opzichte van de grep-en-bidden-aanpak van netstat — hij draait in de kernel, dus hij is exact in plaats van tekst-gematcht.

Hoe zoek je op welk proces een port gebruikt?

Dit is de belangrijkste reden om een van beide tools te pakken. Met ss:

sudo ss -ltnp 'sport = :8080'

Voorbeeldoutput op een machine met een dev-server:

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

Het veld users:(...) geeft direct de procesnaam en PID — geen tweede commando nodig. Is de port bezet maar toont geen proces, dan kijk je meestal naar een socket in een andere network namespace (een container). Draai vanaf de host sudo ss -ltnp en zoek de port met een lege proceskolom, en match die met docker ps of nsenter in de namespace van de container.

Liever een dedicated tool? sudo lsof -i :8080 -sTCP:LISTEN doet hetzelfde werk en werkt identiek op macOS en de meeste BSD’s, wat verklaart waarom hij in runbooks staat. Op Linux is ss er echter al.

Wat zijn de verschillen tussen ss en netstat?

Zelfde werk, ander leidingwerk: netstat schraapt /proc/net/tcp in userspace, terwijl ss via netlink de kernel direct vraagt — daarom is ss op een server met 50k open sockets in milliseconden klaar en netstat niet. In het dagelijks gebruik zit het verschil in de flags. Dit is de mapping om op je monitor te plakken:

Je wilt	netstat	ss
Listening TCP-ports + proces	netstat -tlpn	ss -tlpn
Alle TCP- en UDP-verbindingen	netstat -tulpna	ss -tulpna
Routingtabel	netstat -r	ip route
Interfacestatistieken	netstat -i	ip -s link
Kernel-socketoverzicht	—	ss -s
Filteren op port in de kernel	—	ss -tnp 'sport = :22'

Merk op dat de eerste twee rijen identiek zijn: bij toeval vallen de korte flags van ss samen met die van netstat voor de gebruikelijke gevallen, dus het spiergeheugen overleeft de overstap grotendeels. De onderste rijen zijn waar netstat geen antwoord heeft — de routing- en interfaceklussen zijn naar het ip-commando verhuisd, en de overzichts- en filterrijen bestaan alleen in ss.

Wanneer gebruik je netstat nog?

Twee eerlijke gevallen. Ten eerste draagbaarheid: op een gemengd park van Linux-, AIX- of oudere BSD-dozen is netstat de enige syntax die overal bestaat. Ten tweede continuïteit van spiergeheugen in oude runbooks — als een runbook netstat -tlpn zegt en er staat net-tools op de doos, werkt het nog prima.

Verder: default naar ss en werk het runbook bij. Een handige metgezel bij dat runbookwerk op een server is de journalctl-cheatsheet, die natuurlijk past bij port-checks als je een service diagnoseert die niet opstart: de journalctl-cheatsheet.

Waarom krijg je ss: command not found?

Omdat je óf op een heel oude distro zit (van vóór 2007, toen iproute2 nog niet standaard was) óf — veel waarschijnlijker — helemaal niet op Linux. ss is geen macOS-commando; macOS levert lsof en netstat mee maar geen ss. Voor de BSD’s geldt grotendeels hetzelfde. Op Windows: gebruik netstat -ano of de PowerShell-functie Get-NetTCPConnection.

Zit je echt op Linux en ontbreekt ss, installeer dan iproute2:

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

Het antwoord in 30 seconden

ss boven netstat op Linux, altijd: het zit er standaard in, is sneller en kan in de kernel filteren. netstat -tlpn wordt ss -tlpn, procesjacht wordt sudo ss -ltnp 'sport = :PORT', en routingtabellen horen tegenwoordig bij ip route. Houd netstat voor cross-platform-scripts en oud spiergeheugen; houd deze pagina bij voor de flag-mapping.