ERR_CONNECTION_REFUSED: O Que Significa e Como Corrigi-lo Completamente

O erro ERR_CONNECTION_REFUSED significa que o seu navegador enviou um pedido de ligação a um servidor web, e esse servidor rejeitou-o 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 de uma falha DNS (ERR_NAME_NOT_RESOLVED), e essa distinção é extremamente importante ao diagnosticar a causa raiz.

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

Compreender a Mecânica ao Nível TCP

A maioria dos guias de resolução de problemas de navegadores trata o ERR_CONNECTION_REFUSED como um vago "problema de rede". Não é. Ao nível TCP, uma ligaçã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 um descarte silencioso.

Esta distinção tem uma implicação prática no diagnóstico: se a ligação estivesse a ser descartada silenciosamente por uma firewall, veria ERR_CONNECTION_TIMED_OUT. Uma ligação recusada significa que algo está a responder ativamente — o que significa que o host é acessí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 no host (iptables, ufw, Windows Defender Firewall) está a rejeitar ligações na porta 80 ou 443
• Um proxy reverso (HAProxy, Nginx, Cloudflare) está mal configurado e a devolver pacotes RST upstream
• A aplicação por detrás do proxy falhou, deixando o proxy sem backend para onde 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 alterar quaisquer definições locais, verifique se o site está inacessível para todos ou apenas para si. Utilize estas ferramentas:

• downforeveryoneorjustme.com — verificação simples de disponibilidade
• isitdownrightnow.com — inclui histórico de tempos de resposta
• ping.pe — faz ping ao destino a partir de múltiplas localizações globais simultaneamente

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

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

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

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

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

Se o resultado estiver vazio para a porta 80 ou 443, o processo do 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

Verifique também se a sua firewall não está a bloquear ligações de entrada:

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

# If using ufw
sudo ufw status verbose

Se a porta 443 estiver bloqueada, permita-a:

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

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

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

Para problemas do lado do cliente, reiniciar o router limpa as tabelas NAT, concessões DHCP e quaisquer falhas de encaminhamento transitórias. Desligue o router durante 30 segundos e volte a ligá-lo. Isto é especialmente eficaz quando o erro apareceu subitamente sem quaisquer alterações de configuração.

Passo 4: Limpar a Cache DNS

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

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 que IP o domínio resolve agora:

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

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

Passo 5: Limpar a Cache e Cookies do Navegador

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

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

Defina o intervalo de tempo para Todo o período, marque Imagens e ficheiros em cache e Cookies e outros dados de sites, 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 de Navegação Anónima (Ctrl + Shift + N). Se o site carregar em modo anónimo mas não numa janela normal, um recurso em cache ou uma extensão do navegador é o culpado.

Passo 6: Auditar e Desativar as Definições de Proxy

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

No Windows:

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

netsh winhttp reset proxy

No macOS:

Vá a 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 era a causa. Reconfigure-o corretamente ou remova-o completamente.

Passo 7: Alterar o Seu Resolvedor DNS

O resolvedor DNS predefinido do seu ISP pode estar a devolver resultados incorretos, a sofrer uma interrupção, ou a bloquear ativamente determinados 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á a 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 a Firewall e o Antivírus

Alguns produtos antivírus e firewalls baseadas no host intercetam o 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 de destino 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 de destino em vez de deixar o software desativado. Reative-o imediatamente após os testes.

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 definição de proxy específica do Chrome. Tente criar um novo perfil Chrome para isolar o problema.

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

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

Um certificado SSL mal configurado pode fazer o servidor falhar ou recusar ligações TLS, que o Chrome reporta como ERR_CONNECTION_REFUSED em vez de um erro de certificado em alguns casos extremos. Utilize o seguinte para testar a partir da linha de comandos:

curl -vI https://yourdomain.com

Procure a fase de handshake TLS no resultado detalhado. Uma falha aqui indica um problema de certificado ou de conjunto de cifras. 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 SSL Certificates são válidos, corretamente encadeados e instalados na interface de servidor correta.

