Why CONNECT Traffic Does Not Fill Squid's Object Cache
Explain why an ordinary HTTPS tunnel can transfer many bytes without giving a forward proxy reusable HTTP response objects.
An ordinary CONNECT tunnel gives Squid encrypted bytes rather than a cacheable website response. A large HTTPS download can therefore add plenty of traffic and no reusable object-cache entry.
Squid can record the tunnel destination, duration and byte count. It does not receive the inner URL path, cache directives, representation and validators as normal HTTP messages it can store and reuse. More disk space or a larger object-size limit cannot reveal them.
Check request methods and tunnel records before declaring caching broken. A workload dominated by CONNECT is consistent with heavy transfers and little object reuse. For an actual cache check, use an HTTP resource you control with explicit cache headers and known content; confirm that you are testing Squid's object path rather than a tunnel, browser cache or destination CDN.
TLS to the proxy is a separate layer. After terminating its own TLS listener, Squid can process an ordinary HTTP destination request. If that connection instead requests CONNECT to HTTPS, the inner destination TLS remains separate and opaque.
HTTPS interception changes certificate trust, authorization and privacy requirements. It is not a routine cache-space adjustment, and a normal forward proxy needs no interception to operate.