在 Squid 日志中找到失败的请求
用 access.log 查看事务结果，用 cache.log 排查 Squid 自身故障，并区分隧道状态与目标网站状态。
使用 Debian 的 Squid 6 软件包时，先查看通常的事务日志和守护进程日志：
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.log自定义日志配置或服务管理器可能把它们送往其他位置。从已知来源重现一个范围明确的请求，并记录时间、方法和目标，以便匹配正确的记录。
| 证据 | 从中读取什么 |
|---|---|
| access.log 原生结果 | Squid 结果码和 HTTP 状态是事务中彼此独立的部分。 |
| 访问层级信息 | 转发如何使用父代理或其他路径。 |
| CONNECT 成功 | 表示隧道已打开，并不是加密 TLS 内后续的网站状态。 |
| cache.log | Squid 自身的辅助程序、启动、解析器和配置故障。 |
如果找不到匹配请求，先确认这个客户端确实到达了这个实例和监听端。检查日志 ACL、缓冲、轮转，以及事务是否仍处于活动状态；长期保持的隧道可能尚无最终访问记录。绕过规则或旧代理进程可能将流量送往其他地方，因此修改访问策略前，应先把监听进程与它加载的配置对应起来。
分享经过脱敏的相关事务记录及附近错误。URL、查询内容、源地址和用户名可能属于私密信息；没有具体需要就导出整份日志或启用完整请求头日志，只会增加暴露，而非提供有用证据。