Find a Failed Request in Squid's Logs
Use access.log for transaction results and cache.log for Squid's own failures, while distinguishing tunnel status from destination status.
On Debian's Squid 6 package, start with the usual transaction and daemon logs:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logCustom logging or a service manager can send them elsewhere. Reproduce one bounded request from a known source and record its time, method and destination so you can match the right record.
| Evidence | What to read from it |
|---|---|
| access.log native result | Squid's result code and HTTP status are separate parts of the transaction. |
| Access hierarchy information | How forwarding used a parent or another route. |
| CONNECT success | The tunnel opened; it is not the later website status inside encrypted TLS. |
| cache.log | Helper, startup, resolver and configuration failures in Squid itself. |
If no matching request appears, confirm that this client reached this instance and listener. Check logging ACLs, buffering, rotation and whether the transaction is still active; a long-lived tunnel may have no final access record yet. A bypass or older proxy process can send traffic somewhere else, so match the listening process to its loaded configuration before editing access policy.
Share the relevant redacted transaction and nearby errors. URLs, queries, source addresses and usernames can be private; dumping whole logs or enabling full header logging without a specific need adds exposure rather than useful evidence.