ERR_CONNECTION_REFUSED: O Que Significa e Como Corrigir

O Que É o ERR_CONNECTION_REFUSED?

O ERR_CONNECTION_REFUSED é um erro do Chrome que aparece quando o navegador chega ao servidor do site, mas o servidor recusa ativamente a conexão. No nível da rede, o seu computador enviou uma solicitação de conexão TCP (SYN) para o endereço IP e a porta do servidor e, em vez de aceitá-la, o servidor — ou um firewall na frente dele — respondeu com um pacote de reset (RST) que diz "nada aqui vai falar com você".

Isso torna o ERR_CONNECTION_REFUSED fundamentalmente diferente de erros de DNS como o DNS_PROBE_FINISHED_NXDOMAIN. Em um erro de DNS, o nome de domínio nunca chegou a ser resolvido para um endereço IP. No ERR_CONNECTION_REFUSED, o DNS funcionou perfeitamente — o navegador sabe exatamente onde o servidor está — mas a máquina naquele endereço se recusou a abrir a porta.

A recusa geralmente significa uma de três coisas: nenhum serviço está escutando naquela porta (o servidor web está fora do ar ou travou), um firewall está rejeitando o tráfego para aquela porta, ou o seu dispositivo está se conectando ao endereço IP errado — por exemplo, por causa de um cache de DNS desatualizado ou de um proxy quebrado.

Como Esse Erro Aparece em Outros Navegadores

Cada navegador relata uma conexão recusada de um jeito, mas a rejeição TCP por trás é idêntica.

Os navegadores baseados em Chromium (Chrome, Edge, Brave, Opera) exibem o código bruto ERR_CONNECTION_REFUSED. O Firefox e o Safari usam uma linguagem mais simples, mas a causa e as correções são exatamente as mesmas.

Causas Comuns do ERR_CONNECTION_REFUSED

Em cerca de metade dos casos o problema está do lado do servidor, e na outra metade algo no seu dispositivo ou na sua rede está interferindo. Aqui estão as causas mais comuns, da mais frequente para a menos frequente.

• O servidor do site está fora do ar — O serviço web (nginx, Apache, Node.js) travou, está reiniciando ou foi parado. A máquina está online, mas nada responde nas portas 80/443.

• Firewall bloqueando a porta — Um firewall no servidor, na sua rede ou no seu dispositivo rejeita conexões para aquela porta.

• Configurações de proxy incorretas — O seu sistema roteia o tráfego por um servidor proxy que está offline ou inacessível. Esta é uma das causas mais comuns do lado do cliente.

• Cache de DNS desatualizado — O site migrou para um servidor novo, mas a entrada DNS em cache ainda aponta para o IP antigo, onde nada está mais escutando.

• Interferência de VPN ou antivírus — O software de segurança intercepta a conexão e a rejeita, ou o servidor de saída da VPN não consegue alcançar o site.

• Interferência de extensões do navegador — Bloqueadores de anúncios, extensões de privacidade ou extensões infectadas por malware podem bloquear conexões a hosts específicos.

• Substituição no arquivo hosts — O domínio está mapeado para um IP errado (geralmente 127.0.0.1) no seu arquivo hosts, então o navegador se conecta à sua própria máquina, que recusa.

• Nada escutando no localhost — Para desenvolvedores: o servidor de desenvolvimento local não está rodando, travou ou está vinculado a uma porta diferente da que você abriu.

• Problema no router — Um router ou modem com defeito embaralha as conexões até ser reiniciado.

Correção 1: Verifique Se o Site Está Fora do Ar para Todos

Antes de mudar qualquer coisa no seu dispositivo, descubra se o problema está do lado do servidor — se o site está fora do ar para todos, nenhuma correção local vai ajudar.

O jeito mais limpo de testar é por um caminho de rede diferente. Abra o site no seu celular usando dados móveis (Wi-Fi desligado). Se falhar lá também, o próprio servidor está recusando conexões e você só precisa esperar o dono do site resolver.

Você também pode testar o servidor diretamente com estas ferramentas do DNS Robot:

• [Verificador de Portas](/port-checker) — Digite o domínio do site e teste a porta 443 (HTTPS) e a porta 80 (HTTP). Se ambas aparecerem fechadas, o servidor web está fora do ar ou bloqueado por firewall para todo mundo, não só para você.

• [Teste de Ping](/ping) — Verifica se a máquina do servidor responde de alguma forma. Se o ping funciona mas as portas estão fechadas, a máquina está no ar, porém o serviço web está morto.

• [Verificador de Cabeçalhos HTTP](/http-headers) — Envia uma solicitação HTTP real a partir dos servidores do DNS Robot. Se ele recebe resposta e o seu navegador não, o problema é local, no seu dispositivo ou na sua rede.

Correção 2: Reinicie o Router e o Dispositivo

O clássico primeiro passo tem um motivo: reiniciar limpa a tabela de conexões do router, o cache de DNS e qualquer estado de NAT com defeito que possa causar conexões recusadas.

