ERR_CONNECTION_REFUSED: O Que Significa e Como Corrigir Completamente

O erro ERR_CONNECTION_REFUSED significa que o seu navegador enviou um pedido de conexão para um servidor web, e esse servidor o rejeitou ativamente — não o ignorou, mas recusou explicitamente o handshake TCP. Este é um modo de falha fundamentalmente diferente de um timeout (ERR_CONNECTION_TIMED_OUT) ou uma falha de DNS (ERR_NAME_NOT_RESOLVED), e essa distinção é enormemente importante ao diagnosticar a causa raiz.

Em termos práticos, quando o Chrome exibe “Este site não pode ser alcançado. ERR_CONNECTION_REFUSED,” significa uma de três coisas: o servidor de destino não está escutando na porta solicitada, um firewall ou camada de segurança está enviando um pacote TCP RST (reset) de volta para o seu cliente, ou a sua pilha de rede local está mal configurada e encaminhando o pedido incorretamente antes de chegar ao servidor. Identificar qual dessas três categorias se aplica à sua situação é o caminho mais rápido para uma solução.

Compreender a Mecânica ao Nível do TCP

A maioria dos guias de resolução de problemas do navegador trata ERR_CONNECTION_REFUSED como um vago “problema de rede”. Não é. Ao nível do TCP, uma conexão recusada significa que o servidor (ou um intermediário) enviou de volta um pacote RST/ACK em resposta ao pacote SYN do seu navegador. Esta é uma rejeição explícita, não uma queda silenciosa.

Esta distinção tem uma implicação prática de diagnóstico: se a conexão estivesse a ser silenciosamente descartada por uma firewall, veria ERR_CONNECTION_TIMED_OUT. Uma conexão recusada significa que algo está a responder ativamente — o que significa que o host é alcançável ao nível da rede, mas o serviço na porta de destino está indisponível ou bloqueado.

As causas comuns ao nível da porta incluem:

• O processo do servidor web (Apache, Nginx, Node.js) falhou ou parou
• O servidor está a escutar numa porta não-padrão e o URL não a especifica
• Uma firewall baseada em host (iptables, ufw, Windows Defender Firewall) está a rejeitar conexões na porta 80 ou 443
• Um proxy reverso (HAProxy, Nginx, Cloudflare) está configurado incorretamente e a devolver pacotes RST a montante
• A aplicação atrás do proxy falhou, deixando o proxy sem backend para encaminhar

Causas Raiz: Uma Análise Estruturada

Causas do Lado do Cliente

Causas do Lado do Servidor

Guia de Diagnóstico e Correção Passo a Passo

Passo 1: Determinar Se o Problema É Global ou Local

Antes de tocar em qualquer configuração local, estabeleça se o site está inativo para todos ou apenas para você. Use estas ferramentas:

• downforeveryoneorjustme.com — verificação simples de ativo/inativo
• isitdownrightnow.com — inclui histórico de tempo de resposta
• ping.pe — faz ping no alvo a partir de múltiplas localizações globais simultaneamente

Se o site está acessível a partir de nós externos, mas não a partir da sua máquina, o problema é local. Se está inacessível globalmente, o problema é do lado do servidor e fora do seu controle — contacte o administrador do site ou aguarde.

Para administradores de servidor que gerem a sua própria infraestrutura, um site globalmente inacessível justifica investigação imediata do processo do servidor web, regras de firewall e rede upstream. Se está a executar um ambiente de VPS Hosting, verifique primeiro a lista de processos do seu servidor e a configuração do firewall.

Passo 2: Verificar Se o Servidor Está Realmente a Escutar (Para Administradores de Servidor)

Se administra o servidor em questão, SSH e execute o seguinte para confirmar o que está a escutar em quais portas:

sudo ss -tlnp | grep -E ':80|:443'

Se a saída estiver vazia para a porta 80 ou 443, o seu processo de servidor web não está em execução. Reinicie-o:

