Pourquoi Squid journalise l'hôte HTTPS mais pas le chemin de la page
Explique l'absence des chemins HTTPS dans les journaux Squid CONNECT ordinaires sans traiter l'interception TLS comme un réglage de journalisation courant.
Une entrée pour shop.example:443 ne donne pas à Squid le chemin /orders/42. CONNECT demande un hôte/un port ; ensuite le TLS de destination porte le chemin HTTP à l'intérieur du tunnel.
| Preuve | Relais CONNECT ordinaire |
|---|---|
| Hôte/port de destination et résultat du tunnel | Disponible pour le proxy. |
| Chemin HTTPS interne et requête applicative | Chiffré entre le client et le site. |
Fragment d'URL du navigateur commençant par # | Reste normalement dans le client, même hors de la journalisation du proxy. |
Un format de journal peut enregistrer les champs dont Squid dispose, pas déchiffrer des messages non vus. Le transfert HTTP simple est différent car l'intermédiaire reçoit cette requête HTTP. Une sortie plus détaillée ne change pas la frontière de CONNECT.
L'interception TLS gérée modifie la confiance du client et les exigences administratives. Ce n'est pas un petit interrupteur de journalisation et elle est inutile pour un proxy de transfert normal qui change d'IP.
Si vous possédez l'application et avez besoin de diagnostics au niveau de la page, utilisez ses journaux ou une télémétrie client conçue à cet effet. Pour les échecs du proxy, conservez l'hôte de destination, le minutage, le statut et l'étape de connexion achevée ; ils localisent souvent le problème sans collecter de chemins de page privés.