ERR_CONNECTION_REFUSED: o que significa e como corrigir

O que significa ERR_CONNECTION_REFUSED

Uma conexão TCP começa com um handshake: o cliente envia um pacote SYN, e o servidor responde com SYN-ACK se algum processo estiver associado àquela porta. A RFC 9293, a especificação do TCP, trata do outro caso: um segmento que não pertence a nenhuma conexão recebe um reset como resposta, e “a SYN segment that does not match an existing connection is rejected by this means” (um segmento SYN que não corresponde a uma conexão existente é rejeitado dessa forma). Esse RST é o que o Chrome mostra como ERR_CONNECTION_REFUSED. A mesma RFC cita a mensagem ICMP Port Unreachable como a outra forma rápida de uma tentativa de conexão falhar; alguns firewalls rejeitam com ela em vez de um RST, e clientes Linux também a reportam como recusa.

O RST vem da pilha TCP do kernel, não do código da aplicação, então chega em milissegundos. Ele também mostra que algo naquele endereço IP está no ar e respondendo: o próprio host, sem nada associado à porta, ou um firewall na frente dele que rejeita a porta. Olhe a porta e o processo por trás dela antes de olhar a energia ou o link de rede do servidor.

Como o erro aparece

O Chrome mostra “This site can't be reached”, depois “example.com refused to connect” (example.com recusou a conexão) e o código ERR_CONNECTION_REFUSED. O Firefox mostra “Unable to connect” e diz que não consegue estabelecer conexão com o servidor naquele endereço. A linha de comando dá um retrato mais exato:

curl -v https://example.com:8443/
* Trying 203.0.113.10:8443...
* connect to 203.0.113.10 port 8443 failed: Connection refused
* Failed to connect to example.com port 8443 after 2 ms: Connection refused
curl: (7) Failed to connect to example.com port 8443 after 2 ms: Connection refused

A saída traz o endereço IP e a porta exatos que o curl tentou e reporta a recusa após 2 ms, rápido demais para ser um timeout. O código de saída 7 significa que o curl obteve um endereço mas não conseguiu se conectar a ele. nc -zv example.com 8443 imprime o mesmo “Connection refused”, e no Windows Test-NetConnection example.com -Port 8443 no PowerShell mostra TcpTestSucceeded : False.

ERR_CONNECTION_REFUSED e erros parecidos

O Chrome mostra todos estes sob o mesmo título “This site can't be reached”, então o código embaixo é o que os diferencia. As linhas seguem a ordem em que o carregamento de uma página os encontra, da consulta DNS ao primeiro byte da resposta. Os números são os códigos de erro internos do Chromium.

Erro	O que aconteceu no nível da rede ou do protocolo	Onde olhar primeiro
ERR_NAME_NOT_RESOLVED (-105)	A consulta DNS não devolveu nenhum endereço IP utilizável, então nenhuma conexão foi tentada.	Os registros DNS do domínio e o resolvedor que o dispositivo usa.
ERR_ADDRESS_UNREACHABLE (-109)	O sistema operacional ou um roteador informou que não há rota até o endereço IP.	O roteamento do lado do cliente: rotas de VPN, a rede local, a configuração de IPv6.
ERR_CONNECTION_TIMED_OUT (-118)	O SYN saiu e nada voltou, nem SYN-ACK nem RST, até o cliente desistir.	Firewalls e security groups que descartam pacotes, se o host está no ar e o endereço IP que o DNS devolve.
ERR_CONNECTION_REFUSED (-102)	O SYN chegou ao host e foi rejeitado na hora, em geral com um RST.	Se há um processo escutando naquela porta e naquele endereço, e regras REJECT do firewall.
ERR_CONNECTION_RESET (-101)	A conexão estava aberta e depois um RST a encerrou durante o handshake TLS ou a transferência.	Os logs do proxy, do WAF e da aplicação naquele momento; antivírus, VPN ou filtragem na rede do cliente.
ERR_EMPTY_RESPONSE (-324)	A conexão foi aberta e a requisição saiu, mas o servidor fechou a conexão sem enviar nenhum dado.	Os logs de erro do servidor e do proxy: workers que travaram ou conexões fechadas de propósito (o return 444 do nginx).

O que causa o ERR_CONNECTION_REFUSED

