Når Squid ikkje kan slå opp eit vertsnamn

Undersøk DNS der det mislukka oppslaget skjer. At den berbare maskina di kan slå opp eit namn, provar ikkje at Squid eller ein overordna proxy som opprettar den vidare tilkoplinga, kan gjere det.

Les cacheloggen til instansen som feilar og kontroller resolverinnstillingane til tenaren. Ein supplerande kontroll på vertsnivå er:

getent ahosts target.example

Bruk det faktiske målet. getent nyttar oppslagsmekanismen til verten; den interne resolveren eller hurtigbufferen til Squid kan vere annleis. Undersøk eksplisitte dns_nameservers- og hosts_file-inndata før du går ut frå at dei samsvarar.

I Squid 6.13 inneheld ei eksplisitt namnetenarliste IP-adresser:

dns_nameservers 192.0.2.53

Byt ut denne dokumentasjonsadressa med ein godkjend resolver som er tilgjengeleg frå Squid-tenaren. Private namn kan krevje resolveren til organisasjonen; ein uvedkomande offentleg resolver kan mangle dei i si DNS-vising.

Eit alias i hosts-fila til den berbare maskina følgjer ikkje med ein vertsnamnførespurnad gjennom proxyen. Undersøk hosts_file-innstillinga for den installerte Squid-versjonen på maskina som gjer oppslaget, og ta omsyn til resolveren til ein overordna proxy der det er relevant. Vertsnamnet som vert nytta til TLS-identitet, må samsvare med tenesta.

Etter éi kontrollert konfigurasjonsendring må du kontrollere syntaksen og laste inn den tiltenkte instansen på nytt, gjenta same førespurnad og undersøkje prova for han. Positive og negative svar i hurtigbufferen kan påverke gjentekne testar. Eit vellukka oppslag etterfølgt av eit tilkoplingstidsavbrot er ein seinare rute- eller løyvefeil; ikkje hald fram med å endre DNS for å rette han. Hald klient-DNS, overordna ruting og proxyprotokollen uendra medan du vurderer tenarendringa.