ERR_CONNECTION_TIMED_OUT: o servidor não responde a tempo

O que o erro significa

O navegador resolveu o nome, enviou o pedido de conexão para a porta 443 (ou 80) e esperou. Nada chegou: nem resposta, nem recusa. Depois de um tempo o Chrome desiste e mostra ERR_CONNECTION_TIMED_OUT abaixo de “Não é possível acessar esse site”; o Firefox diz “Tempo limite de conexão esgotado”. A diferença para o ERR_CONNECTION_REFUSED importa: em uma conexão recusada, o servidor responde ativamente “aqui não tem nada”; em um timeout, ninguém responde. Recusada: a máquina funciona, mas o servidor web não. Timeout: os pacotes se perdem no caminho ou a máquina não consegue responder.

Causas frequentes

1. Um firewall descarta os pacotes. ufw, firewalld, iptables ou o grupo de segurança do provedor de nuvem usam drop em vez de reject: o pacote some em silêncio e o navegador espera em vão. Típico depois de um servidor novo ou de uma mudança de regras.
2. O servidor ou o serviço está travado ou sobrecarregado. A máquina responde ao ping, mas o nginx, o Apache ou o PHP-FPM estão com todas as conexões ocupadas, ou a memória acabou. As conexões novas ficam na fila até o navegador desistir.
3. IP errado no DNS. Depois de uma mudança de servidor, o registro A ainda aponta para a máquina antiga, já desligada: o nome resolve, mas lá ninguém responde.
4. A rede do visitante. Um roteador que bloqueia o destino, uma VPN que caiu, um proxy da empresa, um filtro de conteúdo ou uma operadora com problema de roteamento.
5. MTU ou IPv6. O domínio tem um registro AAAA, mas o servidor não responde em IPv6; ou um túnel reduz o tamanho máximo dos pacotes e as conexões TLS param no meio.

Se você é visitante

1. Abra o site pelo celular sem Wi-Fi. Se assim funcionar, o problema está na sua rede, não no site.
2. Desconecte a VPN e desative um proxy manual que você não usa.
3. Reinicie o roteador e limpe o cache DNS (ipconfig /flushdns no Windows, sudo dscacheutil -flushcache no macOS, sudo resolvectl flush-caches no Linux).
4. Tente em uma janela anônima e em outro navegador.
5. Se não responder nem de outra rede e de outro aparelho, só o dono do site pode resolver.

Se o site é seu: verifique primeiro

Abra o website down checker: se o servidor não responde nem a partir do nosso local de verificação na Europa, a falha não está na sua rede. Depois, na linha de comando:

# para qual endereço o domínio aponta?
dig +short example.com A
dig +short example.com AAAA

# o servidor responde? (-v mostra em que passo ele para)
curl -v --max-time 10 -4 https://example.com/
curl -v --max-time 10 -6 https://example.com/

Se curl -4 entra e curl -6 fica pendurado, o problema é o IPv6. Se o curl para em “Trying 203.0.113.10:443…”, os pacotes se perdem antes de chegar ao servidor web. Entre por SSH (se nem o SSH responder, pule para a seção sobre a hospedagem):

# quem escuta nas portas 80 e 443, e em qual endereço?
sudo ss -tlnp | grep -E ':80 |:443 '

# regras do firewall
sudo ufw status verbose

# carga, memória, disco
uptime
free -h
df -h

Soluções no seu servidor

1. Abrir o firewall

# ufw
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

Em um servidor na nuvem, confira também o grupo de segurança do provedor: ele bloqueia antes de o pacote chegar à sua máquina, e de dentro não se vê. Se você usa fail2ban, verifique se ele não baniu seu próprio IP.

2. Aliviar um servidor sobrecarregado

Se uptime mostra uma carga bem acima do número de núcleos, ou free -h mostra a memória esgotada, o servidor aceita conexões devagar demais. Procure o processo responsável com top e leia o log do PHP-FPM: server reached pm.max_children quer dizer que todos os workers estão ocupados, muitas vezes por uma consulta lenta ou uma enxurrada de bots. Reinicie o serviço afetado depois de testar a configuração dele:

sudo nginx -t && sudo systemctl restart nginx
sudo systemctl restart php8.4-fpm
sudo tail -n 50 /var/log/nginx/error.log

Se isso se repete todo dia, aumente os workers se a memória permitir, coloque um cache na frente da aplicação e bloqueie os bots inúteis.

3. Corrigir o IP no DNS

Compare dig +short example.com A com hostname -I no servidor. Se não baterem, corrija o registro A no seu provedor de DNS. Se o servidor não tem IPv6 público, remova o registro AAAA: um AAAA sem servidor atrás produz exatamente este erro para uma parte dos visitantes.

4. Escutar em todos os endereços

No nginx, o bloco server precisa de listen 443 ssl; e listen [::]:443 ssl;. Se ele escuta só em 127.0.0.1, de fora ninguém responde. Depois da mudança: sudo nginx -t && sudo systemctl reload nginx.

Se o problema está na sua hospedagem

Em uma hospedagem compartilhada, você não controla nem o firewall nem a carga. Se o site não responde de fora e o SSH também não, envie esta mensagem:

Prezados, meu site example.com não responde desde aproximadamente 9h30 (UTC): os navegadores mostram ERR_CONNECTION_TIMED_OUT e a porta 443 não responde. O domínio resolve para 203.0.113.10, o IP da minha hospedagem. Não alterei nada do meu lado. O servidor dessa máquina está sobrecarregado ou parado, ou existe um bloqueio no firewall?

Para não acontecer de novo

Um servidor que fica mudo é o caso em que o dono demora mais para perceber: nenhuma página de erro, só silêncio. Uma verificação vinda de fora nota na primeira tentativa que falha. No seu servidor, o monitoramento de servidores com agente de servidor avisa antes, quando a carga sobe, a memória acaba ou o disco enche.

Fora do ar? Nós resolvemos. No seu servidor ou em uma hospedagem compartilhada com acesso SSH, o Quick Fix, o reparo automático a preço fixo, reinicia o serviço parado se o teste da configuração passar, 24 horas por dia, inclusive nos fins de semana; o Deep Fix cuida do firewall, da sobrecarga ou do DNS, em blocos de 15 minutos; a estimativa é o valor máximo.