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