Найдите неудачный запрос в журналах Squid
Используйте access.log для результатов транзакций, а cache.log — для сбоев самого Squid, отличая статус туннеля от статуса адресата.
В пакете Squid 6 для Debian начните с обычных журналов транзакций и демона:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logПользовательские настройки журналирования или менеджер служб могут направлять их в другое место. Воспроизведите один запрос с ограниченной областью из известного источника и запишите время, метод и адресата, чтобы найти нужную запись.
| Данные | Что из них узнать |
|---|---|
| Результат access.log в родном формате | Код результата Squid и HTTP-статус — отдельные части транзакции. |
| Информация об иерархии доступа | Как пересылка использовала родительский прокси или другой маршрут. |
| Успешный CONNECT | Туннель открылся; это не последующий статус сайта внутри зашифрованного TLS. |
| cache.log | Сбои вспомогательных программ, запуска, резолвера и конфигурации самого Squid. |
Если подходящего запроса нет, убедитесь, что этот клиент достиг именно этого экземпляра и слушателя. Проверьте ACL журналирования, буферизацию, ротацию и остаётся ли транзакция активной: у долгоживущего туннеля ещё может не быть итоговой записи доступа. Обход прокси или старый процесс прокси может направлять трафик в другое место, поэтому перед изменением политики доступа сопоставьте слушающий процесс с загруженной им конфигурацией.
Передайте соответствующую транзакцию с удалёнными конфиденциальными данными и соседние ошибки. URL, параметры запросов, адреса источников и имена пользователей могут быть частными. Выгрузка целых журналов или включение записи всех заголовков без конкретной необходимости увеличивает раскрытие данных вместо пользы для диагностики.