ERR_CONNECTION_REFUSED vs. Erros de Navegador Semelhantes

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

Casos Extremos Avançados e Armadilhas

Conflitos de resolução IPv6 vs. IPv4: Se um domínio resolve para um endereço IPv6 mas a sua rede não suporta IPv6 corretamente, o Chrome pode tentar uma ligação IPv6 que é recusada, e depois falhar ao reverter rapidamente para IPv4. Desativar temporariamente o IPv6 no adaptador de rede pode confirmar isto. No Linux, pode forçar IPv4 com curl -4 https://example.com.

Erros de origem desatualizados em cache do Cloudflare ou CDN: Se um site utiliza Cloudflare e o servidor de origem fica inativo, o Cloudflare pode servir uma versão em cache durante algum tempo, e depois começar a devolver erros 521 (origem recusou ligação) ou 522, que o Chrome pode apresentar como ERR_CONNECTION_REFUSED dependendo de como o erro é proxiado.

Ambientes de desenvolvimento localhost: Os programadores veem frequentemente ERR_CONNECTION_REFUSED ao aceder a localhost:3000 ou semelhante. 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.

Conflitos de porta de servidor de email: Se estiver 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 fazer o servidor web falhar ao vincular.

Limitações de alojamento partilhado: Em ambientes de Shared Web Hosting, uma recusa de ligaçã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 aponta para o IP partilhado correto. Verifique o painel de controlo do seu alojamento para o estado da conta e configuração DNS.

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

Utilize esta lista de verificação para fazer triagem eficientemente:

• O erro aparece em todos os sites simultaneamente — Verifique primeiro as definições de proxy e a configuração de VPN/firewall
• O erro aparece apenas num domínio específico — Verifique se o site está globalmente inacessível; depois limpe a cache DNS
• O erro aparece apenas no Chrome, não noutros navegadores — Limpe a cache do Chrome, desative extensões, ou crie um novo perfil Chrome
• O erro aparece apenas na sua rede, não com dados móveis — Reinicie o router; verifique o DNS ou firewall ao nível do ISP
• O erro aparece após uma alteração de configuração do servidor — Verifique o estado do processo do servidor web, vinculações de porta e regras de firewall no servidor
• O erro aparece intermitentemente sob carga — Investigue o esgotamento de recursos (descritores de ficheiros, memória, limites de ligaçã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 definições DNS — Reverta as alterações DNS e limpe a cache; verifique se o novo resolvedor é acessível

FAQ

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 de reset TCP, rejeitando a ligação imediatamente. ERR_CONNECTION_TIMED_OUT significa que não foi recebida nenhuma resposta dentro do período de timeout — os pacotes foram descartados silenciosamente. Uma ligação recusada aparece mais rapidamente e indica uma rejeição ativa, enquanto um timeout sugere uma regra DROP de encaminhamento ou firewall.

O 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 faz o processo do servidor web falhar no arranque ou falhar ao lidar com ligações TLS, resultando em nenhum listener na porta 443. O Chrome reporta então ERR_CONNECTION_REFUSED porque nada está a escutar, mesmo que a causa subjacente seja um problema de certificado.

Por que razão o ERR_CONNECTION_REFUSED aparece apenas num site específico?

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

Como corrijo o ERR_CONNECTION_REFUSED no localhost?

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

Limpar o DNS resolve sempre o ERR_CONNECTION_REFUSED?

Apenas quando a causa raiz é uma entrada de cache DNS desatualizada a apontar para um endereço IP onde o serviço já não está em execução. Se o servidor estiver inativo, a firewall estiver a bloquear a ligação, ou o proxy estiver mal configurado, limpar o DNS não terá qualquer efeito. Utilize dig ou nslookup para verificar a resolução DNS antes e depois de limpar para confirmar se o DNS era realmente o problema.