Как отлаживать Squid ERR_DNS_FAIL
Я управляю парой веб-прокси, использующих Squid 4.10 на Ubuntu 20.04LTS в нескольких местах по всему миру. У одного из них появилась неприятная привычка время от времени не заходить на веб-страницу. Вместо этого пользователь получает страницу с ошибкой, говорящую:
Hmmm... can't reach this page
It looks like the webpage at <URL> might be having issues,
or it may have moved permanently to a new web address.
ERR_TUNNEL_CONNECTION_FAILED
После добавления %err_code/%err_detailв конец соответствующего logformat, как рекомендовано в этом сообщении списка рассылки , записи Squid access.log для неудачных попыток доступа выглядят так: этот:
1635169354.239 171 10.72.1.103 NONE/503 0 CONNECT ad.360yield.com:443 - HIER_
NONE/- - ERR_DNS_FAIL/-
статус Squid равен NONE/503, а код ошибки и подробности всегда ERR_DNS_FAIL/-. Метка времени, IP-адрес клиента и запрошенный URL-адрес, конечно, различаются.
Каждое возникновение проблемы затрагивает одно полное доменное имя или очень небольшое количество полных доменных имен, часто все из одной организации (, например. lm.licenses.adobe.com и cc-api-data.adobe.io, оба от Adobe. )Все другие виды доступа продолжают нормально работать. Происшествие обычно длится от пяти до десяти минут. В течение этого времени затрагиваются все клиенты, пытающиеся получить доступ к этому полному доменному имени. До и после этого одно и то же FQDN работает без проблем. В затронутых FQDN нет заметной закономерности.
Некоторые события сопровождаются сообщением типа:
2021/10/25 15:42:34 kid1| ipcacheParse No Address records in response to 'ad.360yield.com'
в /var/log/squid/cache.log, но в большинстве случаев там ничего не регистрируется.
Как узнать, что там не так?
Повышение уровня журнала для поиска DNS до 6 путем помещения директивы
debug_options ALL,1 78,6
в /etc/squid/squid.confзаставляет Squid регистрировать /var/log/squid/cache.log, какой сервер имен использовался для неудачных запросов, например:
2021/10/26 16:16:43.088 kid1| 78,3| dns_internal.cc(1369) idnsRead: idnsRead: FD 17: received 32 bytes from 127.0.0.1:53
2021/10/26 16:16:43.088 kid1| 78,3| dns_internal.cc(1176) idnsGrokReply: idnsGrokReply: QID 0x376f, 0 answers
Затем сбои могут быть дополнительно исследованы на этом сервере имен.
В моем случае это указывало на прокси-сервер dnsmasqDNS, работающий на том же компьютере. Включение ведения журнала запросов в dnsmasqпоказало, что один из четырех настроенных внешних серверов имен был ответственен за сбои. Запросы, которые были отправлены на этот сервер имен, не удались,в то время как запросы, отправленные одному, трем другим удалось. Таким образом, решение состояло в том, чтобы удалить неисправный внешний сервер имен из конфигурации.