ERR_CONNECTION_REFUSED: o servidor recusa a conexão

O que o erro significa

O navegador encontrou o endereço do servidor, pediu uma conexão na porta 443 (ou 80) e o servidor respondeu “não”: um pacote TCP de reset, o que sai quando nenhum programa está escutando naquela porta. O Chrome mostra ERR_CONNECTION_REFUSED abaixo de “Não é possível acessar esse site”; o Firefox diz “Não foi possível conectar”; o Safari, “O Safari não pode se conectar ao servidor”. Em Portugal, a mesma tela do Chrome diz “Não é possível aceder a este site”.

Não é um ERR_CONNECTION_TIMED_OUT (nenhuma resposta: um firewall que descarta os pacotes ou uma máquina desligada) nem um DNS_PROBE_FINISHED_NXDOMAIN (o nome não é resolvido). Conexão recusada quer dizer: a máquina está ligada, mas o servidor web está parado, escuta em outra porta ou em outro endereço, ou um firewall rejeita em vez de ignorar.

Causas frequentes

1. O servidor web está parado. O nginx ou o Apache travou, não voltou depois de uma mudança na configuração ou foi parado por uma atualização. É o caso mais comum.
2. Endereço ou porta errados. Depois de uma mudança nas linhas listen, o nginx escuta só em 127.0.0.1 ou só em IPv4, enquanto o DNS também aponta para um endereço IPv6.
3. Um firewall rejeita a porta. ufw, firewalld ou um grupo de segurança na nuvem com uma regra reject para as portas 80 e 443, muitas vezes depois de alguém “endurecer” o servidor.
4. Servidor novo sem servidor web. O DNS já aponta para o IP novo, mas lá o nginx ainda não foi instalado ou iniciado.
5. HTTPS não configurado. A porta 80 responde, na 443 ninguém escuta, e o navegador (ou uma entrada HSTS) exige HTTPS.
6. Causas locais do visitante. Um proxy morto, uma VPN, a “proteção web” de um antivírus, uma linha no arquivo hosts, uma extensão do navegador.

Se você é visitante

1. Abra o site em uma janela anônima e em outro navegador, para descartar extensões e cache.
2. Confira as configurações de proxy: no Windows em “Configurações de proxy”, no macOS em Rede > Avançado > Proxies. Desative um proxy manual que você não usa.
3. Desligue por um momento a VPN e a proteção web do antivírus.
4. Limpe o cache DNS (ipconfig /flushdns no Windows, sudo dscacheutil -flushcache no macOS, sudo resolvectl flush-caches no Linux): ele pode guardar o endereço antigo de um site que mudou de servidor.
5. Tente http:// no lugar de https:// uma vez; se assim abrir, o HTTPS do site está quebrado e só o dono resolve.

Se o site é seu: verifique primeiro

Abra o website down checker. “Conexão recusada” vindo de fora confirma que é o servidor que recusa. Depois entre por SSH; o simples fato de o SSH responder enquanto o site recusa já é uma pista: a máquina funciona, o servidor web não.

# o servidor web está rodando?
systemctl status nginx
systemctl status apache2

# o que escuta nas portas 80 e 443?
sudo ss -tlnp | grep -E ':80 |:443 '

# regras do firewall
sudo ufw status verbose
sudo firewall-cmd --list-all
sudo nft list ruleset | grep -E 'dport (80|443)'

Se o ss não mostrar nada na 443, o servidor web está parado ou não usa essa porta. Se mostrar 127.0.0.1:443 em vez de 0.0.0.0:443 ou *:443, ele escuta só localmente.

Soluções no seu servidor

1. Iniciar o servidor web e ler por que ele parou

sudo systemctl start nginx
systemctl status nginx
sudo journalctl -u nginx -n 50

Se ele não subir, quase sempre é um destes casos:

• bind() to 0.0.0.0:80 failed (98: Address already in use): outro programa ocupa a porta (Apache e nginx instalados juntos, ou um processo antigo). sudo ss -tlnp | grep ':80 ' diz qual; pare o que você não quer.
• [emerg] unknown directive ou unexpected "}": erro de sintaxe. sudo nginx -t aponta arquivo e linha.
• cannot load certificate: um certificado excluído ou renovado em outro caminho. Compare as linhas ssl_certificate com o disco.
• Too many open files ou disco cheio: df -h, df -i.

Apache: sudo apachectl configtest, depois sudo journalctl -u apache2 -n 50. Valem as mesmas categorias; AH00558 (could not determine server name) é só um aviso, não a causa.

Teste sempre antes de recarregar, e recarregue em vez de reiniciar sempre que possível:

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

2. Escutar no endereço certo

O bloco server do nginx precisa escutar em IPv4 e em IPv6:

listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;

Se o DNS tem um registro AAAA, mas o servidor não escuta em IPv6 (ou não tem conectividade IPv6), os visitantes com IPv6 são recusados e os outros entram. Escute em IPv6 ou remova o AAAA.

3. Abrir o firewall

# ufw (Debian/Ubuntu)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# firewalld (família RHEL)
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload

Em um servidor na nuvem, confira também o grupo de segurança ou o firewall de rede no painel do provedor: uma regra lá é invisível de dentro do servidor.

4. Configurar o HTTPS se só a porta 80 responde

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

O certbot cria o bloco 443 e o redirecionamento. Depois confira com o SSL checker se a cadeia está completa.

5. Depois de uma mudança de servidor

Instale, configure e inicie o servidor web na máquina nova antes de trocar o DNS. Se já trocou: instale e inicie o servidor web agora, ou aponte o registro de volta para o servidor antigo até o novo estar pronto.

Se o problema está na sua hospedagem

Em uma hospedagem compartilhada, conexão recusada quer dizer: o servidor web da hospedagem caiu, ou ela moveu seu site para um IP novo sem atualizar o DNS. Envie esta mensagem:

Prezados, meu site example.com está respondendo “conexão recusada” nas portas 80 e 443 desde aproximadamente 20h15 (UTC). O domínio resolve para 203.0.113.10. Não alterei nada do meu lado. O servidor web dessa máquina está parado ou meu site foi movido para outro endereço?

Para não acontecer de novo

Uma conexão recusada é quase sempre um servidor web parado, exatamente o que uma verificação de porta e uma verificação do site vindas de fora percebem em um minuto. No seu servidor, o agente de servidor avisa quando o nginx ou o Apache para, antes que um visitante perceba.

Fora do ar? Nós resolvemos. No seu servidor ou em uma hospedagem compartilhada com acesso SSH, o Quick Fix, o reparo automático a preço fixo, reinicia o servidor web se o teste da configuração passar, 24 horas por dia, inclusive nos fins de semana, sem ninguém precisar entrar no servidor às 3 da manhã. Configuração quebrada? O Deep Fix conserta, em blocos de 15 minutos; a estimativa é o valor máximo.