Diagnosticando "Connection timed out"

2026-06-06 Tempo de leitura: Cerca de 12 min Dificuldade: Intermediario

O que significa "Connection timed out"?

Conclusao: Voce enviou uma requisicao de conexao e nada retornou. O destino -- ou um dispositivo no caminho -- esta descartando pacotes silenciosamente (DROP), ou o destino esta desligado. O kernel retenta, depois desiste. A caracteristica definidora e a espera de varios segundos a dezenas de segundos antes da falha.

Connection timed out aparece quando voce envia um SYN ao destino, nenhum SYN+ACK retorna, e o kernel esgota suas retransmissoes e desiste. No nivel de chamada de sistema, connect() retorna ETIMEDOUT, que as aplicacoes apresentam como "Connection timed out".

$ ssh user@192.0.2.10
ssh: connect to host 192.0.2.10 port 22: Connection timed out

$ curl http://192.0.2.10/
curl: (28) Failed to connect to 192.0.2.10 port 80 after 129000 ms: Connection timed out

O que o diferencia de refused (rejeitado instantaneamente) e No route to host (retornado inacessivel instantaneamente) e que ele falha apos um longo silencio. Esse silencio e a assinatura de "alguem esta descartando pacotes sem dizer nada" -- quase sempre um firewall DROP ou um host ausente.

Pre-requisitos

SO: Ubuntu / uma distribuicao Linux tipica (usa ss / traceroute / tcpdump)
Alvo: um host que voce quer alcancar por IP e porta
Algumas verificacoes precisam de sudo (tcpdump / nft, etc.)

Qual a diferenca de refused e No route to host?

Conclusao: Refused significa "chegou mas a porta rejeitou (RST instantaneo)", No route to host significa "nao ha caminho (ICMP instantaneo)", e timed out significa "nenhuma resposta (longa espera)". Mesma conexao falhada -- o tempo antes da resposta indica qual camada esta com problema.

Erros de conexao se dividem em tres familias pela forma como a resposta retorna. Determine primeiro qual voce tem.

Erro	O que retorna	Camada da causa
Connection refused	TCP RST (instantaneo)	Servico / porta (L4, app)
No route to host	ICMP unreachable (instantaneo)	Rota / ARP / REJECT (L2-L3)
Connection timed out	Sem resposta (longa espera)	DROP / caminho silencioso (L3-L4)

$ time curl -sS http://192.0.2.10/

curl: (28) Failed to connect to 192.0.2.10 port 80 after 129000 ms: Connection timed out

real    2m9.012s

Se leva varios segundos ou mais para falhar, voce tem a familia timed-out: alguem esta descartando pacotes silenciosamente. Se falhou instantaneamente, o problema e outro. Para um servico parado ou porta fechada veja Diagnosticando Connection refused; para ausencia total de caminho veja Diagnosticando No route to host. Este artigo cobre Connection timed out.

Refused e "o host esta vivo mas a porta me recusou"; timed out e "ninguem responde". O primeiro da uma resposta clara (RST); o segundo e silencio. Silencio e a marca do DROP -- um firewall descartando com -j DROP, ou um host que nao esta la.

Por que "Connection timed out" acontece?

Conclusao: A causa se reduz a quatro coisas -- (1) firewall DROP (mais comum), (2) security group de cloud nao aberto, (3) host inativo ou sem listener, ou (4) blackhole no caminho. Trabalhe da camada mais proxima do seu host para fora.

Os caminhos que produzem ETIMEDOUT, organizados por causa:

Causa	O que esta acontecendo	Por onde comecar
Firewall DROP	O servidor / um dispositivo no caminho descarta SYN silenciosamente	`nft list ruleset`
Security group nao aberto	Um SG / NACL de cloud nao permite a porta	Console da cloud
Host inativo / sem listener	O servidor esta desligado / o servico nao iniciou	`ss -ltn` no servidor
Blackhole no caminho	Erro de roteamento / VPN ou buraco de rota consome pacotes	`traceroute` / `mtr`

Faca a triagem da camada mais proxima do seu host para fora. Primeiro confirme que realmente e timed out pela espera, depois veja ate onde no caminho os pacotes chegam, e finalmente inspecione o lado do servidor e seu firewall.

