netstat и ss: какие порты слушает сервер и что означают состояния TCP

Снаружи порт закрыт, изнутри сервис вроде запущен. Или наоборот: сайт отвечает, но раз в час намертво зависает на минуту. Обе ситуации разбираются одной командой — если знать, куда смотреть. Разбираем ss и netstat: ключи, фильтры, одиннадцать состояний TCP и две колонки, которые видит только ss.

ss и netstat — утилиты, которые показывают сокеты операционной системы: какие порты она слушает, с кем установлены соединения и в каком те состоянии. Это взгляд изнутри сервера, в отличие от сканирования снаружи: ss видит и процесс-владелец сокета, и очереди, которых снаружи не видно вовсе.

Почему netstat может не найтись на сервере

netstat входит в пакет net-tools, последний релиз которого — 2.10 от января 2021 года. За пять с лишним лет ни одного обновления: пакет живёт только на патчах дистрибутивов. На смену пришёл iproute2, который активно развивается.

Где netstat уже не стоит по умолчанию: RHEL начиная с седьмой версии, Debian и Ubuntu (пакет с приоритетом optional против important у iproute2), Fedora, Arch, Alpine и все контейнерные образы. В докер-контейнере вы почти гарантированно не найдёте ни того, ни другого — ставить придётся руками.

Главная команда, которую нужно помнить

sudo ss -tulpn      # что слушает сервер: TCP, UDP, процессы, без резолва
sudo netstat -tulpn # то же на старых системах

Мнемоника одинаковая: tcp, udp, listening, process, numeric. Без sudo колонка с процессами будет пустой для чужих сокетов — ядро не покажет владельца непривилегированному пользователю.

Netid State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
tcp   LISTEN 0      4096         0.0.0.0:80         0.0.0.0:*     users:(("nginx",pid=812,fd=6))
tcp   LISTEN 0      511        127.0.0.1:9000       0.0.0.0:*     users:(("php-fpm",pid=901,fd=8))
tcp   LISTEN 0      70         127.0.0.1:33060      0.0.0.0:*     users:(("mysqld",pid=744,fd=21))
udp   UNCONN 0      0      127.0.0.53%lo:53         0.0.0.0:*     users:(("systemd-resolve",pid=611,fd=13))

Ключи ss

Фильтры ss: главное преимущество перед netstat

У ss есть собственный язык выражений, и фильтрация происходит в ядре, а не после выгрузки всего списка. На машине с сотней тысяч соединений это разница между долями секунды и десятками секунд.

# По состоянию
ss -t state established
ss -t state time-wait
ss -t state close-wait          # диагностика утечки дескрипторов
ss -t state syn-sent            # висящие исходящие соединения

# По адресу и подсети
ss -t dst 10.0.0.5
ss -t dst 10.0.0.0/8
ss -t dst 10.0.0.5:443
ss -t src 192.168.1.10

# По портам
ss -t sport = :22
ss -tn 'sport > :1024'
ss -t '( dport = :443 or sport = :443 )'

# Комбинация
ss -tn state established '( dport = :80 or dport = :443 )' dst 10.0.0.0/8

# Топ IP-адресов, с которых идут соединения
ss -tn state established -H | awk '{print $5}' | cut -d: -f1 \
  | sort | uniq -c | sort -rn | head -20

# Сводка по состояниям одной командой
ss -tan | awk 'NR>1{c[$1]++} END{for (s in c) print c[s], s}' | sort -rn

# Аварийно оборвать соединения с конкретным адресом
sudo ss -K dst 10.0.0.5 dport = :443

Почему ss быстрее: netstat читает и разбирает текстовые файлы /proc/net/tcp, которые ядро генерирует построчно, а с ключом -p ещё и обходит все дескрипторы всех процессов, чтобы сопоставить inode сокета с владельцем. ss использует netlink-интерфейс sock_diag: двоичный формат, запрос только нужных полей и фильтрация на стороне ядра.

Одиннадцать состояний TCP и что означает их скопление

Про TIME-WAIT отдельно, потому что вокруг него много устаревших советов. В Linux длительность жёстко зашита в ядро — 60 секунд, и sysctl её не меняет. Десятки тысяч таких сокетов на busy-прокси — ожидаемая картина, а не авария. Реальная проблема возникает только при исчерпании эфемерных портов к одному и тому же адресу с портом; симптом — ошибка EADDRNOTAVAIL. Лечится это пулом соединений и keep-alive, расширением net.ipv4.ip_local_port_range и параметром tcp_tw_reuse=1. А вот tcp_tw_recycle, который до сих пор советуют в старых статьях, удалён из ядра ещё в версии 4.12 — он ломал клиентов за NAT.

Recv-Q и Send-Q: две колонки, которые читают неправильно

У этих колонок разный смысл для слушающего и для установленного сокета. Путаница здесь стоит часов диагностики.

ss -ltn

State  Recv-Q Send-Q  Local Address:Port
LISTEN 0      4096          0.0.0.0:80      <- очередь пуста, всё хорошо
LISTEN 129    128           0.0.0.0:8080    <- очередь переполнена, соединения теряются

Разбор трёх типовых ситуаций

Порт снаружи закрыт, сервис запущен. Смотрим адрес привязки: если 127.0.0.1:8080, сервис принципиально недоступен снаружи, и дело не в файрволе. Если 0.0.0.0:8080 — тогда уже файрвол или группа безопасности у хостера.

Сайт зависает под нагрузкой. Смотрим ss -ltn: если Recv-Q растёт — приложению не хватает воркеров, соединения ждут в очереди и отваливаются по таймауту у клиента, при этом в логах веб-сервера может не быть вообще ничего.

Сервис умирает раз в неделю. Смотрим ss -tan state close-wait | wc -l. Если счёт идёт на сотни и растёт день ото дня — утечка дескрипторов, и падение случится, когда упрётся в лимит.

Что делать на Windows и macOS

Утилиты ss там нет и не будет: она опирается на netlink, которого нет за пределами Linux.

# Windows
netstat -ano                     # все сокеты с PID
netstat -ano | findstr :443
tasklist /FI "PID eq 1234"       # сопоставить PID с процессом

# PowerShell, объектный вариант
Get-NetTCPConnection -State Listen |
  Select LocalAddress,LocalPort,OwningProcess,
         @{n='Process';e={(Get-Process -Id $_.OwningProcess).ProcessName}}

# macOS: netstat есть, но BSD-версии, PID не показывает
sudo lsof -i -P -n               # реальный аналог ss -tulpn
sudo lsof -i :443
netstat -an                      # -p здесь означает протокол, а не процесс

Взгляд изнутри не заменяет взгляда снаружи

ss показывает, что сокет открыт и слушает. Он не показывает, доходит ли до него трафик из интернета: между вашим сервисом и пользователем могут стоять файрвол, группа безопасности хостера, NAT и провайдерская фильтрация. Порт может слушать идеально и быть недоступен всей стране.

Проверить это можно только снаружи, причём из нескольких мест: проверка TCP-порта устанавливает соединение с указанным портом с внешних точек и показывает, где оно проходит, а где нет. А ICMP-проверка отвечает на предыдущий вопрос — виден ли вообще сам хост.