Cando Squid non pode resolver un nome de host

Examina o DNS onde se produce a consulta que falla. Que o portátil resolva un nome non demostra que Squid, ou un proxy pai que establece a conexión posterior, poida resolvelo.

Le o rexistro de caché da instancia que falla e revisa a configuración do resolvedor do servidor. Unha comprobación complementaria no nivel do host é:

getent ahosts target.example

Usa o destino real. getent utiliza o mecanismo de consulta do host; o resolvedor interno ou a caché de Squid poden ser diferentes. Examina as entradas explícitas de dns_nameservers e hosts_file antes de supoñer que coinciden.

En Squid 6.13, unha lista explícita de servidores de nomes contén enderezos IP:

dns_nameservers 192.0.2.53

Substitúe este enderezo de documentación por un resolvedor aprobado e accesible desde o servidor Squid. Os nomes privados poden requirir o resolvedor da organización; un resolvedor público alleo pode non velos na súa vista DNS.

Un alias do ficheiro hosts do portátil non viaxa cunha petición por nome de host enviada mediante o proxy. Na máquina que fai a consulta, revisa a opción hosts_file da versión de Squid instalada e ten en conta o resolvedor dun pai cando corresponda. Mantén o nome de host usado para a identidade TLS acorde co servizo.

Tras un único cambio controlado de configuración, comproba a sintaxe e recarga a instancia prevista, repite a mesma petición e examina as probas correspondentes. As respostas positivas e negativas na caché poden afectar as probas repetidas. Unha consulta correcta seguida dun tempo de conexión esgotado é un fallo posterior de ruta ou permisos; non sigas cambiando o DNS para arranxalo. Mantén constantes o DNS do cliente, o encamiñamento do pai e o protocolo proxy mentres avalías o cambio do servidor.