Намерете неуспешна заявка в журналите на 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 адреси, заявки, изходни адреси и потребителски имена могат да са лични; извеждането на цели журнали или включването на пълен запис на заглавките без конкретна нужда увеличава разкриването, вместо да дава полезни доказателства.