Trova una richiesta fallita nei log di Squid
Usa access.log per i risultati delle transazioni e cache.log per i guasti di Squid, distinguendo lo stato del tunnel da quello della destinazione.
Con il pacchetto Squid 6 di Debian, inizia dai consueti log delle transazioni e del demone:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logUna registrazione personalizzata o un gestore dei servizi può inviarli altrove. Riproduci una sola richiesta di ambito limitato da un’origine nota e annota ora, metodo e destinazione per individuare la voce corretta.
| Evidenza | Che cosa ricavarne |
|---|---|
| Risultato nativo di access.log | Il codice di risultato di Squid e lo stato HTTP sono parti distinte della transazione. |
| Informazioni sulla gerarchia di accesso | Come l’inoltro ha usato un proxy padre o un altro percorso. |
| CONNECT riuscito | Il tunnel si è aperto; non è lo stato successivo del sito web all’interno del TLS cifrato. |
| cache.log | Guasti di helper, avvio, risolutore e configurazione di Squid stesso. |
Se non compare una richiesta corrispondente, verifica che questo client abbia raggiunto questa istanza e questo listener. Controlla ACL di logging, buffering, rotazione e se la transazione è ancora attiva; un tunnel di lunga durata potrebbe non avere ancora una voce di accesso finale. Un bypass o un vecchio processo proxy può inviare il traffico altrove: associa quindi il processo in ascolto alla configurazione caricata prima di modificare la politica di accesso.
Condividi la transazione pertinente con i dati sensibili oscurati e gli errori vicini. URL, query, indirizzi di origine e nomi utente possono essere privati; riversare interi log o abilitare la registrazione completa degli header senza una necessità precisa aumenta l’esposizione anziché fornire evidenze utili.