Retrouver une requête en échec dans les journaux de Squid
Utilisez access.log pour les résultats des transactions et cache.log pour les pannes de Squid, en distinguant le statut du tunnel de celui de la destination.
Avec le paquet Squid 6 de Debian, commencez par les journaux habituels des transactions et du démon :
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logUne journalisation personnalisée ou un gestionnaire de services peut les envoyer ailleurs. Reproduisez une seule requête de portée limitée depuis une source connue et notez son heure, sa méthode et sa destination pour retrouver la bonne entrée.
| Élément probant | Ce qu’il permet de lire |
|---|---|
| Résultat natif d’access.log | Le code de résultat Squid et le statut HTTP sont deux éléments distincts de la transaction. |
| Informations de hiérarchie d’accès | La manière dont le transfert a utilisé un proxy parent ou un autre trajet. |
| Succès de CONNECT | Le tunnel s’est ouvert ; ce n’est pas le statut ultérieur du site web à l’intérieur du flux TLS chiffré. |
| cache.log | Les défaillances des auxiliaires, du démarrage, du résolveur et de la configuration de Squid lui-même. |
Si aucune requête correspondante n’apparaît, vérifiez que ce client a atteint cette instance et ce point d’écoute. Contrôlez les ACL de journalisation, la mise en tampon, la rotation et si la transaction est encore active ; un tunnel de longue durée peut ne pas encore avoir d’entrée d’accès finale. Un contournement ou un ancien processus proxy peut envoyer le trafic ailleurs : associez donc le processus à l’écoute à sa configuration chargée avant de modifier la politique d’accès.
Partagez la transaction pertinente expurgée des données sensibles et les erreurs voisines. Les URL, requêtes, adresses sources et noms d’utilisateur peuvent être privés ; publier des journaux entiers ou activer la journalisation complète des en-têtes sans besoin précis augmente l’exposition plutôt que d’apporter des éléments utiles.