• Nada está escutando naquela porta. O servidor web, a aplicação ou o proxy que deveria ser dono da porta não está rodando, ou está configurado para outra porta.
• O serviço caiu ou está reiniciando. Um processo que encerrou, foi morto por usar memória demais ou está reiniciando durante um deploy deixa a porta livre, às vezes por apenas alguns segundos.
• O serviço escuta no endereço errado. Um servidor associado a 127.0.0.1 aceita conexões da própria máquina e recusa tudo que chega pelo endereço público.
• Uma regra de firewall rejeita a porta. Uma regra REJECT responde com um RST ou um erro ICMP, o que, visto de fora, é igual a uma porta fechada. Uma regra DROP produz um timeout.
• A URL usa a porta ou o esquema errado. Um erro de digitação, um favorito antigo de antes de uma mudança de porta, ou um endereço https:// num servidor que só escuta na porta 80.
• Um servidor de desenvolvimento local não está rodando. localhost:3000 recusado quase sempre significa que o servidor de desenvolvimento foi parado, caiu ao iniciar ou nunca foi iniciado nesta sessão.
• Um proxy ou uma VPN está mal configurado. Um proxy apontado para um backend que está fora do ar, ou um cliente de VPN que envia requisições para uma porta que ninguém atende, recusa a conexão por conta própria.
• Um container ou um Service do Kubernetes aponta para a porta errada. A porta publicada ou de destino difere da porta em que a aplicação escuta, então o processo roda e continua saudável enquanto toda conexão a ele é recusada.

Causas no servidor e configuração

Comece no servidor com ss -ltnp. Ele lista cada socket TCP em escuta com endereço, porta e processo dono, o que mostra em qual dos casos abaixo você está:

sudo ss -ltnp
State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     127.0.0.1:3000      0.0.0.0:*          users:(("node",pid=812,fd=19))
LISTEN  0       511     0.0.0.0:80          0.0.0.0:*          users:(("nginx",pid=640,fd=6))

Aqui o nginx aceita conexões na porta 80 em todos os endereços IPv4, enquanto a aplicação na porta 3000 as aceita apenas da própria máquina. Uma porta que não aparece na lista não tem nenhum listener.

Diretivas listen do nginx e do Apache

No nginx, listen 443 ssl; aceita conexões IPv4 em todos os endereços, e o IPv6 precisa de uma linha própria. Se o domínio tem um registro AAAA e o servidor só escuta em IPv4, as conexões IPv6 são recusadas enquanto as IPv4 funcionam. Um site que carrega por http:// mas é recusado por https:// geralmente não tem nenhum listener na 443:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;
}

Aplique as mudanças com sudo nginx -t && sudo systemctl reload nginx. No Apache, cada porta precisa de uma linha Listen (por exemplo Listen 443 em ports.conf ou httpd.conf) além do bloco <VirtualHost *:443>; um virtual host sem um Listen correspondente nunca ganha um socket. Confira com sudo apachectl configtest antes de reiniciar.

Node.js e servidores de desenvolvimento

O argumento de host decide quem pode se conectar. Omiti-lo faz o Node.js escutar no endereço IPv6 não especificado :: quando o IPv6 está disponível, ou em 0.0.0.0 caso contrário:

// Only connections from the same machine
server.listen(3000, '127.0.0.1');

// Connections on every IPv4 address
server.listen(3000, '0.0.0.0');

Muitos servidores de desenvolvimento escutam só em localhost por padrão, entre eles o flask run do Flask e o Vite. Um celular ou outro computador na mesma rede Wi-Fi é recusado até você iniciá-los com flask run --host=0.0.0.0 ou vite --host.

Publicação de portas no Docker

-p host:container mapeia uma porta do host para uma porta do container. A metade do container deve ser a porta em que a aplicação escuta dentro do container, e a aplicação deve escutar em 0.0.0.0 ali, não em 127.0.0.1:

# Host port 8080 on all host addresses -> container port 80
docker run -d --name web -p 8080:80 nginx

# Published on the host's loopback only: other machines are refused
docker run -d --name web-local -p 127.0.0.1:8080:80 nginx

# Show the ports a running container publishes
docker port web

No Compose o mesmo mapeamento é ports: ["8080:80"]. Quando a metade do container ou o endereço de bind lá dentro está errado, clientes externos costumam ser recusados, enquanto o curl no próprio host do Docker muitas vezes reporta Connection reset by peer ou Empty reply from server, porque o proxy do Docker aceita a conexão local antes de falhar ao alcançar o container.

Services do Kubernetes

O port de um Service é onde os clientes se conectam; o targetPort deve ser a porta em que o processo no pod escuta. O campo containerPort do pod é sobretudo informativo, a menos que o targetPort o referencie por nome:

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

Se nenhum pod por trás do Service está pronto (o seletor não casa com nada, ou todos os pods falham na readiness probe), o kube-proxy em seu modo iptables padrão rejeita as conexões ao Service, e os clientes veem uma recusa. Atrás de um ingress controller, a mesma situação costuma virar um 503. kubectl get endpointslices -l kubernetes.io/service-name=web mostra se existem endpoints prontos, e kubectl describe pod -l app=web mostra probes falhando.

