Por que o Squid registra o host HTTPS mas não o caminho da página
Explica os caminhos HTTPS ausentes nos registos Squid CONNECT comuns sem tratar a interceção TLS como um ajuste rotineiro do registo.
Um registo para shop.example:443 não dá ao Squid o caminho /orders/42. O CONNECT pede um host/porta; depois o TLS de destino transporta o caminho HTTP dentro do túnel.
| Evidência | Retransmissão CONNECT comum |
|---|---|
| Host/porta de destino e resultado do túnel | Disponível para o proxy. |
| Caminho HTTPS interno e pedido da aplicação | Encriptado entre o cliente e o sítio web. |
Fragmento de URL do navegador que começa com # | Normalmente fica no cliente, mesmo fora do registo do proxy. |
Um formato de registo pode registar campos que o Squid tem, não desencriptar mensagens não vistas. O reencaminhamento HTTP simples é diferente porque o intermediário recebe esse pedido HTTP. Uma saída mais detalhada não altera a fronteira do CONNECT.
A interceção TLS gerida altera a confiança do cliente e os requisitos administrativos. Não é um pequeno interruptor de registo e é desnecessária para um proxy de reencaminhamento normal que muda de IP.
Se a aplicação é sua e precisa de diagnóstico ao nível da página, use os seus registos ou telemetria de cliente concebida adequadamente. Para falhas do proxy, guarde o host de destino, o tempo, o estado e a etapa de ligação concluída; muitas vezes localizam o problema sem recolher caminhos de página privados.