ss vs netstat: qual comando de porta usar no Linux

Use o ss — ele é o padrão atual em toda distro Linux moderna, e o netstat é legado ali. No Ubuntu, Fedora e Debian o binário netstat agora vem num pacote opcional net-tools, enquanto o ss faz parte do iproute2 e está instalado em todo lugar. O ss também é mais rápido em servidores movimentados porque lê as estatísticas de sockets direto do kernel em vez de percorrer o /proc arquivo por arquivo. A pegadinha é a sintaxe: -tulpn não significa a mesma coisa em todo lugar, então este guia traz o mapeamento exato de flags, os comandos que valem a pena decorar e as respostas para as perguntas que aparecem quando você está no meio de um incidente às 2 da manhã.

O netstat está depreciado?

No Linux, na prática, sim. O pacote net-tools — que contém netstat, ifconfig e route — não acompanha os recursos modernos do kernel há anos e não vem mais instalado por padrão em nenhuma distribuição grande. Ele ainda existe, ainda roda e não há nada para desinstalar, mas recursos novos só chegam no iproute2 (o pacote por trás do ss e do ip).

Três consequências práticas:

1. Some das instalações novas. Um Ubuntu 24.04 ou servidor Fedora padrão não tem netstat até você instalar o net-tools à mão. É por isso que tanta gente pesquisa pelo equivalente do netstat — o binário simplesmente não está lá.
2. Sem informações modernas de socket. O netstat é anterior a recursos como TCP fast open, estatísticas de socket por subflow e atribuição de socket por cgroup. O ss reporta tudo isso nativamente.
3. A exceção do Windows. No Windows, o netstat está vivo e bem — netstat -ano continua sendo o jeito padrão de mapear um PID para uma porta em escuta. Só a história do Linux é de deprecação.

O que é o comando ss no Linux?

ss significa “socket statistics”. Ele despeja a visão que o kernel tem de todo socket TCP, UDP e Unix: estado, endereços, portas, processos, timers e profundidade de filas. A forma de trabalho é:

# Tudo que está em escuta, com o processo responsável
sudo ss -tulpn

Flag por flag, isso lê: TCP (-t), UDP (-u), só sockets em escuta (-l), mostrar processos (-p), saída numérica — sem consultas DNS (-n). O sudo importa para o -p: sem root você vê as portas mas não recebe os nomes de processo dos sockets que não são seus.

Mais dois one-liners que cobrem a maior parte do trabalho:

# Todas as conexões estabelecidas de/para a porta 443, com processos
sudo ss -tnp 'sport = :443 or dport = :443'

# Tabela-resumo: quantos sockets em cada estado
ss -s

Essa sintaxe de filtro é uma melhoria real sobre a abordagem do netstat de “grep e reza” — ela roda dentro do kernel, então é exata em vez de casamento de texto.

Como descobrir qual processo está usando uma porta?

Esse é o motivo mais comum para recorrer a qualquer um dos dois. Com o ss:

sudo ss -ltnp 'sport = :8080'

Exemplo de saída numa máquina rodando um servidor de desenvolvimento:

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

O campo users:(...) te dá o nome do processo e o PID direto — sem segundo comando. Se a porta está ocupada mas nenhum processo aparece, normalmente é um socket segurado por outro namespace de rede (um contêiner). A partir do host, rode sudo ss -ltnp e procure a porta com a coluna de processo vazia, então cruze com docker ps ou entre no namespace do contêiner com nsenter.

Prefere uma ferramenta dedicada? sudo lsof -i :8080 -sTCP:LISTEN faz o mesmo trabalho e funciona igual no macOS e na maioria dos BSDs — por isso sobrevive nos runbooks. No Linux, porém, o ss já está lá.

Quais as diferenças entre ss e netstat?

Mesmo trabalho, encanamento diferente: o netstat vasculha o proc/net/tcp em userspace, enquanto o ss usa netlink para perguntar direto ao kernel — por isso o ss responde em milissegundos num servidor com 50 mil sockets abertos e o netstat não. No dia a dia, a diferença são os flags. Este é o mapeamento que vale decorar:

Você quer	netstat	ss
Portas TCP em escuta + processo	netstat -tlpn	ss -tlpn
Todas as conexões TCP + UDP	netstat -tulpna	ss -tulpna
Tabela de roteamento	netstat -r	ip route
Estatísticas de interface	netstat -i	ip -s link
Resumo de sockets do kernel	—	ss -s
Filtrar por porta no kernel	—	ss -tnp 'sport = :22'

Repare que as duas primeiras linhas são idênticas: por sorte, os flags curtos do ss coincidem com os do netstat nos casos comuns, então quase toda a memória muscular sobrevive à migração. As linhas de baixo são onde o netstat não tem resposta — os trabalhos de rota e interface migraram para o comando ip, e as linhas de resumo e filtro só existem no ss.

Quando ainda vale usar o netstat?

Dois casos honestos. Primeiro, portabilidade: num parque misto de máquinas Linux, AIX ou BSDs antigos, o netstat é a única sintaxe presente em todo lugar. Segundo, continuidade de memória muscular em runbooks antigos — se o runbook diz netstat -tlpn e a máquina tem o net-tools instalado, ainda funciona bem.

Fora isso, fique com o ss e atualize o runbook. Uma companhia útil quando você estiver reescrevendo esses runbooks num servidor é o cheat sheet do journalctl, que combina bem com checagens de porta quando você está diagnosticando um serviço que não sobe: /en/blog/2026-09-02/journalctl-cheat-sheet.

Por que aparece “ss: command not found”?

Porque ou você está numa distro muito antiga (da era pré-2007, antes do iproute2 ser padrão) ou — muito mais provável — você não está no Linux. ss não é comando de macOS; o macOS traz lsof e netstat, mas nenhum ss. O mesmo vale para os BSDs, em geral. No Windows, use netstat -ano ou o Get-NetTCPConnection do PowerShell.

Se você realmente está no Linux e o ss não existe, instale o iproute2:

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

A resposta de 30 segundos

ss em vez de netstat no Linux, sempre: vem pré-instalado, é mais rápido e filtra dentro do kernel. netstat -tlpn vira ss -tlpn, a caça a processos vira sudo ss -ltnp 'sport = :PORT', e as tabelas de rota agora pertencem ao ip route. Guarde o netstat para scripts multiplataforma e velha memória muscular; guarde esta página para o mapeamento de flags.