ERR_CONNECTION_REFUSED

O que este erro significa e como reconhecê-lo

• O Chrome, o Edge ou outro navegador baseado em Chromium exibe “Este site não pode ser acessado — ERR_CONNECTION_REFUSED.”
• O erro aparece rapidamente, em vez de ocorrer após uma longa espera. Um atraso prolongado é mais compatível com um timeout, como ERR_CONNECTION_TIMED_OUT.
• Um site que funcionava anteriormente falha após uma reinicialização do servidor, um deployment, uma alteração de DNS, uma atualização de configuração ou uma mudança no firewall.
• O SSH ou outra porta de aplicação na mesma máquina pode continuar acessível enquanto a porta web recusa conexões.
• As solicitações feitas no servidor podem funcionar enquanto as solicitações externas falham quando o serviço escuta apenas no localhost ou um firewall externo bloqueia a porta.

Causas principais, por probabilidade

1. O servidor web ou o processo da aplicação está parado — o Nginx, o Apache ou o servidor da aplicação pode ter travado, sido parado ou falhado durante a inicialização.
2. Nada está escutando na porta solicitada — o serviço pode usar uma porta diferente, enquanto a solicitação é direcionada para 80 ou 443.
3. O serviço está vinculado à interface errada — um listener em 127.0.0.1 aceita solicitações locais, mas não conexões externas diretas.
4. Um firewall do host ou da nuvem recusa o tráfego — um firewall do sistema operacional, security group, network ACL ou firewall do provedor pode ter sido alterado.
5. O DNS aponta para o destino errado — o domínio pode resolver para um servidor antigo, reconstruído ou que não esteja configurado. Um registro AAAA também pode direcionar alguns visitantes para um endereço IPv6 sem um listener web funcionando.

Como corrigir

1. Confirme o endereço de destino

Verifique os registros A e AAAA do domínio e compare os endereços resolvidos com o servidor que deveria receber a solicitação. Se o domínio apontar para um servidor antigo, desativado ou recém-reconstruído, corrija o DNS antes de alterar a configuração do serviço web. Se existirem registros IPv4 e IPv6, verifique se o serviço e o firewall são compatíveis com ambos os caminhos.

2. Verifique se o serviço está em execução

Usando um método de administração autorizado, como SSH, verifique o serviço relevante. Por exemplo, inspecione o Nginx com systemctl status nginx; use o nome de serviço equivalente para o Apache ou para o servidor da aplicação.

Se o serviço estiver parado ou com falha, examine o status e os logs antes de iniciá-lo. Um erro de configuração introduzido por uma alteração recente é uma causa comum de falha na inicialização. Valide a configuração com nginx -t para o Nginx ou apachectl configtest para o Apache. Só depois que o teste for aprovado e você estiver autorizado a alterar o serviço reinicie ou recarregue-o. Uma reinicialização pode interromper solicitações ativas e talvez não seja apropriada durante um pico de produção.

3. Verifique a porta e a interface em escuta

No servidor, inspecione os listeners com ss -tlnp ou o equivalente da plataforma. Confirme se o processo esperado está escutando na porta solicitada, geralmente :80 ou :443.

Verifique o endereço de vinculação, além da porta:

• 0.0.0.0:80 ou 0.0.0.0:443 geralmente escuta nas interfaces IPv4 disponíveis.
• Um endereço específico do servidor indica que o serviço está vinculado a essa interface.
• 127.0.0.1:80 ou 127.0.0.1:443 aceita apenas solicitações locais.

Se a aplicação for intencionalmente privada no localhost, confirme se o reverse proxy voltado para o público está em execução e encaminhando as solicitações para ela. Caso contrário, ajuste a configuração do serviço para escutar na interface pretendida durante uma alteração aprovada de manutenção ou deployment.

4. Verifique as regras de firewall do host e da nuvem

Revise o firewall do servidor com ufw status, iptables -L ou o comando equivalente do sistema operacional. Em seguida, inspecione o security group da nuvem, a network ACL ou o firewall do provedor associado ao servidor esperado.

Confirme se o tráfego de entrada é permitido na porta necessária a partir das fontes apropriadas. Um site público pode precisar de acesso à internet, enquanto um serviço interno deve usar um intervalo aprovado mais restrito. Verifique as regras IPv4 e IPv6 separadamente quando ambos os tipos de registro forem publicados. Não amplie o acesso mais do que o necessário e faça alterações no firewall somente com autorização.

5. Teste local e externamente

A partir do servidor, teste o listener local e o hostname configurado separadamente. O sucesso local confirma apenas que algo responde na máquina; ele não prova que clientes externos conseguem alcançar a porta.

Depois de corrigir o DNS, o serviço, a vinculação ou o firewall, execute uma solicitação detalhada com curl -v para o hostname afetado a partir de uma rede diferente ou de uma máquina externa. Confirme se a solicitação alcança o endereço e a porta esperados e se a recusa foi eliminada.

6. Compare as alterações recentes

Se a falha começou após um deployment, uma reinicialização, a reconstrução do servidor, uma atualização de DNS ou uma alteração no firewall, compare a configuração atual com a última versão conhecida por funcionar. Procure especificamente uma porta alterada, uma falha na inicialização do serviço, uma vinculação apenas ao localhost, uma regra associada ao servidor errado ou uma configuração IPv6 incompleta.

Prevenção e como verificar a correção

• Use um gerenciador de serviços ou supervisor de processos para que o serviço web possa se recuperar de uma falha inesperada.
• Torne a validação da configuração, como nginx -t ou apachectl configtest, uma verificação obrigatória do deployment antes de um reload ou restart.
• Documente as portas, os endereços de vinculação, as regras de firewall, os security groups e os registros DNS pretendidos como uma baseline conhecida por funcionar.
• Monitore o serviço de fora do servidor, em vez de depender apenas de verificações de integridade locais.
• Revise os listeners e as regras de firewall IPv4 e IPv6 sempre que um domínio tiver registros A e AAAA.
• Registre as alterações de infraestrutura para que uma nova recusa possa ser relacionada a um deployment, uma reconstrução, uma atualização de DNS ou uma alteração no firewall.

Perguntas frequentes