Gdy Squid nie potrafi rozwiązać nazwy hosta

Sprawdzaj DNS tam, gdzie wyszukiwanie kończy się niepowodzeniem. To, że laptop rozwiązuje nazwę, nie dowodzi, że potrafi to Squid lub nadrzędny serwer proxy nawiązujący dalsze połączenie.

Przeczytaj dziennik cache instancji, w której występuje błąd, i sprawdź ustawienia resolvera serwera. Pomocnicza kontrola na poziomie hosta to:

getent ahosts target.example

Użyj rzeczywistego celu. getent korzysta z mechanizmu wyszukiwania hosta; wewnętrzny resolver lub pamięć podręczna Squida mogą działać inaczej. Zanim założysz zgodność, sprawdź jawnie wskazane źródła dns_nameservers i hosts_file.

W Squid 6.13 jawna lista serwerów nazw zawiera adresy IP:

dns_nameservers 192.0.2.53

Zastąp ten adres dokumentacyjny zatwierdzonym resolverem osiągalnym z serwera Squid. Nazwy prywatne mogą wymagać resolvera organizacji; niezwiązany z nią publiczny resolver może nie widzieć ich w swoim widoku DNS.

Alias z pliku hosts laptopa nie jest przesyłany z żądaniem po nazwie hosta przez proxy. Na maszynie wykonującej wyszukiwanie przejrzyj ustawienie hosts_file dla zainstalowanej wersji Squida i w razie potrzeby uwzględnij resolver nadrzędnego proxy. Nazwa hosta używana jako tożsamość TLS powinna odpowiadać usłudze.

Po jednej kontrolowanej zmianie konfiguracji sprawdź jej składnię i przeładuj docelową instancję, powtórz to samo żądanie oraz przejrzyj związane z nim dowody. Dodatnie i ujemne odpowiedzi z pamięci podręcznej mogą wpływać na powtarzane testy. Udane wyszukanie, po którym upływa limit czasu połączenia, oznacza późniejszy błąd trasy lub uprawnień; nie zmieniaj dalej DNS, aby go naprawić. Podczas oceny zmiany serwera zachowaj niezmienione DNS klienta, routing nadrzędnego proxy i protokół proxy.