Hanapin ang nabigong request sa mga log ng Squid
Gamitin ang access.log para sa resulta ng transaksiyon at cache.log para sa mga pagkabigo ng Squid mismo, at ihiwalay ang status ng tunnel sa status ng destinasyon.
Sa Squid 6 package ng Debian, magsimula sa karaniwang mga log ng transaksiyon at daemon:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logMaaaring ipadala ang mga ito sa ibang lugar ng custom na logging o service manager. Ulitin ang isang request na may limitadong saklaw mula sa kilalang pinagmulan at itala ang oras, method at destinasyon upang maitugma ang tamang rekord.
| Ebidensiya | Ano ang mababasa rito |
|---|---|
| Resulta sa katutubong format ng access.log | Magkahiwalay na bahagi ng transaksiyon ang result code ng Squid at ang HTTP status. |
| Impormasyon sa hierarchy ng access | Kung paano gumamit ang pagpapasa ng parent proxy o ibang ruta. |
| Tagumpay ng CONNECT | Nabuksan ang tunnel; hindi ito ang kasunod na status ng website sa loob ng naka-encrypt na TLS. |
| cache.log | Mga pagkabigo ng helper, startup, resolver at configuration sa Squid mismo. |
Kung walang lumabas na katugmang request, tiyaking nakarating ang client na ito sa instance at listener na ito. Suriin ang mga logging ACL, buffering, rotation at kung aktibo pa ang transaksiyon; maaaring wala pang huling access record ang tunnel na matagal nang bukas. Maaaring ilihis sa ibang lugar ng bypass o mas lumang proxy process ang trapiko, kaya itugma ang nakikinig na proseso sa configuration na na-load nito bago baguhin ang access policy.
Ibahagi ang kaugnay na transaksiyon na may nakatagong sensitibong datos at ang mga error sa malapit. Maaaring pribado ang mga URL, query, source address at username; ang paglalabas ng buong log o pagpapagana ng buong header logging nang walang tiyak na pangangailangan ay nagdaragdag ng pagkalantad sa halip na kapaki-pakinabang na ebidensiya.