linux-labs

Вики / Сеть

ss (сокеты и порты)

Команда Ubuntu 24.04 · iproute2 СетьПроцессы

Кто слушает порты и какие соединения открыты — современная замена netstat.

ss (socket statistics) показывает сокеты: какие порты слушаются, какие соединения установлены, и какой процесс за ними стоит. Замена netstat (пакет net-tools), заметно быстрее на большом числе соединений.

Самая частая команда админа — «кто что слушает»:

ss -tlnp        # TCP · Listening · Numeric · Process
Ключ Значение
-t / -u TCP / UDP
-l только слушающие (listening)
-a все (слушающие + установленные)
-n не резолвить порты/имена в названия (быстро, без DNS)
-p показать процесс (нужен root для чужих)
-4 / -6 только IPv4 / IPv6
-s сводная статистика
-o таймеры (keepalive, retransmit)
-m память сокета
-i детали TCP (cwnd, rtt)
-x unix-сокеты

Мнемоника частого набора -tlnp: tcp listening numeric process.

ss -tlnp                          # слушающие TCP-порты + процессы
ss -ulnp                          # слушающие UDP-порты
ss -tnp                           # установленные TCP-соединения
ss -tanp                          # все TCP: и слушающие, и установленные
ss -s                             # сводка: сколько всего сокетов по типам
ss -tnp state established         # только установленные
ss -tnp state time-wait          # «зависшие» в TIME-WAIT
ss -tlnp '( sport = :80 or sport = :443 )'   # кто слушает 80/443
ss -tnp dst 10.0.0.5             # соединения к конкретному хосту
ss -tnp 'dport = :5432'          # соединения к порту postgres
ss -tnp dst 10.0.0.0/24          # к целой подсети
ss -tonp                          # с таймерами keepalive/retransmit
ss -tnp | wc -l                   # сколько активных TCP-соединений (грубо)

Фильтр по состоянию TCP — state <имя> (или state connected/listening):

ss -tan state established         # рабочие соединения
ss -tan state syn-sent            # клиент ждёт ответа (висит коннект?)
ss -tan state close-wait          # приложение не закрывает сокеты (утечка fd!)
ss -tan state time-wait | wc -l   # много TIME-WAIT — частые короткие коннекты

Адресные фильтры комбинируются (and/or): src/dst (адрес), sport/dport (порт).

ss -tnp 'dst 10.0.0.5 and dport = :443'
ss -tnp 'sport >= :1024'         # эфемерные исходящие порты

«Address already in use» при старте службы

Порт уже занят. Найди кем и останови/смени порт:

ss -tlnp 'sport = :8000'         # users:(("python",pid=1234,fd=3))

Служба запущена, но снаружи недоступна

  1. Слушает ли вообще: ss -tlnp | grep :PORT.
  2. На 127.0.0.1 вместо 0.0.0.0/*? Тогда только локально — поправь bind в конфиге.
  3. Порт открыт в файрволе? (nft list ruleset / ufw status — см. firewall).

Растёт число сокетов в CLOSE-WAIT

Приложение не закрывает соединения (утечка дескрипторов) — рано или поздно упрётся в ulimit. ss -tanp state close-wait покажет виновный процесс.

Много TIME-WAIT

Норма при большом числе коротких клиентских соединений; обычно не проблема. Лечится keep-alive/пулом соединений на стороне приложения, не тюнингом ядра наобум.

Непонятно, что за процесс держит соединение

ss -tnp покажет users:(("nginx",pid=1234,...)). Глубже — lsof.

ss -tlnp                          # слушающие порты + кто
ss -tnp                           # активные соединения
ss -tulnp                         # TCP+UDP слушающие
ss -tlnp 'sport = :80'            # кто на 80
ss -tan state close-wait          # утечка сокетов?
ss -s                             # статистика

См. также