Why Squid Logs the HTTPS Host but Not the Page Path
Explain missing HTTPS paths in ordinary Squid CONNECT logs without treating TLS interception as a routine logging adjustment.
A record for shop.example:443 does not give Squid the path /orders/42. CONNECT asks for a host/port; destination TLS then carries the HTTP path inside the tunnel.
| Evidence | Ordinary CONNECT relay |
|---|---|
| Target host/port and tunnel outcome | Available to the proxy. |
| Inner HTTPS path and application request | Encrypted between client and website. |
Browser URL fragment beginning with # | Normally stays in the client, even outside proxy logging. |
A log format can record fields Squid has, not decrypt unseen messages. Plain HTTP forwarding is different because the intermediary receives that HTTP request. More verbose output does not change the CONNECT boundary.
Managed TLS interception changes client trust and administrative requirements. It is not a small logging switch and is unnecessary for a normal IP-changing forward proxy.
If you own the application and need page-level diagnostics, use its logs or appropriately designed client telemetry. For proxy failures, retain destination host, timing, status and completed connection stage; those often locate the problem without collecting private page paths.