Firewalls

Firewalls de host podem recusar ou descartar, e a diferença decide qual erro os visitantes recebem. No ufw, deny descarta os pacotes (o cliente dá timeout) enquanto reject responde na hora (o cliente é recusado):

sudo ufw status verbose
sudo ufw allow 443/tcp

# iptables: rules with packet counters; watch REJECT lines while you retry
sudo iptables -L INPUT -n -v --line-numbers

# nftables
sudo nft list ruleset | grep -n reject

Uma regra REJECT cujo contador de pacotes sobe a cada nova tentativa é a regra que está recusando você.

Proxies reversos e PHP-FPM

Quando a recusa acontece entre um proxy reverso e o backend dele, o visitante nunca vê ERR_CONNECTION_REFUSED. O nginx registra a recusa no log e responde ao navegador com um 502 Bad Gateway:

2026/10/13 09:14:02 [error] 640#640: *1532 connect() failed (111: Connection refused) while connecting to upstream, client: 198.51.100.7, server: example.com, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "example.com"

Com PHP, a mesma linha costuma significar fastcgi_pass 127.0.0.1:9000; no nginx enquanto o pool do PHP-FPM escuta num socket Unix (listen = /run/php/php8.3-fpm.sock), ou que o PHP-FPM não está rodando. Faça os dois lados apontarem para o mesmo endereço.

Como aparece visto de fora

Verificações feitas de vários locais ao mesmo tempo costumam cair em um destes padrões:

• Recusada de todos os locais, na hora. O serviço está fora do ar, associado ao endereço errado, ou uma regra REJECT no servidor vale para todo mundo. Comece com ss -ltnp.
• Recusada de alguns locais, aceita em outros. Os pontos de verificação chegaram a máquinas diferentes ou encontraram regras diferentes: um dos vários registros A aponta para um servidor sem o serviço, uma regra de firewall rejeita certas faixas de origem, ou uma lista de bloqueio como o fail2ban rejeita esses endereços.
• Aceita em todo lugar, menos na sua rede. A recusa é local: um proxy ou uma VPN no seu dispositivo, um firewall corporativo que rejeita aquela porta, ou uma regra do roteador.
• Porta 80 aceita, porta 443 recusada. O servidor não tem listener HTTPS, e todo link https:// ou upgrade por HSTS bate na porta fechada.
• Algumas verificações recusadas, outras com timeout. Há mais de um endereço IP ou regra envolvidos; compare o endereço IP a que cada ponto de verificação se conectou.

O verificador de portas abre uma conexão TCP com o host e a porta que você informar a partir de vários locais e reporta, para cada um, se a conexão foi aceita, recusada ou deu timeout.

Como corrigir o ERR_CONNECTION_REFUSED

Se você é o visitante

1. Confirme a URL e a porta. Procure um erro de digitação, um favorito antigo ou um link que ainda aponta para uma porta que o site não usa mais.
2. Procure um proxy. No Windows, abra Configurações > Rede e Internet > Proxy. No macOS, execute scutil --proxy ou abra as configurações de proxy da sua conexão de rede. No Chrome, chrome://net-internals/#proxy mostra o proxy que o navegador está usando.
3. Desligue a VPN e recarregue. Se o site carregar depois disso, a configuração da VPN é a causa.
4. Tente outra rede, como dados móveis em vez de Wi-Fi, para descartar uma regra de firewall local ou do roteador.
5. Espere um minuto e tente de novo. Se o dono do site está no meio de um deploy ou reiniciando um serviço, a porta pode ficar livre por apenas alguns segundos.

Se o endereço recusado é localhost

1. Veja se algo escuta na porta. No macOS ou Linux, execute lsof -nP -iTCP:3000 -sTCP:LISTEN; no Windows, execute netstat -ano | findstr :3000, ou Get-NetTCPConnection -LocalPort 3000 -State Listen no PowerShell.
2. Inicie o servidor e leia as primeiras linhas da saída. Um servidor de desenvolvimento que cai ao iniciar (um erro de sintaxe, uma variável de ambiente ausente, uma porta já em uso) imprime o motivo ali e depois encerra.
3. Case a família de endereços. Se o erro cita ::1, o cliente tentou o loopback IPv6 enquanto o servidor escuta só em 127.0.0.1. Use http://127.0.0.1:3000 no cliente, ou faça o servidor escutar nos dois (no Node.js, omitir o argumento de host costuma fazer isso).

Se você administra o site

1. Confirme que o processo está rodando e associado à porta esperada:

   sudo ss -ltnp | grep ':443'

   Um resultado vazio significa que nada está escutando; inicie o serviço ou corrija a porta configurada.
