Hitta en misslyckad begäran i Squids loggar
Använd access.log för transaktionsresultat och cache.log för Squids egna fel, och skilj tunnelstatus från destinationens status.
Med Debians Squid 6-paket börjar du med de vanliga transaktions- och demonloggarna:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logAnpassad loggning eller en tjänstehanterare kan skicka dem någon annanstans. Återskapa en enda avgränsad begäran från en känd källa och anteckna tidpunkt, metod och destination så att du kan hitta rätt post.
| Bevis | Vad du kan läsa ut |
|---|---|
| Resultat i access.logs ursprungliga format | Squids resultatkod och HTTP-status är separata delar av transaktionen. |
| Information om åtkomsthierarki | Hur vidarebefordringen använde en överordnad proxy eller en annan rutt. |
| CONNECT lyckades | Tunneln öppnades; det är inte webbplatsens senare status inuti krypterad TLS. |
| cache.log | Fel i hjälpprogram, start, namnuppslagning och konfiguration i själva Squid. |
Om ingen matchande begäran visas, bekräfta att den här klienten nådde den här instansen och lyssnaren. Kontrollera loggnings-ACL:er, buffring, rotation och om transaktionen fortfarande är aktiv; en långlivad tunnel kanske ännu saknar en slutlig åtkomstpost. En förbikoppling eller en äldre proxyprocess kan skicka trafiken någon annanstans. Koppla därför den lyssnande processen till dess inlästa konfiguration innan du ändrar åtkomstpolicyn.
Dela den relevanta transaktionen med känsliga uppgifter maskerade och närliggande fel. URL:er, frågor, källadresser och användarnamn kan vara privata; att dumpa hela loggar eller aktivera fullständig headerloggning utan ett konkret behov ökar exponeringen i stället för att ge användbara bevis.