Como saber qual processo ocupa uma porta no Linux com ss e lsof
Publicado em 2026-10-26 por frfrand
Descobrir portas ocupadas e serviços a ouvir no Ubuntu
Nginx tenta enviar solicitações para a porta 8000 e não encontra nada. A API morreu ou há outro processo usando essa porta? ss e lsof permitem ver quem está ouvindo e quais arquivos ou sockets estão abertos.
Te mostro onde está o problema, como comprovar sem chutar e o que faria em um aplicativo que realmente tem usuários. Não é preciso decorar um manual inteiro para resolver uma falha específica.
O que ss e lsof significam na prática
ss consulta soquetes do sistema e exibe endereços de escuta, enquanto lsof lista descritores de arquivo associados a processos. Para ver o PID ou executável de outros usuários, geralmente é necessário usar sudo. Um processo ouvindo em localhost não equivale a estar acessível pela Internet.
Uma esclarecimento antes de mexer no servidor: se o projeto já está em produção, salve o estado que encontrou e verifique em qual usuário e máquina você vai executar os comandos. Trabalhar como root sem necessidade e mudar várias coisas de uma vez dificulta encontrar a causa de um erro.
Comandos úteis para começar
sudo ss -ltnp
sudo ss -ltnp '( sport = :8000 )'
sudo lsof -nP -iTCP:8000 -sTCP:LISTEN
curl -i http://127.0.0.1:8000/health
sudo systemctl status miappOs caminhos, nomes de unidades e domínios são exemplos. Adapte-os ao seu serviço. Se um comando exigir permissões de administrador, revise o que muda e por quê. As consultas de diagnóstico devem vir antes das modificações.
Passo a passo, com verificações
- Verifique se existe um socket TCP escutando na porta esperada.
- Verifique se escuta em
127.0.0.1, em um IP concreto ou em todas as interfaces. - Identifique PID e serviço; não mate processos apenas por reconhecer seu número.
- Faça uma requisição local e outra através do Nginx para isolar o trecho.
- Se a porta estiver ocupada, corrija a configuração do serviço e verifique os logs.
Após cada passo, verifique um resultado observável: um estado, um arquivo, uma resposta HTTP ou uma entrada de log. Se encontrar uma mensagem inesperada, salve-a para investigar em vez de ocultá-la com reinícios repetidos.
Exemplo real: uma aplicação que precisa ser mantida
Você tem dois projetos FastAPI no mesmo VPS. Ambos tentam escutar na 8000, então o segundo falha. Com ss você encontra o processo e atribui portas internas distintas com Nginx por domínio.
Ao final, teste o caminho completo: entre pelo domínio, chame a API, escreva um dado de teste e verifique se a informação continua lá após um reinício controlado. Um servidor que «arranca» nem sempre é uma aplicação que funciona.
Erros que vale a pena evitar
Não use kill -9 como solução inicial; pode interromper transações ou tarefas. Primeiro identifique o serviço supervisor e sua configuração.
Também é importante que as credenciais não terminem no histórico do terminal, logs, arquivos compartidos ou capturas. Para usuários e serviços, use permissões mínimas e documente quem pode revogar o acesso.
Como o ArduMaker entra neste cenário
Um VPS do ArduMaker pode hospedar várias aplicações atrás do Nginx. Documentar a porta interna, o domínio e o serviço systemd evita conflitos entre projetos.
O ArduMaker pode ajudar você a administrar os VPS, implantar repositórios e trabalhar com serviços, bancos de dados e domínios na mesma plataforma. Não substitui o que acabamos de explicar sobre o Linux: precisamente por isso convém entender o diagnóstico e ter uma forma de repeti-lo.
Quando convém automatizá-lo
Se a tarefa se repete, documente primeiro o procedimento manual e suas verificações. Depois considere um script ou uma tarefa agendada com erros visíveis, logs e permissões limitadas. Não automatize um comando que você ainda não sabe recuperar quando dá errado.
Perguntas frequentes
Posso testar sem afetar clientes? Em muitos casos, sim: um VPS de staging ou um serviço de teste separado permite validar a configuração antes de alterar a produção.
Como saber se ficou certo? Veja os logs e uma operação funcional, não apenas se o comando terminou com código zero.
Quando preciso de mais recursos? Quando as métricas indicarem saturação de CPU, RAM, disco ou conexões. Uma falha de configuração raramente se resolve contratando mais memória.
Referências
Em uma frase: primeiro entenda o erro, depois mude uma coisa concreta e comprove seu efeito. Essa disciplina te economiza muitas horas de suporte.