# For Nginx
sudo systemctl restart nginx

# For Apache
sudo systemctl restart apache2

# Check status
sudo systemctl status nginx

Também verifique se o seu firewall não está a bloquear conexões de entrada:

# Check iptables rules
sudo iptables -L INPUT -n -v

# If using ufw
sudo ufw status verbose

Se a porta 443 está bloqueada, permita-a:

sudo ufw allow 443/tcp
sudo ufw allow 80/tcp
sudo ufw reload

Para administradores que executam Servidores Dedicados, verifique também se as regras de firewall upstream do seu fornecedor de hospedagem ou as regras do grupo de segurança estão a bloquear a porta no perímetro da rede — isto é separado do firewall ao nível do SO.

Passo 3: Reiniciar o Seu Router e Limpar o Estado da Rede Local

Para problemas do lado do cliente, uma reinicialização do router limpa tabelas NAT, concessões DHCP e qualquer falha de encaminhamento transitória. Desconecte o router durante 30 segundos e depois reconecte. Isto é especialmente eficaz quando o erro apareceu de repente sem qualquer alteração de configuração.

Passo 4: Limpar a Cache DNS

Uma entrada de cache DNS obsoleta apontando para um endereço IP antigo ou desativado é uma das causas mais comuns de ERR_CONNECTION_REFUSED no lado do cliente. O servidor no IP em cache pode já não estar a executar o site alvo.

• No Windows:

ipconfig /flushdns

• No macOS (Ventura, Sonoma e a maioria das versões modernas):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• No Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

Após limpar, verifique para qual IP o domínio agora se resolve:

nslookup example.com
# or
dig +short example.com

Compare isto com o IP conhecido do site. Se forem diferentes, a propagação DNS pode ainda estar em progresso.

Passo 5: Limpar Cache e Cookies do Navegador

No Google Chrome, navegue para chrome://settings/clearBrowserData ou use o atalho de teclado:

• Windows/Linux: Ctrl + Shift + Delete
• macOS: Cmd + Shift + Delete

Defina o intervalo de tempo para Todo o tempo, marque Imagens e ficheiros em cache e Cookies e outros dados do site, depois clique em Limpar dados. Reinicie o Chrome completamente (não apenas o separador) antes de testar novamente.

Para um teste mais rápido sem limpar dados, abra uma janela Incógnito (Ctrl + Shift + N). Se o site carrega em Incógnito, mas não numa janela normal, um recurso em cache ou uma extensão do navegador é o culpado.

Passo 6: Auditar e Desativar Configurações de Proxy

Um servidor proxy mal configurado ou inativo é uma causa frequente de ERR_CONNECTION_REFUSED em todos os sites simultaneamente. O Chrome usa as configurações de proxy do sistema por padrão.

• No Windows:

Navegue para Definições > Sistema > Proxy e desative “Usar um servidor proxy” se estiver ativado sem o seu conhecimento. Alternativamente, execute isto a partir de uma Linha de Comandos elevada:

netsh winhttp reset proxy

• No macOS

Vá para Definições do Sistema > Rede, selecione a sua interface ativa, clique em Detalhes, depois no separador Proxies, e desmarque todos os protocolos de proxy ativos.

Após desativar o proxy, teste o site. Se carregar, a sua configuração de proxy foi a causa. Reconfigure-a corretamente ou remova-a completamente.

Passo 7: Alterar o Seu Resolvedor DNS

O resolvedor DNS padrão do seu ISP pode estar a devolver resultados incorretos, a sofrer uma interrupção ou a bloquear ativamente certos domínios. Mudar para um resolvedor público elimina esta variável.

Resolvedores DNS públicos recomendados:

• No Windows (via PowerShell):

Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1","1.0.0.1")

• No macOS:

Vá para Definições do Sistema > Rede > [A Sua Interface] > Detalhes > DNS, remova as entradas existentes e adicione 1.1.1.1 e 1.0.0.1.

• No Linux (systemd-resolved):

