ERR_CONNECTION_REFUSED: conexão recusada, como corrigir

O que é o ERR_CONNECTION_REFUSED?

ERR_CONNECTION_REFUSED significa que o navegador encontrou o endereço IP do site, mas a máquina nesse endereço recusou a conexão. O Chrome mostra “Não é possível acessar esse site” com “A conexão com example.com foi recusada.” e o código ERR_CONNECTION_REFUSED, o erro -102 da lista do Chromium (net_error_list.h).

O seu dispositivo enviou um pedido de conexão TCP ao endereço IP e à porta do servidor (443 para HTTPS, 80 para HTTP) e recebeu uma recusa na hora: um reset de TCP ou uma mensagem de “port unreachable” (porta inacessível) de um firewall. Nenhum programa aceitava conexões naquela porta, ou um firewall rejeitou o pedido. O DNS funcionou; a conexão, não.

Em outras palavras, é uma resposta, não silêncio. Se nada responde, o Chrome espera e mostra ERR_CONNECTION_TIMED_OUT. Se a conexão abre e depois é cortada, é ERR_CONNECTION_RESET; se o servidor desliga antes de enviar a página, é ERR_CONNECTION_CLOSED.

Como esse erro aparece em outros navegadores e apps

Uma conexão recusada é o mesmo evento em qualquer lugar; só a mensagem muda. Os navegadores baseados em Chromium (Chrome, Edge, Brave, Opera) mostram o código ERR_CONNECTION_REFUSED, e os aplicativos relatam o erro do próprio sistema operacional:

As correções abaixo valem seja qual for a mensagem: algo naquele endereço e porta disse não.

Causas comuns do ERR_CONNECTION_REFUSED

As causas, do lado do site até o seu:

• O servidor do site está fora do ar — o servidor web (nginx, Apache, Node.js) caiu, está reiniciando ou foi parado. A máquina está online, mas nada responde na porta 80 ou 443.
• Um firewall configurado para rejeitar — um firewall no servidor, na sua rede ou no seu dispositivo que rejeita (em vez de descartar em silêncio) as conexões para aquela porta.
• O site bloqueia a sua rede — alguns sites rejeitam faixas inteiras de endereços, como servidores de saída de VPN ou um país inteiro.
• Software de segurança ou VPN — um escudo web de antivírus ou uma VPN que passa o seu tráfego por si mesma e recusa a conexão. (Um firewall no seu próprio dispositivo que bloqueia o Chrome mostra outra página, “O seu acesso à Internet está bloqueado”, ERR_NETWORK_ACCESS_DENIED.)
• O endereço IP errado — um cache de DNS desatualizado ou uma entrada do arquivo hosts leva você a um servidor antigo, ou ao seu próprio computador (127.0.0.1), onde nada está escutando.
• Um redirecionamento ou regra de HTTPS lembrado — o Chrome guardou um redirecionamento, ou a regra HSTS do site, e continua mandando você para uma porta que o site não atende mais.
• Nada escutando no localhost — para desenvolvedores: o servidor local não está rodando, caiu, ou está em outra porta ou endereço diferente do que você abriu.

Um site, todos os sites ou todos os navegadores?

Onde o erro aparece mostra onde procurar, antes de você mudar qualquer coisa:

“Em todos os navegadores” importa: Edge, Firefox e Safari não compartilham o cache nem as extensões do Chrome, então uma recusa em todos eles aponta para algo abaixo do navegador: o seu dispositivo, a rede ou o próprio site.

Correção 1: verifique se o site está fora do ar para todos

Antes de mudar qualquer coisa no seu dispositivo, descubra se o site recusa todo mundo. Se recusar, nenhuma correção do seu lado vai ajudar.

O teste mais rápido é outro caminho de rede: abra o site no celular usando dados móveis (Wi-Fi desligado). Depois teste o servidor de fora com estas ferramentas do DNS Robot:

• Verificador de site fora do ar — abre o site de 11 lugares e do seu próprio navegador. Fora do ar em todos: o problema é o site. No ar em todos menos no seu: o problema é do seu lado.
• Teste de portas — informe o site com a porta 443 (ou example.com:443). Fechada significa que o servidor recusou a nossa conexão também; aberta significa que ele aceita conexões e que a recusa é só sua.
• Teste de Ping — conecta ao site na porta 443 a partir de 11 cidades, mais um ping clássico de uma delas. Recusa em todas as cidades significa que a máquina está ligada mas nada escuta naquela porta; a falta de resposta ao ping clássico não prova nada, porque muitos servidores o ignoram.

