Cuando Squid no puede resolver un nombre de host

Examina el DNS donde se produce la consulta fallida. Que tu portátil resuelva un nombre no demuestra que Squid, o un proxy padre que establece la conexión posterior, pueda resolverlo.

Consulta el registro de caché de la instancia que falla y la configuración del resolvedor del servidor. Una comprobación complementaria a nivel de host es:

getent ahosts target.example

Usa el destino real. getent utiliza el mecanismo de resolución del host; el resolvedor interno o la caché de Squid pueden ser distintos. Examina las entradas explícitas de dns_nameservers y hosts_file antes de suponer que coinciden.

En Squid 6.13, una lista explícita de servidores de nombres contiene direcciones IP:

dns_nameservers 192.0.2.53

Sustituye esta dirección de documentación por un resolvedor aprobado y accesible desde el servidor Squid. Los nombres privados pueden necesitar el resolvedor de la organización; uno público ajeno puede no incluirlos en su vista DNS.

Un alias del archivo hosts del portátil no viaja con una solicitud por nombre de host enviada mediante el proxy. Revisa la opción hosts_file de la versión de Squid instalada en la máquina que hace la consulta y ten en cuenta el resolvedor de un padre cuando corresponda. Mantén el nombre de host usado para la identidad TLS en consonancia con el servicio.

Tras un único cambio controlado de configuración, comprueba su sintaxis y recarga la instancia prevista, repite la misma solicitud y examina las pruebas correspondientes. Las respuestas positivas y negativas en caché pueden afectar a las pruebas repetidas. Una consulta correcta seguida de un tiempo de espera de conexión agotado es un fallo posterior de ruta o permisos; no sigas cambiando el DNS para corregirlo. Mantén constantes el DNS del cliente, el enrutamiento del padre y el protocolo proxy mientras evalúas el cambio del servidor.