Когато Squid не може да разреши име на хост

Проверявайте DNS там, където търсенето се проваля. Това, че лаптопът ви разрешава име, не доказва, че Squid или родителско прокси, което създава следващата връзка, може да го разреши.

Прочетете журнала на кеша на проблемния екземпляр и проверете настройките на резолвера на сървъра. Допълнителна проверка на ниво хост е:

getent ahosts target.example

Използвайте действителната цел. getent използва механизма за търсене на хоста; вътрешният резолвер или кешът на Squid може да се различава. Проверете изрично зададените dns_nameservers и hosts_file, преди да приемете, че съвпадат.

При Squid 6.13 изричният списък със сървъри за имена съдържа IP адреси:

dns_nameservers 192.0.2.53

Заменете този адрес за документация с одобрен резолвер, достъпен от сървъра Squid. Частните имена може да изискват резолвера на организацията; несвързан публичен резолвер може да не ги вижда в своя DNS изглед.

Псевдонимът от файла hosts на лаптопа не се предава със заявка по име на хост през прокси. На машината, която извършва търсенето, прегледайте настройката hosts_file за инсталираната версия на Squid и при нужда отчетете резолвера на родителското прокси. Името на хоста за TLS идентичността трябва да съответства на услугата.

След една контролирана промяна на конфигурацията проверете синтаксиса и презаредете нужния екземпляр, повторете същата заявка и прегледайте съответните доказателства. Положителните и отрицателните кеширани отговори могат да влияят на повторните тестове. Успешно търсене, последвано от изтекло време за свързване, е по-късен проблем с маршрута или правата; не продължавайте да променяте DNS, за да го поправите. Докато оценявате промяната на сървъра, запазете DNS на клиента, маршрутизацията на родителското прокси и прокси протокола непроменени.