Quando o Squid não consegue resolver um nome de host

Examine o DNS onde a consulta falha. Seu notebook resolver um nome não comprova que o Squid, ou um proxy pai que faz a conexão seguinte, consiga resolvê-lo.

Leia o log de cache da instância com falha e confira as configurações do resolvedor do servidor. Uma verificação complementar no nível do host é:

getent ahosts target.example

Use o destino real. getent utiliza o mecanismo de resolução do host; o resolvedor interno ou o cache do Squid pode ser diferente. Examine as entradas explícitas de dns_nameservers e hosts_file antes de supor que coincidem.

No Squid 6.13, uma lista explícita de servidores de nomes contém endereços IP:

dns_nameservers 192.0.2.53

Substitua esse endereço de documentação por um resolvedor aprovado e acessível a partir do servidor Squid. Nomes privados podem exigir o resolvedor da organização; um resolvedor público sem relação com ela pode não enxergá-los em sua visão DNS.

Um alias do arquivo hosts do notebook não acompanha uma solicitação por nome de host enviada pelo proxy. Na máquina que faz a consulta, revise a configuração hosts_file da versão instalada do Squid e considere o resolvedor de um pai, quando aplicável. Mantenha o nome de host usado para a identidade TLS compatível com o serviço.

Após uma única alteração controlada de configuração, verifique a sintaxe e recarregue a instância pretendida, repita a mesma solicitação e examine as evidências correspondentes. Respostas positivas e negativas em cache podem afetar testes repetidos. Uma consulta bem-sucedida seguida de timeout de conexão é uma falha posterior de rota ou permissão; não continue alterando o DNS para corrigi-la. Mantenha constantes o DNS do cliente, o roteamento do pai e o protocolo proxy enquanto avalia a alteração do servidor.