Correção 2: reinicie o roteador e o dispositivo

A primeira sugestão do próprio Chrome, “Verificar a conexão”, diz para reiniciar “todos os roteadores, modens ou outros dispositivos de rede que você estiver usando”. Isso limpa o estado que o roteador acumulou, inclusive o cache de DNS.

Tire o roteador (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 os redirecionamentos e regras de HTTPS lembrados pelo Chrome

O Chrome lembra redirecionamentos permanentes e a regra HSTS de cada site (“sempre usar HTTPS”). Se o site mudou de lugar, ou deixou de servir HTTPS na porta 443, o Chrome continua mandando você para um endereço ou porta onde nada escuta.

• Abra o Chrome → menu de três pontos → Excluir dados de navegação
• Período → Todo o período, marque Imagens e arquivos em cache (os cookies podem ficar)
• Clique em Excluir dados (ou Excluir deste dispositivo, se você não estiver conectado ao Chrome) e tente o site de novo
• Ainda recusado? Abra chrome://net-internals/#hsts, digite o domínio em Delete domain security policies e clique em Delete. Isso só funciona para regras definidas pelo próprio site, não para domínios incluídos na lista de pré-carregamento HSTS do Chrome.

Uma mudança de 2026: o Chrome 154 (outubro de 2026) liga “Sempre usar conexões seguras” por padrão, então o Chrome pede a sua permissão antes da primeira visita a um site público sem HTTPS, em vez de tentar em silêncio (Google Security Blog).

Correção 4: verifique as configurações de proxy

A página de erro do Chrome lista o proxy, então verifique, mas saiba o que esperar. Quando o Chrome não consegue alcançar um servidor proxy, ele mostra uma página com o título “Sem Internet” e ERR_PROXY_CONNECTION_FAILED (“Há algo errado com o servidor proxy, ou o endereço está incorreto.”) em vez de ERR_CONNECTION_REFUSED. Se for essa a página que você vê, esta é a sua correção.

Windows: Configurações → Rede e Internet → Proxy. Em “Configuração manual de proxy”, clique em Editar (ou Configurar) ao lado de “Usar um servidor proxy”, desative a opção e clique em Salvar. Desative também “Usar script de configuração” se não reconhecer o endereço. Deixe “Detectar configurações automaticamente” ativado, a menos que você saiba que a sua rede não o usa.

macOS: Ajustes do Sistema → Rede → Wi-Fi → Detalhes → Proxies. Desative todos os proxies que a sua organização não configurou e clique em OK.

O Chrome usa as configurações de proxy do sistema, e o Firefox também por padrão (“Usar as configurações de proxy do sistema”), então um único proxy desatualizado quebra todos os navegadores de uma vez. Em um dispositivo da escola ou do trabalho, o administrador define o proxy e você não pode mudá-lo.

Correção 5: limpe o cache de DNS

Se o site migrou para um servidor novo, uma resposta de DNS em cache ainda pode apontar para o IP antigo, onde nada mais escuta. Limpar o cache faz o seu dispositivo buscar 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 sockets em chrome://net-internals/#sockets: o Chrome guarda 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.

Para ver o endereço que o seu computador realmente usa (arquivo hosts e cache incluídos), rode ping example.com, ou Resolve-DnsName example.com no PowerShell, e compare com a Consulta DNS. Não use o nslookup para isso: ele consulta o servidor DNS diretamente e ignora os dois.

Correção 6: mude para um servidor DNS público

Se o resolver do seu provedor continua entregando um endereço antigo depois de você limpar o cache, mude para um resolver público para obter uma resposta nova.

Windows: Configurações → Rede e Internet → Wi-Fi → “Gerenciar redes conhecidas” → sua rede (Ethernet → sua rede) → Editar ao lado de “Atribuição de servidor DNS” → Manual → ative o IPv4 → DNS preferencial 1.1.1.1, DNS alternativo 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 de 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 entre o seu navegador e a internet, e cada um pode recusar uma conexão. Os escudos que escaneiam HTTPS passam o seu tráfego por um serviço local; se esse serviço quebra, os sites HTTPS podem falhar em todos os navegadores de uma vez. E alguns sites rejeitam endereços de VPN de cara.

Teste um de cada vez: desconecte a VPN e recarregue. Depois pause a proteção web do antivírus por um minuto e recarregue. Por último, pause qualquer firewall de terceiros, muitas vezes parte de um pacote de antivírus. (O firewall do macOS só filtra conexões de entrada, e o Firewall do Windows Defender permite o tráfego de saída, a menos que alguém tenha adicionado uma regra. Se o Chrome mostra “O seu acesso à Internet está bloqueado”, a causa é um firewall do seu dispositivo.)

Se o site carregar com um deles desligado, ligue-o de volta e adicione uma exceção para o site, ou escolha outro servidor de VPN, em vez de deixar a proteção desligada.

Correção 8: teste as extensões no modo anônimo

As extensões raramente causam esse código: uma que bloqueia um site mostra ERR_BLOCKED_BY_CLIENT. Mas uma janela anônima (Ctrl+Shift+N, ou Cmd+Shift+N no Mac) é um teste de dez segundos que descarta ao mesmo tempo as extensões e os dados em cache, porque as extensões ficam desativadas ali, a menos que você as tenha permitido.

Se o site carregar na janela anônima, vá em chrome://extensions, desative todas e ative uma por vez até o erro voltar. Se ainda falhar na janela anônima, a causa está fora do Chrome.

Correção 9: verifique o seu arquivo hosts

O arquivo hosts sobrepõe o DNS para os nomes que ele contém. Se o site estiver mapeado lá para 127.0.0.1 ou para o IP de um servidor antigo, o navegador se conecta ali e é recusado. Entradas de desenvolvimento esquecidas e listas hosts de bloqueio de anúncios são os suspeitos de sempre, e o arquivo afeta todos os navegadores.

# 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.

Correção 10: no Android ou no iPhone

Os celulares recusam conexões pelos mesmos motivos, com chaves diferentes:

• Troque de rede: carregue o site nos dados móveis e depois no Wi-Fi. Se só uma das duas recusa, o problema é essa rede, não o celular.
• Desative apps de VPN, inclusive bloqueadores de anúncios e firewalls que funcionam como VPN (eles mostram uma chave ou um ícone de VPN na barra de status).
• Remova um proxy do Wi-Fi: no Android, abra as configurações da rede Wi-Fi → ícone de lápis (Modificar) → Opções avançadas → Proxy → Nenhum (o nome varia conforme o fabricante). No iPhone: Ajustes → Wi-Fi → ⓘ ao lado da rede → Configurar Proxy → “Off” (desativado).
• Limpe os dados do Chrome: Chrome → Configurações → Privacidade e segurança → Excluir dados de navegação → Imagens e arquivos em cache.
• Testando o seu próprio servidor? No celular, localhost é o próprio celular. Use o endereço IP local do seu computador (veja a próxima seção).

Localhost recusou a conexão (para desenvolvedores)

Ver localhost recusou a conexão ou ERR_CONNECTION_REFUSED em 127.0.0.1 significa que nada na sua máquina está aceitando conexões no endereço e na porta que você abriu. Os motivos de sempre:

• O servidor de desenvolvimento não está rodando — você nunca o iniciou, ou ele caiu. Confira o terminal onde npm run dev, rails s ou python manage.py runserver deveria estar rodando.
• Porta errada — o servidor iniciou em outra porta (3001 porque a 3000 estava ocupada, por exemplo). Copie o endereço da mensagem de inicialização dele.
• Sem porta no endereço — http://localhost vai para a porta 80, enquanto servidores de desenvolvimento usam a sua própria (3000, 5173, 8000, 8080).
• 127.0.0.1 ou [::1] — os navegadores tentam os dois endereços para localhost, mas um servidor pode escutar em só um deles. Abrir o outro endereço diretamente (http://127.0.0.1:3000 ou http://[::1]:3000), ou conectar de uma ferramenta que tenta só um, é recusado.
• Dentro do Docker — o app precisa escutar em 0.0.0.0 dentro do contêiner, e a porta precisa estar publicada (-p 3000:3000). Um app preso a 127.0.0.1 num contêiner não pode ser alcançado da sua máquina (você pode ver ERR_EMPTY_RESPONSE no lugar).
• De um celular ou emulador — ali, localhost é o próprio dispositivo. Use o IP de LAN do seu computador e inicie o servidor de desenvolvimento em todas as interfaces (Vite: --host), ou 10.0.2.2 no emulador do Android, o apelido dele para o localhost do seu computador.

# What is listening on port 3000?
# macOS / Linux:
lsof -nP -iTCP:3000 -sTCP:LISTEN

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

# No output = nothing is listening = connection refused.
# 127.0.0.1:3000 in the output = IPv4 only; [::1]:3000 = IPv6 only.

Se você precisa verificar se uma porta do seu servidor público está acessível pela internet (e não só pela própria máquina), use o Teste de portas do DNS Robot: ele testa a conexão de fora da sua rede, que é o que os seus visitantes realmente enfrentam.

“Conexão Recusada” dentro de uma página incorporada

Se “A conexão com example.com foi recusada.” aparece dentro de uma caixa em outra página (um formulário, relatório, mapa ou login incorporado), normalmente não é um problema de rede. O Chrome mostra a mesma frase quando o site incorporado proíbe ser exibido dentro de páginas de outros sites por um cabeçalho X-Frame-Options ou Content-Security-Policy: frame-ancestors. Internamente é ERR_BLOCKED_BY_RESPONSE, erro -27 (net_error_list.h).

Como visitante, abra o link incorporado na própria aba; ele carrega ali. Como dono do site, permita a página que incorpora você com Content-Security-Policy: frame-ancestors 'self' https://parent.example. O X-Frame-Options só pode dizer DENY ou SAMEORIGIN, e os navegadores atuais seguem o frame-ancestors quando uma página envia os dois. Veja o que o seu site envia com o Verificador de headers HTTP, e o nosso guia do X-Frame-Options traz os cabeçalhos exatos.

Para donos de sites: o seu site recusa conexões

Se visitantes relatam ERR_CONNECTION_REFUSED no seu site, os pacotes deles chegam a uma máquina no seu IP, mas nada ali aceita a conexão. Siga esta lista de verificação:

• O servidor web está rodando? Entre por SSH e confira systemctl status nginx (ou apache2, caddy). Um servidor que não subiu depois de uma reinicialização por causa de uma configuração quebrada, ou que foi morto quando a máquina ficou sem memória, não deixa nada escutando. Reinicie com sudo systemctl restart nginx.
• Está escutando nas portas e endereços certos? Rode ss -tlnp | grep -E ':(80|443) '. Um servidor que escuta só em 127.0.0.1 recusa todo mundo de fora; nada na 443 significa que nenhum bloco de servidor escuta ali (o HTTPS nunca foi configurado, ou o arquivo do site não está habilitado). O nginx -T imprime a configuração que está de fato carregada.
• Um firewall está rejeitando? Uma regra configurada para rejeitar (iptables REJECT, ufw reject) envia recusas. O deny padrão do ufw e firewalls de nuvem como os grupos de segurança da AWS descartam pacotes em silêncio, o que os visitantes veem como ERR_CONNECTION_TIMED_OUT.
• O fail2ban baniu alguém? O banimento padrão dele rejeita o endereço banido, então esse visitante (ou você, depois de algumas falhas de login por SSH) recebe ERR_CONNECTION_REFUSED enquanto todos os outros entram. Confira sudo fail2ban-client status.
• O IP do seu servidor mudou? Compare o seu registro A com o IP real do servidor usando a Consulta DNS. Depois de uma migração, um registro A antigo manda os visitantes para a máquina anterior.
• Atrás da Cloudflare? Em registros com proxy ativado (nuvem laranja), os visitantes se conectam à Cloudflare, não a você, então não verão esse código. Quando a sua origem recusa as conexões da Cloudflare, a Cloudflare mostra o próprio Error 521: Web server is down.
• Teste de fora: o Teste de portas nas portas 80 e 443, e o Verificador de headers HTTP para uma requisição real 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 -w 5 example.com 443
# "succeeded" = port open, "refused" = still rejected

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

# Then confirm the address your computer actually uses:
ping -c 1 example.com          # Mac/Linux
Resolve-DnsName example.com    # Windows PowerShell

Ou pule o terminal: passe o domínio e a porta pelo Teste de portas do DNS Robot para uma resposta de aberta/fechada de fora da sua rede. Se a porta está aberta de fora mas o navegador ainda mostra ERR_CONNECTION_REFUSED, o bloqueio está no seu dispositivo ou na sua rede: volte às correções de VPN, software de segurança e arquivo hosts.