ss чи netstat: якою командою дивитися порти в Linux

Використовуйте ss — це поточний стандарт на кожній сучасній Linux-дистрибутиві, а netstat там — легасі. На Ubuntu, Fedora й Debian бінарник netstat тепер живе в опціональному пакеті net-tools, тоді як ss вбудований в iproute2 і стоїть всюди. ss ще й швидший на завантажених серверах, бо читає статистику сокетів напряму з ядра, а не обходить _/proc_ файл за файлом. Пастка — синтаксис: -tulpn не всюди означає те саме, тож цей гайд дає точну таблицю відповідності прапорців, команди, які варто запам’ятати, і відповіді на питання, що виникають посеред інциденту о другій ночі.

Чи netstat застаріла?

На Linux — фактично так. Пакет net-tools — з netstat, ifconfig і route — роками не слідкує за новими можливостями ядра і більше не ставиться за замовчуванням у жодному великому дистрибутиві. Він досі існує, досі працює, зносити нічого не треба, але нове з’являється лише в iproute2 (пакеті за ss та ip).

Три практичні наслідки:

1. Відсутня на свіжих інсталяціях. Типовий сервер Ubuntu 24.04 чи Fedora не має netstat, доки ви власноруч не поставите net-tools. Саме тому стільки людей гуглять еквівалент netstat — бінарника просто немає.
2. Немає сучасної інформації про сокети. netstat старіша за TCP fast open, статистику сокетів на рівні subflow і прив’язку сокетів до cgroup. ss звітує про них з коробки.
3. Виняток Windows. На Windows netstat живий і здоровий — netstat -ano досі стандартний спосіб зв’язати PID із портом, що слухає. Історія застарівання — суто лінуксова.

Що таке команда ss у Linux?

ss означає «socket statistics». Вона виливає ядерний погляд на кожен TCP-, UDP- та Unix-сокет: стан, адреси, порти, процеси, таймери і глибину черг. Робоча форма:

# Усе, що слухає, разом із процесом-власником
sudo ss -tulpn

Прапорець за прапорцем: TCP (-t), UDP (-u), лише сокети в стані прослуховування (-l), показати процеси (-p), числовий вивід без DNS-запитів (-n). sudo важлива для -p: без root ви бачите порти, але не імена процесів чужих сокетів.

Ще два однорядківці, що покривають більшість роботи:

# Усі встановлені з'єднання з/на порт 443, з процесами
sudo ss -tnp 'sport = :443 or dport = :443'

# Зведена таблиця: скільки сокетів у кожному стані
ss -s

Такий синтаксис фільтрації — справжнє оновлення проти netstat-івського «grep і молися»: фільтр виконується всередині ядра, тож він точний, а не текстовий.

Як перевірити, який процес займає порт?

Це найчастіша причина діставати будь-який з цих інструментів. Через ss:

sudo ss -ltnp 'sport = :8080'

Приклад виводу на машині з dev-сервером:

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

Поле users:(...) дає ім’я процесу і PID просто тут — другої команди не треба. Якщо порт зайнятий, але процесу не видно, ви, найімовірніше, дивитеся на сокет в іншому network namespace (контейнері). З хоста виконайте sudo ss -ltnp і знайдіть порт із порожньою колонкою процесу, а тоді звірте через docker ps або заходьте в namespace контейнера через nsenter.

Любите окремий інструмент? sudo lsof -i :8080 -sTCP:LISTEN робить те саме і працює однаково на macOS та більшості BSD — тому він і вижив у ранбуках. Але на Linux ss уже стоїть.

У чому різниця між ss і netstat?

Робота та сама, сантехніка різна: netstat вичитує _proc/net/tcp_ у userspace, а ss питає ядро напряму через netlink — тому ss повертається за мілісекунди на сервері з 50 тисячами відкритих сокетів, а netstat ні. У щоденній роботі різниця — у прапорцях. Ось таблиця, яку варто приклеїти до монітора:

Хочете	netstat	ss
TCP-порти в стані прослуховування + процес	netstat -tlpn	ss -tlpn
Усі TCP + UDP з’єднання	netstat -tulpna	ss -tulpna
Таблиця маршрутизації	netstat -r	ip route
Статистика інтерфейсів	netstat -i	ip -s link
Зведення ядерних сокетів	—	ss -s
Фільтр за портом у ядрі	—	ss -tnp 'sport = :22'

Зверніть увагу: перші два рядки ідентичні — на щастя, короткі прапорці ss збігаються з netstat-івськими в типових випадках, тож м’язова пам’ять здебільшого переживає переїзд. Нижні рядки — там, де netstat не має відповіді: маршрутизація й інтерфейси переїхали до команди ip, а рядки зведення й фільтра існують лише в ss.

Коли netstat досі доречна?

Два чесні випадки. Перший — переносимість: на змішаному парку Linux, AIX чи старих BSD netstat — єдина синтаксис, присутня всюди. Другий — безперервність м’язової пам’яті в старих ранбуках: якщо ранбук каже netstat -tlpn, а net-tools на машині стоїть, команда досі працює.

В іншому — стандарт ss і оновіть ранбук. Корисний сусід, коли ви переписуєте ранбуки на сервері, — шпаргалка journalctl: вони природно йдуть у парі, коли ви діагностуєте сервіс, що не стартує: /en/blog/2026-09-02/journalctl-cheat-sheet.

Чому команда ss не знайдена?

Бо ви або на дуже старій дистрибутиві (до 2007-го, коли iproute2 ще не був стандартом), або — значно ймовірніше — взагалі не на Linux. ss — це не команда macOS: macOS постачається з lsof і netstat, але без ss. У BSD — здебільшого так само. На Windows використовуйте netstat -ano або Get-NetTCPConnection у PowerShell.

Якщо ж ви справді на Linux і ss бракує, встановіть iproute2:

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

Відповідь за 30 секунд

ss замість netstat на Linux — щоразу: вона передвстановлена, швидша і фільтрує всередині ядра. netstat -tlpn стає ss -tlpn, полювання на процес — sudo ss -ltnp 'sport = :PORT', а таблиці маршрутизації тепер живуть у ip route. Тримайте netstat для крос-платформених скриптів і старої м’язової пам’яті; тримайте цю сторінку для таблиці прапорців.