ss vs netstat: Welcher Port-Befehl unter Linux?

Nimm ss — es ist der aktuelle Standard auf jeder modernen Linux-Distribution, und netstat ist dort Legacy. Auf Ubuntu, Fedora und Debian liegt die netstat-Binary inzwischen nur noch im optionalen Paket net-tools, während ss in iproute2 steckt und überall installiert ist. ss ist auf ausgelasteten Servern auch schneller, weil es die Socket-Statistiken direkt aus dem Kernel liest, statt sich _/proc_ Datei für Datei vorzunehmen. Der Haken ist die Syntax: -tulpn bedeutet nicht überall dasselbe, daher liefert dir dieser Guide das exakte Flag-Mapping, die Befehle, die sich zu merken lohnen, und Antworten auf die Fragen, die mitten im Incident um 2 Uhr nachts aufkommen.

Ist netstat veraltet?

Unter Linux: im Effekt ja. Das Paket net-tools — mit netstat, ifconfig und route an Bord — hat moderne Kernel-Features seit Jahren nicht mehr nachgezogen und wird auf keiner großen Distribution mehr standardmäßig installiert. Es existiert weiter, läuft weiter, und es gibt nichts zu deinstallieren, aber neue Features landen nur noch in iproute2 (das Paket hinter ss und ip).

Drei praktische Konsequenzen:

1. Bei frischen Installationen nicht vorhanden. Ein Standard-Ubuntu 24.04 oder ein Fedora-Server hat kein netstat, bis du net-tools von Hand installierst. Deshalb suchen so viele Leute nach dem netstat-Äquivalent — die Binary ist schlicht weg.
2. Keine modernen Socket-Infos. netstat ist älter als Features wie TCP fast open, Socket-Statistiken auf Subflow-Ebene und cgroup-Attribution. ss meldet sie nativ.
3. Die Windows-Ausnahme. Unter Windows lebt netstat bestens — netstat -ano ist dort weiterhin der Standardweg, um eine PID auf einen lauschenden Port zu mappen. Nur unter Linux ist die Geschichte eine Deprecation.

Was ist der ss-Befehl unter Linux?

ss steht für „socket statistics”. Es wirft den Kernel-Blick auf jedes TCP-, UDP- und Unix-Socket aus: Zustand, Adressen, Ports, Prozesse, Timer und Queue-Tiefen. Die Arbeitsform ist:

# Alles, was lauscht, mit dem besitzenden Prozess
sudo ss -tulpn

Flag für Flag gelesen: TCP (-t), UDP (-u), nur lauschende Sockets (-l), Prozesse anzeigen (-p), numerische Ausgabe — keine DNS-Auflösung (-n). Das sudo ist für -p wichtig: Ohne root siehst du Ports, bekommst aber keine Prozessnamen für Sockets, die dir nicht gehören.

Zwei weitere Einzeiler, die den Großteil der Arbeit abdecken:

# Alle bestehenden Verbindungen zu/von Port 443, mit Prozessen
sudo ss -tnp 'sport = :443 or dport = :443'

# Übersichtstabelle: wie viele Sockets in welchem Zustand
ss -s

Diese Filter-Syntax ist ein echtes Upgrade gegenüber dem grep-und-beten-Ansatz von netstat — sie läuft im Kernel, ist also exakt statt textbasiert gematcht.

Wie prüfe ich, welcher Prozess einen Port benutzt?

Das ist mit Abstand der häufigste Grund, zu einem der beiden Werkzeuge zu greifen. Mit ss:

sudo ss -ltnp 'sport = :8080'

Beispielausgabe auf einer Maschine mit einem Dev-Server:

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

Das Feld users:(...) liefert Prozessname und PID direkt — ein zweiter Befehl ist nicht nötig. Ist der Port belegt, aber kein Prozess sichtbar, schaust du meist auf einen Socket, den ein anderer Network-Namespace hält (ein Container). Vom Host aus: sudo ss -ltnp laufen lassen und den Port mit leerer Prozessspalte suchen, dann mit docker ps abgleichen oder mit nsenter in den Namespace des Containers gehen.

Lieber ein dediziertes Werkzeug? sudo lsof -i :8080 -sTCP:LISTEN macht denselben Job und funktioniert identisch auf macOS und den meisten BSDs — deshalb überlebt es in Runbooks. Unter Linux ist ss aber ohnehin schon da.

Was sind die Unterschiede zwischen ss und netstat?

Dieselbe Arbeit, andere Verrohrung: netstat schabt sich _proc/net/tcp_ im Userspace zusammen, während ss per netlink den Kernel direkt fragt — deshalb liefert ss auf einem Server mit 50k offenen Sockets in Millisekunden ein Ergebnis, und netstat eben nicht. Im Alltag liegt der Unterschied bei den Flags. Hier das Mapping, das einen Platz an deinem Monitor verdient:

Du willst	netstat	ss
Lauschende TCP-Ports + Prozess	netstat -tlpn	ss -tlpn
Alle TCP- + UDP-Verbindungen	netstat -tulpna	ss -tulpna
Routing-Tabelle	netstat -r	ip route
Interface-Statistiken	netstat -i	ip -s link
Kernel-Socket-Übersicht	—	ss -s
Im Kernel nach Port filtern	—	ss -tnp 'sport = :22'

Dir fällt auf: Die ersten beiden Zeilen sind identisch. Der Zufall will es, dass ss’ Kurzflags für die üblichen Fälle mit denen von netstat übereinstimmen — das Muskelgedächtnis überlebt den Wechsel also meist. Die unteren Zeilen sind die, auf die netstat keine Antwort hat: Routing und Interfaces sind an den ip-Befehl gewandert, und Übersicht wie Filter gibt es nur in ss.

Wann sollte man trotzdem netstat nutzen?

Zwei ehrliche Fälle. Erstens Portabilität: In einem gemischten Fuhrpark aus Linux-, AIX- oder älteren BSD-Kisten ist netstat die eine Syntax, die überall vorhanden ist. Zweitens Muskelgedächtnis-Kontinuität in alten Runbooks — steht in einem Runbook netstat -tlpn und die Kiste hat net-tools installiert, funktioniert es weiterhin einwandfrei.

Ansonsten: standardmäßig ss, und das Runbook aktualisieren. Ein nützlicher Begleiter beim Umschreiben dieser Runbooks auf einem Server ist das journalctl-Cheat-Sheet, das sich gut mit Port-Checks paart, wenn du einen Dienst diagnostizierst, der nicht startet: /en/blog/2026-09-02/journalctl-cheat-sheet.

Warum wird der Befehl ss nicht gefunden?

Weil du entweder auf einer sehr alten Distribution sitzt (Ära vor 2007, bevor iproute2 Standard war) — oder, weit wahrscheinlicher, gar nicht unter Linux. ss ist kein macOS-Befehl; macOS bringt lsof und netstat mit, aber kein ss. Bei den BSDs meist genauso. Unter Windows nimm netstat -ano oder das PowerShell-Cmdlet Get-NetTCPConnection.

Wirklich unter Linux und ss fehlt? Dann iproute2 installieren:

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

Die Antwort in 30 Sekunden

ss statt netstat unter Linux, jedes Mal: vorinstalliert, schneller, und es kann im Kernel filtern. Aus netstat -tlpn wird ss -tlpn, die Prozesssuche wird zu sudo ss -ltnp 'sport = :PORT', und Routing-Tabellen gehören inzwischen ip route. Behalte netstat für plattformübergreifende Skripte und altes Muskelgedächtnis — und diese Seite fürs Flag-Mapping.