DROP e REJECT sao opostos. DROP descarta o pacote silenciosamente, entao o cliente nao ve resposta e da timeout. REJECT retorna um ICMP ou RST, entao o cliente ve No route to host ou refused. Resumindo: "um longo silencio = DROP", "um erro instantaneo = REJECT" -- o sintoma revela como o firewall esta descartando.

O que verificar primeiro? (Medir a espera)

Conclusao: Limite a espera com curl --connect-timeout ou nc -w e teste apenas a conexao. Se esperar o timeout completo antes de falhar, a ausencia de resposta (timed out) esta confirmada. Nao e necessario esperar o tempo padrao longo.

Primeiro defina um timeout curto e explicito e teste apenas a fase de conexao. Esperar o padrao (cerca de 2 minutos para curl) e desperdicio.

# Limitar o estabelecimento da conexao a 5 segundos
$ curl -sS --connect-timeout 5 http://192.0.2.10/

curl: (28) Failed to connect to 192.0.2.10 port 80 after 5001 ms: Connection timed out

nc (netcat) oferece uma verificacao de alcancabilidade ainda mais direta.

$ nc -vz -w3 192.0.2.10 80

nc: connect to 192.0.2.10 port 80 (tcp) failed: Connection timed out

Se falha apenas apos a espera completa (3 segundos acima), o destino nao esta retornando nada ao seu SYN. Se diz refused instantaneamente, a porta esta fechada mas o host esta respondendo -- isso nao e timed out.

--connect-timeout limita o estabelecimento da conexao, enquanto -m (--max-time) limita a transferencia inteira. Para triagem voce quer apenas a fase de conexao, entao use --connect-timeout. O timeout -w do nc tambem limita a espera de conexao.

Onde no caminho ele para? (traceroute / mtr)

Conclusao: Use traceroute / mtr para ver quantos saltos seus pacotes alcancam em direcao ao destino. O ponto apos o qual tudo vira * * * e o limite onde os pacotes desaparecem (sao DROPados).

Visualize onde no caminho os pacotes desaparecem.

$ traceroute -n 192.0.2.10

 1  10.0.0.1    0.4 ms   0.3 ms   0.3 ms
 2  100.64.0.1  1.2 ms   1.1 ms   1.0 ms
 3  * * *
 4  * * *

Se os saltos ate 2 respondem e do 3 em diante sao todos * * *, os pacotes estao sendo descartados silenciosamente naquele limite. Alem dele ha um blackhole, e um firewall ou buraco de roteamento e o suspeito.

Mas traceroute usa ICMP/UDP, entao em um ambiente onde TCP passa mas apenas ICMP e bloqueado, pode parecer incorretamente que "para no caminho". Para sondar com a porta que voce realmente quer, use o modo TCP.

# Trace com TCP SYN para a porta de destino 80
$ sudo traceroute -T -p 80 -n 192.0.2.10

Para uma visao continua, mtr e pratico.

$ mtr -n -T -P 80 192.0.2.10

Se apenas o ultimo salto e * * * enquanto tudo antes responde, o firewall do destino pode estar descartando ICMP mas passando TCP. Nao conclua DROP apenas por "traceroute parou" -- sempre confirme com o protocolo e porta em que voce quer conectar (-T -p).

Como confirmar que SYN fica sem resposta? (tcpdump)

Conclusao: Observar pacotes reais com tcpdump mostra diretamente que SYN e enviado mas nenhum SYN+ACK retorna. "Enviado mas sem resposta" no cliente e "SYN nunca chegou" no servidor delimitam onde o DROP esta.

Quando voce quer prova, observe os pacotes diretamente. Capture no cliente enquanto tenta a conexao.

# Execute em outro terminal, depois tente a conexao
$ sudo tcpdump -ni any host 192.0.2.10 and port 80

10:00:00.100 IP 10.0.0.42.51000 > 192.0.2.10.80: Flags [S], seq 1, ...
10:00:01.100 IP 10.0.0.42.51000 > 192.0.2.10.80: Flags [S], seq 1, ...
10:00:03.100 IP 10.0.0.42.51000 > 192.0.2.10.80: Flags [S], seq 1, ...

Apenas Flags [S] (SYN) e retransmitido em intervalos crescentes (1s, 2s, 4s...), e nenhum Flags [S.] (SYN+ACK) retorna. Isso e o timed out em si: o pacote nao alcanca o destino, ou chega e e ignorado.