Edite /etc/systemd/resolved.conf:

[Resolve]
DNS=1.1.1.1 1.0.0.1
FallbackDNS=8.8.8.8 8.8.4.4

Depois reinicie o resolvedor:

sudo systemctl restart systemd-resolved

Passo 8: Desativar Temporariamente Firewall e Antivírus

Alguns produtos antivírus e firewalls baseados em host interceptam tráfego HTTPS através de um proxy local e podem emitir pacotes RST quando o seu motor de inspeção falha ou quando o domínio alvo está numa lista de bloqueio. Desativá-los temporariamente (apenas para fins de diagnóstico) confirma se são a causa.

Se desativar o software de segurança resolver o erro, adicione uma exceção específica para o domínio alvo em vez de deixar o software desativado. Reative-o imediatamente após o teste.

Passo 9: Testar com um Navegador e Rede Diferentes

Teste o URL no Firefox, Edge ou Safari. Se carregar noutro navegador, o problema é específico do Chrome — provavelmente um perfil corrompido, uma extensão com mau funcionamento ou uma configuração de proxy específica do Chrome. Tente criar um novo perfil do Chrome para isolar o problema.

Se o site falhar em todos os navegadores, mude para um hotspot móvel. Se carregar sobre dados móveis, o seu ISP ou router doméstico é a fonte do problema.

Passo 10: Verificar Problemas de Configuração SSL/TLS (Administradores de Servidor)

Um certificado SSL mal configurado pode fazer com que o servidor falhe ou recuse conexões TLS, o que o Chrome relata como ERR_CONNECTION_REFUSED em vez de um erro de certificado em alguns casos extremos. Use o seguinte para testar a partir da linha de comandos:

curl -vI https://yourdomain.com

Procure a fase de handshake TLS na saída detalhada. Uma falha aqui indica um problema de certificado ou suite de cifra. Também pode testar com:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

Se o seu certificado SSL expirou ou está mal configurado, renová-lo ou substituí-lo resolve o problema. Certifique-se de que os seus Certificados SSL são válidos, adequadamente encadeados e instalados na interface correta do servidor.

ERR_CONNECTION_REFUSED vs. Erros Semelhantes do Navegador

Compreender como este erro difere de erros relacionados previne diagnósticos incorretos:

Casos Extremos Avançados e Armadilhas

1) Conflitos de resolução IPv6 vs. IPv4:

Se um domínio é resolvido para um endereço IPv6 mas a sua rede não suporta IPv6 adequadamente, o Chrome pode tentar uma conexão IPv6 que é recusada, falhando então em fazer fallback para IPv4 rapidamente. Desabilitar IPv6 no adaptador de rede temporariamente pode confirmar isto. No Linux, pode forçar IPv4 com curl -4 https://example.com.

2) Cloudflare ou caching de CDN com erros de origem obsoletos:

Se um site usa Cloudflare e o servidor de origem fica inativo, o Cloudflare pode servir uma versão em cache por um tempo, depois começar a retornar erros 521 (origem recusou conexão) ou 522, que o Chrome pode exibir como ERR_CONNECTION_REFUSED dependendo de como o erro é proxied.

3) Ambientes de desenvolvimento localhost:

Desenvolvedores frequentemente veem ERR_CONNECTION_REFUSED ao aceder a localhost:3000 ou similar. A causa é quase sempre que o processo do servidor de desenvolvimento não está em execução, falhou, ou está vinculado a 127.0.0.1 numa porta diferente da esperada. Execute ss -tlnp | grep node (ou o processo relevante) para confirmar o que está realmente a escutar.

4) Conflitos de porta do servidor de email:

Se está a executar Email Hosting no mesmo servidor que a sua aplicação web, certifique-se de que conflitos de porta entre SMTP (25, 587), IMAP (993), e HTTP/HTTPS (80, 443) não estão a causar falha na vinculação do servidor web.

5) Limitações de alojamento partilhado:

Em ambientes de Alojamento Web Partilhado, uma recusa de conexão pode indicar que o servidor do fornecedor de alojamento está sobrecarregado, a conta foi suspensa, ou o DNS do domínio ainda não está a apontar para o IP partilhado correcto. Verifique o painel de controlo do seu alojamento para o estado da conta e configuração de DNS.

Matriz de Decisão Prática: Qual Correção Aplicar Primeiro

Use esta checklist para fazer triagem eficientemente:

• O erro aparece em todos os sites simultaneamente — Verifique as configurações de proxy e a configuração de VPN/firewall primeiro
• O erro aparece apenas em um domínio específico — Verifique se o site está globalmente inativo; depois limpe o cache DNS
• O erro aparece apenas no Chrome, não em outros navegadores — Limpe o cache do Chrome, desative extensões ou crie um novo perfil do Chrome
• O erro aparece apenas na sua rede, não nos dados móveis — Reinicie o router; verifique DNS ou firewall no nível do ISP
• O erro aparece após uma alteração de configuração do servidor — Verifique o status do processo do servidor web, vinculações de porta e regras de firewall no servidor
• O erro aparece intermitentemente sob carga — Investigue esgotamento de recursos (descritores de arquivo, memória, limites de conexão) no servidor
• O erro aparece apenas em HTTPS, não em HTTP — Investigue a validade do certificado SSL e a configuração TLS
• O erro apareceu após alterar as configurações de DNS — Reverta as alterações de DNS e limpe o cache; verifique se o novo resolver está acessível

FAQ

1) Qual é a diferença entre ERR_CONNECTION_REFUSED e ERR_CONNECTION_TIMED_OUT?

ERR_CONNECTION_REFUSED significa que o servidor (ou uma firewall) enviou ativamente um pacote TCP reset, rejeitando a conexão imediatamente. ERR_CONNECTION_TIMED_OUT significa que nenhuma resposta foi recebida dentro do período de timeout — os pacotes foram silenciosamente descartados. Uma conexão recusada é mais rápida de aparecer e indica uma rejeição ativa, enquanto um timeout sugere uma regra de roteamento ou firewall DROP.

2) ERR_CONNECTION_REFUSED pode ser causado por um certificado SSL expirado?

Indiretamente, sim. Em algumas configurações de servidor, um certificado SSL expirado ou mal configurado causa a falha do processo do servidor web na inicialização ou travamento ao lidar com conexões TLS, resultando em nenhum listener na porta 443. Chrome então relata ERR_CONNECTION_REFUSED porque nada está escutando, mesmo que a causa subjacente seja um problema de certificado.

3) Por que ERR_CONNECTION_REFUSED aparece apenas em um site específico?

Se o erro está isolado em um único domínio, as causas mais prováveis são: o serviço web do servidor de destino travou, a firewall do servidor está bloqueando seu intervalo de IP, os registros DNS do domínio apontam para um endereço IP antigo onde nenhum serviço está em execução, ou o site foi removido. Use curl -v https://thatdomain.com de uma rede ou servidor diferente para isolar a causa.

4) Como corrijo ERR_CONNECTION_REFUSED no localhost?

O servidor de aplicação não está em execução ou está vinculado a uma porta diferente da que você está solicitando. Confirme o que está escutando com ss -tlnp no Linux/macOS ou netstat -ano | findstr :PORT no Windows. Inicie o processo do servidor de aplicação e certifique-se de que está vinculado a 0.0.0.0 ou 127.0.0.1 na porta esperada.

5) Limpar o DNS sempre corrige ERR_CONNECTION_REFUSED?

Apenas quando a causa raiz é uma entrada de cache DNS obsoleta apontando para um endereço IP onde o serviço não está mais em execução. Se o servidor está inativo, a firewall está bloqueando a conexão ou o proxy está mal configurado, limpar o DNS não terá efeito. Use dig ou nslookup para verificar a resolução DNS antes e depois de limpar para confirmar se o DNS era realmente o problema.