ss vs netstat: którą komendę do portów wybrać w Linuksie?

Używaj ss — to obecny standard na każdej współczesnej dystrybucji Linuksa, a netstat jest tam reliktem. Na Ubuntu, Fedorze i Debianie binarka netstat trafia dziś do opcjonalnego pakietu net-tools, podczas gdy ss jest wbudowane w iproute2 i zainstalowane wszędzie. ss jest też szybsze na obciążonych serwerach, bo czyta statystyki gniazd wprost z jądra zamiast przedzierać się przez _/proc_ plik po pliku. Haczyk to składnia: -tulpn nie znaczy wszędzie tego samego, więc ten przewodnik daje ci dokładne mapowanie flag, komendy warte zapamiętania i odpowiedzi na pytania, które wypadają w środku incydentu o 2 w nocy.

Czy netstat jest przestarzały?

Na Linuksie — faktycznie tak. Pakiet net-tools (z netstat, ifconfig i route w pakiecie) od lat nie nadąża za nowymi funkcjami jądra i nie jest już domyślnie instalowany w żadnej większej dystrybucji. Nadal istnieje, nadal działa i nie ma czego odinstalowywać, ale nowe funkcje trafiają wyłącznie do iproute2 (pakietu stojącego za ss i ip).

Trzy praktyczne konsekwencje:

1. Brak na świeżych instalacjach. Domyślny serwer Ubuntu 24.04 czy Fedora nie ma netstat, dopóki ręcznie nie doinstalujesz net-tools. Dlatego tak wiele osób szuka odpowiednika netstat — binarki po prostu nie ma.
2. Brak informacji o nowoczesnych gniazdach. netstat powstał przed funkcjami typu TCP fast open, statystyki gniazd na poziomie subflow czy przypisanie gniazd do cgroup. ss raportuje je natywnie.
3. Wyjątek: Windows. Na Windows netstat żyje i ma się dobrze — netstat -ano to wciąż standardowy sposób mapowania PID-a na nasłuchujący port. Deprekacja dotyczy tylko Linuksa.

Czym jest komenda ss w Linuksie?

ss znaczy „socket statistics”. Wyrzuca obraz gniazd z perspektywy jądra: każde TCP, UDP i Unix — stan, adresy, porty, procesy, timery i głębokości kolejek. Koń roboczy to:

# Wszystko, co nasłuchuje, wraz z posiadającym procesem
sudo ss -tulpn

Flaga po fladze: TCP (-t), UDP (-u), tylko gniazda nasłuchujące (-l), pokaż procesy (-p), wyjście numeryczne — bez zapytań DNS (-n). sudo ma znaczenie dla -p: bez roota zobaczysz porty, ale nie dostaniesz nazw procesów dla gniazd, których nie jesteś właścicielem.

Dwa kolejne one-linery, które pokrywają większość pracy:

# Wszystkie nawiązane połączenia do/z portu 443, z procesami
sudo ss -tnp 'sport = :443 or dport = :443'

# Tabela zbiorcza: ile gniazd w każdym stanie
ss -s

Ta składnia filtrów to realny krok naprzód względem netstatowego „grepuj i módl się” — filtr wykonuje się w jądrze, więc jest dokładny, a nie dopasowany tekstowo.

Jak sprawdzić, który proces zajmuje port?

To najczęstszy powód sięgnięcia po którekolwiek z tych narzędzi. W ss:

sudo ss -ltnp 'sport = :8080'

Przykładowe wyjście na maszynie z działającym serwerem deweloperskim:

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

Pole users:(...) podaje nazwę procesu i PID wprost — bez drugiej komendy. Jeśli port jest zajęty, a procesu nie widać, zwykle patrzysz na gniazdo trzymane w innej przestrzeni nazw sieci (kontener). Z hosta odpal sudo ss -ltnp, znajdź port z pustą kolumną procesu, a potem dopasuj go przez docker ps albo wejdź przez nsenter do przestrzeni nazw kontenera.

Wolisz dedykowane narzędzie? sudo lsof -i :8080 -sTCP:LISTEN robi tę samą robotę i działa identycznie na macOS i większości BSD, dlatego przetrwało w runbookach. Na Linuksie ss i tak już tam jest.

Czym różnią się ss i netstat?

Ta sama robota, inne rurociągi: netstat skrobie _proc/net/tcp_ w userspace, a ss przez netlink pyta jądro wprost — dlatego ss zwraca wynik w milisekundach na serwerze z 50 tys. otwartych gniazd, a netstat nie. Na co dzień różnica sprowadza się do flag. Oto mapowanie warte przyklejenia do monitora:

Chcesz	netstat	ss
Nasłuchujące porty TCP + proces	netstat -tlpn	ss -tlpn
Wszystkie połączenia TCP + UDP	netstat -tulpna	ss -tulpna
Tablica routingu	netstat -r	ip route
Statystyki interfejsów	netstat -i	ip -s link
Zbiorcze statystyki gniazd z jądra	—	ss -s
Filtr po porcie w jądrze	—	ss -tnp 'sport = :22'

Zauważ, że pierwsze dwa wiersze są identyczne: z szczęścia krótkie flagi ss pokrywają się z netstatowymi dla typowych przypadków, więc pamięć mięśniowa w większości przeżywa przeprowadzkę. Dolne wiersze to teren, gdzie netstat nie ma odpowiedzi — zadania routingu i interfejsów przejęła komenda ip, a wiersze zbiorczy i filtrujący istnieją tylko w ss.

Kiedy nadal warto używać netstat?

Dwie uczciwe sytuacje. Po pierwsze, przenośność: w mieszanej flocie Linuksów, AIX-ów i starszych BSD netstat to jedyna składnia obecna wszędzie. Po drugie, ciągłość pamięci mięśniowej w starych runbookach — jeśli runbook mówi netstat -tlpn, a maszyna ma net-tools, dalej działa bez zgrzytu.

Poza tym: domyślnie używaj ss i zaktualizuj runbook. Przydatnym towarzyszem podczas przepisywania runbooków na serwerze jest ściągawka journalctl, która naturalnie łączy się ze sprawdzaniem portów, gdy diagnozujesz usługę, która nie chce wystartować.

Dlaczego nie ma komendy ss?

Bo jesteś albo na bardzo starej dystrybucji (sprzed ery 2007, zanim iproute2 stało się standardem), albo — znacznie częściej — wcale nie jesteś na Linuksie. ss nie jest komendą macOS; macOS dowozi lsof i netstat, ale nie ss. Z BSD podobnie, w większości. Na Windows użyj netstat -ano albo Get-NetTCPConnection z PowerShell.

Jeśli jednak naprawdę jesteś na Linuksie i ss nie ma, doinstaluj iproute2:

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

Odpowiedź w 30 sekund

Zawsze ss zamiast netstat na Linuksie: jest preinstalowane, szybsze i potrafi filtrować w jądrze. netstat -tlpn zamienia się w ss -tlpn, polowanie na proces w sudo ss -ltnp 'sport = :PORT', a tablice routingu należą teraz do ip route. Zostaw netstat dla skryptów wieloplatformowych i starej pamięci mięśniowej; zostaw tę stronę dla mapowania flag.