Conectividade de Portas no Ubuntu - Guia de Troubleshooting com ss, lsof, nc, curl

2025-12-16 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediário

O que você vai aprender

• Como isolar problemas de "não conecta" na camada de rede / servidor / aplicação
• Evitar erros comuns como "assumir que é o ufw" ou "verificar apenas se o serviço está rodando"
• Dominar o conjunto de comandos (ss / lsof / nc / curl) para diagnóstico rápido

1. Primeiro, esclarecer o que não está conectando

Conclusão: Estabeleca HOST, PORT e protocolo primeiro -- sem eles, o diagnóstico não pode começar.

Estabeleca estas 3 coisas primeiro:

• HOST: Domínio ou IP
• PORT: 22 / 80 / 443 / 3000 / 8080 / 3306 etc.
• Protocolo: SSH? HTTP? Banco de dados?

Exemplos:

• SSH não conecta -> HOST=example.com PORT=22 (ou 2222)
• Web não carrega -> PORT=80/443
• API não responde -> PORT=3000/8080

2. Lado do cliente: você consegue alcançar? (nc)

Conclusão: Execute nc -vz HOST PORT primeiro -- três resultados apontam para camadas diferentes.

Ponto-chave: Teste a alcançabilidade a partir do cliente ANTES de mexer no servidor.

2-1. nc para verificação de conectividade (TCP)

$ nc -vz example.com 22

2-2. Porta diferente (ex.: 2222)

$ nc -vz example.com 2222

2-3. Lendo os resultados (crucial)

• succeeded -> Caminho de rede funciona (agora verifique servidor/aplicação)
• timed out -> Não consegue alcançar (FW/SG/rota/DNS/servidor inativo)
• refused -> Alcançou mas nada escutando (serviço parado/porta errada/bind errado)

3. Lado do servidor: está escutando? (ss)

Conclusão: ss -lntp | grep :PORT -- verifique se o bind é 127.0.0.1, não 0.0.0.0.

Quando nc refused, isso dá a resposta definitiva.

3-1. Mostrar todos os sockets em escuta

$ sudo ss -lntp

• -l: Sockets em escuta
• -n: Numérico (sem consulta DNS)
• -t: TCP
• -p: Mostrar processo (precisa de sudo)

3-2. Filtrar porta específica (ex.: 80)

$ sudo ss -lntp | grep ':80 '

3-3. Armadilha comum: apenas 127.0.0.1

Se você vir:

LISTEN 0 4096 127.0.0.1:3000 ...

Isso aceita apenas conexões localhost. Para acesso externo, precisa fazer bind em 0.0.0.0:3000 (configuração da aplicação).

4. Quem está ocupando a porta? (lsof)

Conclusão: lsof -i :PORT encontra o dono -- um processo inesperado significa conflito de porta.

O ss também mostra isso, mas a saída do lsof é mais legível.

4-1. Mostrar processo ocupando a porta 80

$ sudo lsof -i :80

4-2. Exemplo com porta 3000

$ sudo lsof -i :3000

Se um processo inesperado está ocupando a porta, outro serviço está em conflito.

5. HTTP: verificar resposta (curl)

Conclusão: Use curl -I para o status HTTP -- uma porta alcançável ainda pode retornar 500/502/503.

Para web/API, "porta aberta mas erro 500" é comum.

5-1. Apenas cabeçalhos

$ curl -I http://example.com
$ curl -I https://example.com

5-2. Significado dos códigos de status

• 200: OK
• 301/302: Redirecionamento (verifique se é intencional)
• 403: Proibido (WAF/autenticação básica/restrição de IP)
• 404: Não encontrado (roteamento/caminho)
• 500: Erro interno (verifique os logs)
• 502/503/504: Problema no upstream/backend

6. Troubleshooting DNS (quando HOST é um domínio)

Conclusão: Se IP funciona mas domínio falha, é DNS, CDN ou certificado -- verifique com dig.

"Apenas domínio não conecta" frequentemente é problema de DNS, certificado ou redirecionamento.

6-1. Verificar para qual IP o domínio resolve

$ dig example.com +short

6-2. Testar diretamente com IP (ignorar DNS)

$ nc -vz 203.0.113.10 80
$ curl -I http://203.0.113.10

IP funciona mas domínio não -> DNS (ou CDN/WAF) provavelmente é o problema

7. Verificação de serviço (systemctl / journalctl)

Conclusão: Quando nc tem sucesso mas a aplicação falha, verifique os logs do serviço com journalctl.

Quando nc succeeded mas a aplicação não responde ou retorna erros:

7-1. Status do serviço

$ sudo systemctl status nginx
$ sudo systemctl status apache2
$ sudo systemctl status ssh

7-2. Logs (mais rápido)

$ sudo journalctl -u nginx -n 200
$ sudo journalctl -u ssh -n 200

8. Mensagens de erro explicadas

Conclusão: Timed out significa rota bloqueada; refused significa nada escutando; SSL significa certificado.

8-1. nc: connect ... timed out

Causas: ufw, firewall de nuvem (SG), firewall corporativo, roteamento, servidor inativo

8-2. nc: connect ... refused

Causas: Nada escutando, porta errada, processo inativo

8-3. curl: (7) Failed to connect

Causas: Não consegue alcançar (timeout) ou nada escutando

8-4. curl: (60) SSL certificate problem

Causas: Problema de certificado/hostname/certificado intermediário

8-5. curl -I retorna 502 Bad Gateway

Causas: nginx/apache -> upstream (aplicação) está inativo ou porta errada

9. Coisas a evitar

Conclusão: Nunca desabilite o firewall primeiro -- use nc e ss para isolar o problema.

Não faça: Desabilitar o FW imediatamente para contornar

ufw disable é último recurso. Use nc e ss para determinar a camada do problema primeiro.

Não faça: Assumir porta 22 sem verificar

Se na verdade está escutando na 2222, "liberar 22" é perda de tempo.

Não faça: Pular verificação de escuta no servidor (ss) e culpar a aplicação

Se nada está escutando, o problema está antes da aplicação. Siga a ordem de isolamento.

# Lado do cliente (alcancabilidade)
nc -vz example.com PORT

# Lado do servidor (verificacao de escuta)
sudo ss -lntp | grep ":PORT "

# Lado do servidor (processo ocupando a porta)
sudo lsof -i :PORT

# Verificacao de resposta HTTP
curl -I http://example.com
curl -I https://example.com

# Servico/logs
sudo systemctl status <service>
sudo journalctl -u <service> -n 200