Vind een mislukt request in de logs van Squid
Gebruik access.log voor transactieresultaten en cache.log voor fouten in Squid zelf, en onderscheid de tunnelstatus van de bestemmingsstatus.
Begin bij het Squid 6-pakket van Debian met de gebruikelijke transactie- en daemonlogs:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logAangepaste logging of een servicemanager kan ze ergens anders naartoe sturen. Reproduceer één request met beperkte reikwijdte vanuit een bekende bron en noteer tijdstip, methode en bestemming om de juiste vermelding te vinden.
| Bewijs | Wat je eruit kunt afleiden |
|---|---|
| Resultaat in de native indeling van access.log | De resultaatcode van Squid en de HTTP-status zijn afzonderlijke onderdelen van de transactie. |
| Informatie over de toegangshiërarchie | Hoe het doorsturen een bovenliggende proxy of een andere route gebruikte. |
| Geslaagde CONNECT | De tunnel is geopend; dit is niet de latere websitestatus binnen versleutelde TLS. |
| cache.log | Fouten van helpers, opstarten, resolver en configuratie in Squid zelf. |
Verschijnt er geen passend request, bevestig dan dat deze client deze instantie en listener bereikte. Controleer logging-ACL’s, buffering, rotatie en of de transactie nog actief is; een langdurige tunnel heeft mogelijk nog geen definitieve toegangsvermelding. Een omzeiling of een ouder proxyproces kan verkeer elders heen sturen. Koppel daarom het luisterende proces aan zijn geladen configuratie voordat je het toegangsbeleid wijzigt.
Deel de relevante transactie met gevoelige gegevens afgeschermd en de nabijgelegen fouten. URL’s, query’s, bronadressen en gebruikersnamen kunnen privé zijn; complete logs dumpen of zonder concrete noodzaak volledige headerlogging aanzetten vergroot de blootstelling in plaats van bruikbaar bewijs te leveren.