Когда Squid не может разрешить имя узла
Проверьте резолвер прокси-сервера: успешный поиск на клиенте не доказывает, что 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 клиента, маршрутизацию родительского прокси и протокол прокси.