O Squid não consegue ligar o seu listener: verifique primeiro o endereço

Um erro de ligação ocorre no host do proxy antes de o cliente poder usar o listener pretendido. Alterar os URL do site ou as palavras-passe do proxy não tornará disponível um endereço local inexistente.

Leia o ponto final falhado por completo: endereço, porta e família de endereços. Uma mensagem com [::1] diz respeito a IPv6 loopback. Não é o mesmo que não conseguir ligar-se para fora a um site IPv6.

Pergunte qual espaço de nomes de rede o detém

Para um proxy em contentor, examine os endereços disponíveis no ambiente de rede do contentor. O suporte a IPv6 e a configuração de endereços aí podem diferir do host. Publicar uma porta de contentor não cria automaticamente todos os endereços que um serviço tenta ligar.

A referência do listener do Squid explica que um endereço explícito liga um ponto final local específico. Um nome de host pode introduzir outra fonte de confusão se resolver para um endereço ausente desse ambiente.

Outros erros de ligação têm causas diferentes. Uma porta ocupada sugere outro listener ou instância. Permissão negada pode envolver uma porta privilegiada ou a política de segurança do host. Um endereço indisponível aponta para a configuração de endereços. Mantenha essas observações separadas em vez de tratar cada falha de ligação como uma rejeição da firewall.

Se a implementação for deliberadamente apenas IPv4, escolha um listener IPv4 explícito adequado à política de acesso pretendida. Se IPv6 for necessário, configure esse ambiente para o suportar. Ligar publicamente a um endereço wildcard só para silenciar um erro pode expor o proxy mais amplamente do que o pretendido.

Por fim, verifique se o socket falhado é o listener HTTP voltado para o cliente ou outro componente do Squid. Um aviso não prova que todos os listeners falharam, mas um socket não relacionado a funcionar não prova que o ponto final de que os clientes precisam esteja disponível.