Hvorfor Squid logger HTTPS-verten, men ikke sidens bane
Forklarer manglende HTTPS-baner i vanlige Squid CONNECT-logger uten å behandle TLS-avlytting som en rutinemessig loggjustering.
En oppføring for shop.example:443 gir ikke Squid banen /orders/42. CONNECT ber om en vert/port; deretter bærer destinasjonens TLS HTTP-banen inne i tunnelen.
| Bevis | Vanlig CONNECT-videresending |
|---|---|
| Målvert/port og tunnelresultat | Tilgjengelig for proxyen. |
| Indre HTTPS-bane og applikasjonsforespørsel | Kryptert mellom klient og nettsted. |
Nettleserens URL-fragment som begynner med # | Blir normalt i klienten, også utenfor proxy-logging. |
Et loggformat kan registrere felt Squid har, ikke dekryptere usette meldinger. Vanlig HTTP-videresending er annerledes fordi mellomleddet mottar den HTTP-forespørselen. Mer detaljert utdata endrer ikke CONNECT-grensen.
Administrert TLS-avlytting endrer klienttillit og administrative krav. Det er ikke en liten loggbryter og er unødvendig for en vanlig IP-bytte forward-proxy.
Hvis du eier applikasjonen og trenger diagnose på sidenivå, bruk loggene eller tilpasset klienttelemetri. Ved proxyfeil, behold målvert, timing, status og fullført tilkoblingstrinn; de lokaliserer ofte problemet uten å samle private sidebaner.