Desligue o router (e o modem, se for separado) da tomada, aguarde 30 segundos, ligue de volta e dê 2–3 minutos para ele se reconectar por completo. Reinicie também o computador ou o celular para redefinir a pilha de rede e tente o site de novo.

Correção 3: Limpe o Cache e os Cookies do Navegador

O Chrome pode ter armazenado em cache um redirecionamento quebrado, uma entrada HSTS antiga ou cookies que levam você a um servidor morto. Limpá-los força uma conexão totalmente nova.

• Abra o Chrome → clique no menu de três pontos → Excluir dados de navegação

• Período → selecione Todo o período

• Marque "Cookies e outros dados do site" e "Imagens e arquivos armazenados em cache"

• Clique em Excluir dados, reinicie o Chrome e tente acessar o site novamente

Correção 4: Desative as Configurações de Proxy

Um proxy mal configurado ou morto é uma das causas mais comuns de ERR_CONNECTION_REFUSED em todos os sites ao mesmo tempo. Quando o sistema está configurado para rotear o tráfego por um proxy que não existe mais — muitas vezes deixado por uma VPN antiga, uma configuração da escola/trabalho ou malware — toda conexão é recusada.

Windows: Abra Configurações → Rede e Internet → Proxy. Desative "Usar um servidor proxy" em Configuração manual de proxy e desative "Detectar configurações automaticamente" se você não usa um proxy corporativo.

macOS: Abra Ajustes do Sistema → Rede → Wi-Fi → Detalhes → Proxies. Desmarque todos os protocolos da lista (Proxy da web HTTP, Proxy seguro da web HTTPS, Proxy SOCKS), a menos que a sua organização exija um, e clique em OK.

O Chrome usa as configurações de proxy do sistema operacional, então, depois de alterá-las, reinicie o navegador e teste de novo.

Correção 5: Limpe o Cache de DNS

Se o site migrou recentemente para um servidor novo, a entrada DNS em cache pode ainda apontar para o endereço IP antigo — onde nada está mais escutando, então a conexão é recusada. Limpar o cache força o seu dispositivo a consultar o endereço atual.

# Windows (Command Prompt as Administrator)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

# Also clear Chrome's internal DNS cache:
# chrome://net-internals/#dns → Clear host cache

Depois de limpar, limpe também o cache de DNS interno do Chrome em chrome://net-internals/#dns e esvazie os pools de socket em chrome://net-internals/#sockets — o Chrome mantém os dois separados do sistema operacional. Para o passo a passo completo, veja o nosso guia sobre como limpar o DNS em todos os sistemas.

Você pode confirmar para qual IP o domínio resolve atualmente com o DNS Lookup do DNS Robot — se o nslookup do seu terminal mostrar um IP diferente do resultado global, o seu cache era o problema.

Correção 6: Mude para um Servidor DNS Público

Se o servidor DNS do seu provedor de internet está retornando registros desatualizados, limpar o cache não vai ajudar — você só vai buscar de novo o mesmo IP antigo. Mudar para um resolver público rápido traz registros atuais e muitas vezes acelera a navegação como um todo.

Windows: Configurações → Rede e Internet → sua conexão → Editar ao lado de Atribuição de servidor DNS → Manual → ative o IPv4 → insira 1.1.1.1 e 1.0.0.1 → Salvar.

macOS: Ajustes do Sistema → Rede → Wi-Fi → Detalhes → DNS → adicione 1.1.1.1 e 1.0.0.1, remova as entradas antigas → OK.

Não sabe qual resolver é o mais rápido na sua região? Rode o Teste de Velocidade DNS do DNS Robot — ele faz o benchmark de Cloudflare, Google, Quad9 e outros a partir da sua própria conexão em segundos.

Correção 7: Desative Temporariamente VPN, Antivírus e Firewall

VPNs, escudos web de antivírus e firewalls ficam todos entre o seu navegador e a internet, e cada um deles pode rejeitar conexões. Os recursos de escaneamento de HTTPS dos antivírus são um vilão frequente: eles fazem o seu tráfego seguro passar por um serviço local, e quando esse serviço quebra, todos os sites HTTPS são recusados.

Teste nesta ordem: desconecte a VPN e recarregue. Depois, desative o módulo de proteção web do antivírus por um minuto e recarregue. Por fim, desligue brevemente o firewall (Firewall do Windows Defender ou Firewall do macOS) e recarregue.

Se o site carregar depois de desativar um deles, reative-o e adicione uma exceção para o site — ou troque para outra localização de servidor da VPN — em vez de deixar a proteção desligada.

Correção 8: Teste as Extensões no Modo Anônimo

Bloqueadores de anúncios, ferramentas de privacidade e extensões de VPN podem bloquear silenciosamente conexões a hosts específicos. O teste rápido: abra o site em uma janela anônima (Ctrl+Shift+N / Cmd+Shift+N), onde a maioria das extensões fica desativada por padrão.

