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

2025-12-16 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediario

O que voce vai aprender

• Como isolar problemas de "nao conecta" na camada de rede / servidor / aplicacao
• Evitar erros comuns como "assumir que e o ufw" ou "verificar apenas se o servico esta rodando"
• Dominar o conjunto de comandos (ss / lsof / nc / curl) para diagnostico rapido

1. Primeiro, esclarecer o que nao esta conectando

Conclusao: Estabeleca HOST, PORT e protocolo primeiro -- sem eles, o diagnostico nao pode comecar.

Estabeleca estas 3 coisas primeiro:

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

Exemplos:

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

2. Lado do cliente: voce consegue alcancar? (nc)

Conclusao: Execute nc -vz HOST PORT primeiro -- tres resultados apontam para camadas diferentes.

Ponto-chave: Teste a alcancabilidade a partir do cliente ANTES de mexer no servidor.

2-1. nc para verificacao 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/aplicacao)
• timed out -> Nao consegue alcancar (FW/SG/rota/DNS/servidor inativo)
• refused -> Alcancou mas nada escutando (servico parado/porta errada/bind errado)

3. Lado do servidor: esta escutando? (ss)

Conclusao: ss -lntp | grep :PORT -- verifique se o bind e 127.0.0.1, nao 0.0.0.0.

Quando nc refused, isso da a resposta definitiva.

3-1. Mostrar todos os sockets em escuta

$ sudo ss -lntp

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

3-2. Filtrar porta especifica (ex.: 80)

$ sudo ss -lntp | grep ':80 '

3-3. Armadilha comum: apenas 127.0.0.1

Se voce vir:

LISTEN 0 4096 127.0.0.1:3000 ...

Isso aceita apenas conexoes localhost. Para acesso externo, precisa fazer bind em 0.0.0.0:3000 (configuracao da aplicacao).

4. Quem esta ocupando a porta? (lsof)

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

O ss tambem mostra isso, mas a saida do lsof e mais legivel.

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 esta ocupando a porta, outro servico esta em conflito.

5. HTTP: verificar resposta (curl)

Conclusao: Use curl -I para o status HTTP -- uma porta alcancavel ainda pode retornar 500/502/503.

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

5-1. Apenas cabecalhos

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

5-2. Significado dos codigos de status

• 200: OK
• 301/302: Redirecionamento (verifique se e intencional)
• 403: Proibido (WAF/autenticacao basica/restricao de IP)
• 404: Nao encontrado (roteamento/caminho)
• 500: Erro interno (verifique os logs)
• 502/503/504: Problema no upstream/backend

6. Troubleshooting DNS (quando HOST e um dominio)

Conclusao: Se IP funciona mas dominio falha, e DNS, CDN ou certificado -- verifique com dig.

"Apenas dominio nao conecta" frequentemente e problema de DNS, certificado ou redirecionamento.

6-1. Verificar para qual IP o dominio 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 dominio nao -> DNS (ou CDN/WAF) provavelmente e o problema

7. Verificacao de servico (systemctl / journalctl)

Conclusao: Quando nc tem sucesso mas a aplicacao falha, verifique os logs do servico com journalctl.

Quando nc succeeded mas a aplicacao nao responde ou retorna erros:

7-1. Status do servico

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

7-2. Logs (mais rapido)

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

8. Mensagens de erro explicadas

Conclusao: 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: Nao consegue alcancar (timeout) ou nada escutando

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

Causas: Problema de certificado/hostname/certificado intermediario

8-5. curl -I retorna 502 Bad Gateway

Causas: nginx/apache -> upstream (aplicacao) esta inativo ou porta errada

9. Coisas a evitar

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

Nao faca: Desabilitar o FW imediatamente para contornar

ufw disable e ultimo recurso. Use nc e ss para determinar a camada do problema primeiro.

Nao faca: Assumir porta 22 sem verificar

Se na verdade esta escutando na 2222, "liberar 22" e perda de tempo.

Nao faca: Pular verificacao de escuta no servidor (ss) e culpar a aplicacao

Se nada esta escutando, o problema esta antes da aplicacao. 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