Por que o tráfego CONNECT não preenche o cache de objetos do Squid
Por que um túnel HTTPS comum pode transferir muitos bytes sem fornecer ao proxy objetos de resposta HTTP reutilizáveis.
Um túnel CONNECT comum entrega ao Squid bytes criptografados, não uma resposta de site que possa ser armazenada em cache. Um download HTTPS grande pode gerar muito tráfego sem adicionar objeto reutilizável ao cache.
O Squid pode registrar destino, duração e contagem de bytes do túnel. Não recebe o caminho URL interno, diretivas de cache, representação e validadores como mensagens HTTP normais que possa guardar e reutilizar. Mais espaço em disco ou um limite maior de objeto não os revela.
Confira métodos de solicitação e registros de túneis antes de declarar o cache quebrado. Uma carga dominada por CONNECT combina com grandes transferências e pouca reutilização de objetos. Para uma verificação real, use recurso HTTP sob seu controle com cabeçalhos de cache explícitos e conteúdo conhecido; confirme que testa o processamento de objetos do Squid, não um túnel, o cache do navegador ou a CDN do destino.
O TLS até o proxy é outra camada. Depois de terminar o TLS do próprio listener, o Squid pode processar uma solicitação a um destino HTTP comum. Se essa conexão pedir CONNECT para HTTPS, o TLS interno do destino continua separado e opaco.
A interceptação HTTPS muda os requisitos de confiança em certificados, autorização e privacidade. Não é ajuste rotineiro de espaço de cache, e um proxy direto comum não precisa de interceptação para funcionar.