Se o site carregar no modo anônimo, uma extensão é a causa. Vá em chrome://extensions, desative todas e reative uma por vez até o erro voltar — essa é a culpada. Remova-a ou exclua o site dos filtros dela.

Correção 9: Verifique o Seu Arquivo Hosts

O arquivo hosts substitui o DNS para domínios específicos. Se o site estiver mapeado lá para 127.0.0.1, 0.0.0.0 ou um IP de servidor antigo, o navegador se conecta a esse endereço — e é recusado. Entradas de desenvolvimento esquecidas e listas de hosts para bloqueio de anúncios são os suspeitos de sempre.

# Windows — open as Administrator:
notepad C:\Windows\System32\drivers\etc\hosts

# macOS / Linux:
sudo nano /etc/hosts

# Look for lines containing the domain, e.g.:
# 127.0.0.1   example.com   ← forces the connection to your own PC
# 203.0.113.7 example.com   ← forces an old server IP

# Delete the offending line, save, then flush DNS.

Localhost Recusou a Conexão (Para Desenvolvedores)

Ver localhost recusou a conexão ou ERR_CONNECTION_REFUSED em 127.0.0.1 é um rito de passagem para todo desenvolvedor. Significa que nada na sua máquina está aceitando conexões na porta que você pediu. Os motivos usuais:

• O servidor de desenvolvimento não está rodando — Você nunca o iniciou, ou ele travou. Verifique o terminal onde npm run dev, rails s ou python manage.py runserver deveria estar rodando.

• Porta errada — O servidor iniciou em outra porta (ex.: 3001, porque a 3000 estava ocupada) e você está abrindo a antiga. Leia a linha do log de inicialização que diz em qual porta ele foi vinculado.

• Vinculado a outra interface — O servidor foi vinculado a 0.0.0.0 ou ao IP interno de um container, mas você está acessando localhost — ou vice-versa. Os mapeamentos de porta do Docker (-p 3000:3000) precisam corresponder à porta em que o app escuta dentro do container.

• Firewall ou software de segurança — Firewalls locais podem bloquear até portas de loopback; isso é comum em máquinas corporativas.

• HTTPS vs HTTP — Você está abrindo https://localhost:3000, mas o servidor de desenvolvimento só fala HTTP puro. Tente http:// explicitamente.

# Which process is listening on port 3000?
# macOS / Linux:
lsof -i :3000

# Windows (PowerShell):
netstat -ano | findstr :3000

# No output = nothing is listening = connection refused.
# Start your dev server, or kill the stale process and restart it.

Se você precisar verificar se uma porta do seu servidor público está acessível a partir da internet (e não apenas da própria máquina), use o Verificador de Portas do DNS Robot — ele testa a conexão de fora da sua rede, que é o que os seus visitantes realmente experimentam.

Para Donos de Sites: O Seu Site Recusa Conexões

Se os visitantes relatam ERR_CONNECTION_REFUSED no seu próprio site, o servidor está no ar (o DNS resolve, a máquina provavelmente responde a ping), mas o serviço web não está aceitando conexões. Percorra esta checklist:

• O processo do servidor web está rodando? Entre via SSH e verifique: systemctl status nginx (ou apache2, caddy). Um processo que travou após um reload mal-sucedido ou foi morto por falta de memória é a causa nº 1. Reinicie-o: sudo systemctl restart nginx.

• Ele está escutando nas portas certas? Rode ss -tlnp | grep -E ':80|:443'. Se nada escuta na 443, a sua configuração TLS falhou ao carregar — verifique erros de configuração com nginx -t.

• O firewall está aberto? Verifique ufw status ou o security group do seu provedor de nuvem. As portas 80 e 443 precisam permitir TCP de entrada de 0.0.0.0/0.

• O IP do servidor mudou? Compare o registro A do seu DNS com o IP real do servidor usando o DNS Lookup. Depois de uma migração, um registro A antigo manda os visitantes para a máquina anterior.

• Teste de fora — Use o Verificador de Portas nas portas 80 e 443 e o Verificador de Cabeçalhos HTTP para confirmar que o seu servidor responde a solicitações reais vindas da internet pública.

Como Verificar Se a Correção Funcionou

Depois de cada correção, confirme a conexão no nível da rede em vez de apenas recarregar a página — isso diz se a porta realmente abriu.

# Test the TCP connection directly (Mac/Linux):
nc -zv example.com 443
# "succeeded" = port open, "refused" = still rejected

# Windows (PowerShell):
Test-NetConnection example.com -Port 443
# TcpTestSucceeded : True = fixed

# Then confirm what IP you're actually connecting to:
nslookup example.com

Ou pule o terminal: digite o domínio e a porta no Verificador de Portas do DNS Robot para uma resposta instantânea de aberta/fechada a partir de uma rede externa. Se a porta está aberta externamente mas o navegador ainda mostra ERR_CONNECTION_REFUSED, o bloqueio está no seu dispositivo — revisite as correções de proxy, VPN, antivírus e arquivo hosts acima.