När Squid inte kan slå upp ett värdnamn
Kontrollera proxyserverns resolver; en lyckad uppslagning på klienten bevisar inte att Squid kan slå upp samma namn.
Undersök DNS där den misslyckade uppslagningen sker. Att din bärbara dator kan slå upp ett namn bevisar inte att Squid, eller en överordnad proxy som upprättar den vidare anslutningen, kan göra det.
Läs cacheloggen för den instans som misslyckas och kontrollera serverns resolverinställningar. En kompletterande kontroll på värdnivå är:
getent ahosts target.exampleAnvänd det faktiska målet. getent använder värdens uppslagningsmekanism; Squids interna resolver eller cache kan skilja sig. Undersök uttryckliga dns_nameservers- och hosts_file-indata innan du antar att de stämmer överens.
I Squid 6.13 innehåller en uttrycklig namnserverlista IP-adresser:
dns_nameservers 192.0.2.53Ersätt den här dokumentationsadressen med en godkänd resolver som kan nås från Squid-servern. Privata namn kan kräva organisationens resolver; en orelaterad offentlig resolver kanske inte ser dem i sin DNS-vy.
Ett alias i den bärbara datorns hosts-fil följer inte med en värdnamnsbegäran genom proxyn. Granska hosts_file-inställningen för den installerade Squid-versionen på den dator som gör uppslagningen, och beakta en överordnad proxys resolver när det är relevant. Värdnamnet för TLS-identiteten måste stämma med tjänsten.
Efter en enda kontrollerad konfigurationsändring ska du kontrollera syntaxen och läsa in den avsedda instansen på nytt, upprepa samma begäran och granska bevisen för den. Positiva och negativa svar i cachen kan påverka upprepade tester. En lyckad uppslagning följd av en anslutningstimeout är ett senare rutt- eller behörighetsfel; fortsätt inte ändra DNS för att lösa det. Håll klient-DNS, överordnad routning och proxyprotokollet oförändrade medan du bedömer serverändringen.