Se voce consegue acessar o servidor, capturar no servidor tambem, ao mesmo tempo, torna decisivo.

# Execute no servidor
$ sudo tcpdump -ni any tcp port 80

SYN nao chega no servidor -> DROP no caminho (um roteador / SG de cloud)
SYN chega mas nao e respondido -> DROP do firewall local do servidor, ou nenhum listener

Ver os intervalos de retransmissao do SYN (o backoff exponencial de aproximadamente 1, 2, 4, 8 segundos) e em si prova solida de "sem resposta". A contagem de retentativas e definida por net.ipv4.tcp_syn_retries (padrao 6), e governa a espera total do cliente.

Como identificar um firewall DROP?

Conclusao: Se da timeout mas os pacotes chegam ao destino, uma regra -j DROP e o principal suspeito. No servidor, verifique nft list ruleset / iptables -L para ver se a porta esta permitida. Na cloud, o security group na frente do firewall do SO e a causa com muito mais frequencia.

Inspecione as regras de filtragem no servidor.

# Inspecionar regras nftables
$ sudo nft list ruleset | grep -i -E 'drop|policy'

# Em sistemas usando iptables
$ sudo iptables -L -n -v --line-numbers

Chain INPUT (policy DROP)
pkts bytes target  prot  ...  destination
 ...  ...  ACCEPT  tcp   ...  tcp dpt:22

Com policy DROP e apenas porta 22 permitida, um SYN para porta 80 e silenciosamente descartado e o cliente da timeout. Se voce usa ufw, verifique o que esta permitido.

$ sudo ufw status verbose

Para recuperar quando o ufw bloqueia ate o SSH, veja Troubleshooting ufw e SSH.

Na cloud (AWS / GCP / Azure, etc.), o security group ou network ACL na frente do firewall do SO e de longe o culpado mais frequente. Se nft list ruleset esta vazio mas ainda da timeout, primeiro verifique no console que o SG de cloud permite a porta (e a faixa de IP de origem). Um security group tem como padrao "negar todo inbound" (efetivamente DROP).

O servidor esta sequer escutando?

Conclusao: Mesmo com o firewall aberto, nada conecta se o servico nao esta rodando. No servidor, verifique ss -ltn para ver se a porta esta em LISTEN e se esta vinculada apenas a 127.0.0.1.

Se voce consegue acessar o servidor, verifique diretamente se a porta esta escutando.

$ ss -ltn

State   Recv-Q  Send-Q  Local Address:Port   Peer Address:Port
LISTEN  0       128         127.0.0.1:80          0.0.0.0:*
LISTEN  0       128           0.0.0.0:22          0.0.0.0:*

Se a porta 80 esta escutando em 127.0.0.1:80, ela aceita apenas conexoes locais e nada chega de fora (abrir o firewall nao ajudara). Corrija a configuracao de bind do servico para escutar em 0.0.0.0:80 (todas as interfaces) ou o IP relevante.

Se a porta nao esta na lista, o servico nao esta rodando. Verifique seu estado.

$ systemctl status nginx

Um bind 127.0.0.1 normalmente deveria produzir um refused instantaneo, nao um timeout -- mas se um firewall na frente faz DROP, o sintoma e mascarado como timed out. Quando "abri o firewall mas ainda nao conecta", sempre suspeite do endereco de bind.

Checklist quando ainda falha

Conclusao: Timed out significa "sem resposta". Trabalhando do seu host para fora -- tempo de espera -> caminho -> resposta SYN -> firewall -> listener -- a causa se reduz a DROP, security group, servico inativo ou blackhole no caminho.

[ ] Levou varios segundos ou mais para falhar (um erro instantaneo e refused / No route to host)?
[ ] Voce limitou a fase de conexao com curl --connect-timeout / nc -w?
[ ] Voce tracou com traceroute -T -p <port> na porta que realmente quer?
[ ] Voce encontrou qual salto vira * * * (o limite do DROP)?
[ ] O tcpdump mostrou SYN retransmitindo sem SYN+ACK?
[ ] O SYN chega no servidor tambem (nao = caminho / SG, sim = FW local / sem listener)?
[ ] Existe um DROP para a porta em nft list ruleset / iptables -L?
[ ] O security group / NACL da cloud permite a porta e a origem?
[ ] A porta esta em LISTEN em 0.0.0.0 (publicamente) em ss -ltn?