Por qué Squid registra el host HTTPS pero no la ruta de la página
Explica las rutas HTTPS ausentes en los registros Squid CONNECT habituales sin tratar la interceptación TLS como un ajuste rutinario del registro.
Un registro de shop.example:443 no da a Squid la ruta /orders/42. CONNECT pide un host/puerto; después el TLS de destino lleva la ruta HTTP dentro del túnel.
| Evidencia | Retransmisión CONNECT habitual |
|---|---|
| Host/puerto de destino y resultado del túnel | Disponible para el proxy. |
| Ruta HTTPS interna y solicitud de la aplicación | Cifrado entre el cliente y el sitio web. |
Fragmento de URL del navegador que empieza por # | Normalmente se queda en el cliente, incluso fuera del registro del proxy. |
Un formato de registro puede registrar los campos que Squid tiene, no descifrar mensajes no vistos. El reenvío HTTP simple es distinto porque el intermediario recibe esa solicitud HTTP. Una salida más detallada no cambia el límite de CONNECT.
La interceptación TLS gestionada cambia la confianza del cliente y los requisitos administrativos. No es un pequeño interruptor de registro y es innecesaria para un proxy de reenvío normal que cambia la IP.
Si la aplicación es suya y necesita diagnóstico a nivel de página, use sus registros o telemetría de cliente diseñada adecuadamente. Para fallos del proxy, conserve el host de destino, el tiempo, el estado y la etapa de conexión completada; a menudo localizan el problema sin recopilar rutas de página privadas.