2. Confira o status e os logs do serviço:

   systemctl status nginx
   journalctl -u nginx -n 50 --no-pager

   Uma unit que caiu ou falhou aparece aqui, em geral com o motivo de ter encerrado.
3. Confira o endereço de bind. 127.0.0.1:443 na saída do ss significa que clientes externos são recusados; escute em 0.0.0.0 e [::] ou no endereço público.
4. Confira regras REJECT e mapeamentos de porta com os comandos de firewall, Docker e Kubernetes acima.
5. Reinicie e teste de fora. Confirme que a porta aparece em ss -ltnp e que uma conexão a partir de outra rede funciona.

Como evitar o ERR_CONNECTION_REFUSED

Um processo que não está rodando não consegue relatar a própria falha, então um serviço que caiu ou uma regra REJECT perdida costuma aparecer primeiro como conexões recusadas nos navegadores dos visitantes. O monitoramento de portas conecta à porta de fora da rede, em intervalos regulares, do mesmo jeito que um visitante faria, e envia um alerta por e-mail, SMS, chamada de voz, Slack, Telegram e outros canais quando uma verificação falha. Com verificações a partir de mais de 300 pontos em 158 cidades, uma recusa que afeta só uma região ou um dos vários servidores também aparece.

Perguntas frequentes

ERR_CONNECTION_REFUSED é o mesmo que um firewall me bloqueando?

Pode ser. Uma regra REJECT de firewall produz a mesma rejeição rápida de uma porta fechada, então o navegador não consegue distinguir as duas. Uma regra DROP produz um timeout.

Por que isso acontece só no localhost?

Quase sempre porque o servidor de desenvolvimento local não está rodando naquele terminal, foi parado ou caiu ao iniciar por causa de um erro de código ou de configuração. Procure uma mensagem de erro no terminal onde você costuma iniciá-lo e depois veja qual processo é dono da porta com lsof ou netstat.

Por que recebo “connect ECONNREFUSED ::1”?

Desde o Node.js 17, as consultas DNS devolvem os endereços na ordem em que o sistema os fornece, e em muitos sistemas localhost resolve primeiro para o endereço IPv6 ::1. Um cliente que tenta ::1 enquanto o servidor escuta só em 127.0.0.1 é recusado. Aponte o cliente para 127.0.0.1 ou faça o servidor escutar também em ::.

Uma VPN pode causar ERR_CONNECTION_REFUSED?

Sim. Uma VPN que roteia o tráfego por um proxy ou gateway pode recusar conexões em nome do gateway se o backend dele estiver fora do ar, mesmo com o servidor de destino saudável.

ERR_CONNECTION_REFUSED significa que o site está fora do ar para todo mundo?

Não necessariamente. Teste de uma segunda rede ou faça uma verificação a partir de vários locais antes de concluir isso. Uma única regra de firewall mal configurada ou uma VPN local pode produzir o mesmo erro enquanto o site funciona para todos os outros.

Por que o curl via http:// funciona enquanto o navegador mostra recusado?

O navegador pode estar se conectando à porta 443. Se o site já enviou um cabeçalho HSTS, o Chrome reescreve http:// para https:// antes de conectar, então um servidor sem listener HTTPS é recusado mesmo com a porta 80 respondendo. chrome://net-internals/#hsts mostra se um domínio tem uma entrada HSTS.

Um servidor sobrecarregado pode recusar conexões?

No Linux, em geral não. Quando a fila de um socket em escuta está cheia, o kernel descarta por padrão as novas tentativas de conexão em vez de resetá-las (a configuração tcp_abort_on_overflow vem desligada), então um servidor sobrecarregado tende a produzir conexões lentas e timeouts, não recusas.

Qual a diferença entre recusada e resetada?

Recusada significa que o destino rejeitou o handshake, então nenhuma conexão chegou a existir. Resetada significa que uma conexão foi estabelecida e depois derrubada no meio, pelo servidor, por um proxy ou por outra coisa no caminho.

Como descubro qual processo deveria estar escutando?

A configuração da aplicação e o log de inicialização dela indicam a porta em que ela escuta. Se for diferente da porta da URL, mude uma das duas para que coincidam e depois confirme com ss -ltnp.

Fontes e leitura adicional

• Chromium net error list: as definições de CONNECTION_REFUSED (-102) e dos outros códigos da tabela acima.
• RFC 9293, Transmission Control Protocol: a seção 3.5.2 sobre quando o TCP envia um reset, e a seção 3.8.3 sobre como uma tentativa de conexão falha.
• Docker: port publishing and mapping: a sintaxe do -p e a publicação apenas em localhost.
• Kubernetes: Service: como port e targetPort encaminham o tráfego aos pods.