Eine fehlgeschlagene Anfrage in Squids Logs finden
Lies Transaktionsergebnisse in access.log und Squids eigene Fehler in cache.log und unterscheide Tunnelstatus vom Status des Ziels.
Beim Squid-6-Paket von Debian beginnst du mit den üblichen Transaktions- und Daemon-Logs:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logEigene Logging-Einstellungen oder ein Dienstmanager können sie an andere Orte leiten. Reproduziere eine klar begrenzte Anfrage aus einer bekannten Quelle und notiere Zeitpunkt, Methode und Ziel, damit du den richtigen Eintrag zuordnen kannst.
| Beleg | Was daraus abzulesen ist |
|---|---|
| Natives Ergebnis in access.log | Squids Ergebniscode und der HTTP-Status sind getrennte Bestandteile der Transaktion. |
| Informationen zur Zugriffshierarchie | Wie die Weiterleitung einen übergeordneten Proxy oder eine andere Route nutzte. |
| CONNECT erfolgreich | Der Tunnel wurde geöffnet; das ist nicht der spätere Website-Status innerhalb der verschlüsselten TLS-Verbindung. |
| cache.log | Fehler von Hilfsprogrammen, Start, Namensauflösung und Konfiguration in Squid selbst. |
Wenn keine passende Anfrage erscheint, bestätige, dass dieser Client diese Instanz und diesen Listener erreicht hat. Prüfe Logging-ACLs, Pufferung, Rotation und ob die Transaktion noch aktiv ist; bei einem langlebigen Tunnel kann der abschließende Zugriffseintrag noch fehlen. Eine Umgehung oder ein älterer Proxyprozess kann Verkehr anderswohin leiten. Ordne daher den lauschenden Prozess seiner geladenen Konfiguration zu, bevor du die Zugriffsregeln änderst.
Teile die relevante Transaktion mit geschwärzten vertraulichen Angaben und die benachbarten Fehler. URLs, Abfragen, Quelladressen und Benutzernamen können privat sein. Ganze Logs auszugeben oder ohne konkreten Bedarf sämtliche Header zu protokollieren, erhöht die Offenlegung statt den Beweiswert.