Калі 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 кліента, маршрутызацыю бацькоўскага проксі і пратакол проксі.