Hvorfor Squid logger HTTPS-vertsmaskinen men ikke sidens sti
Forklarer manglende HTTPS-stier i vanlige Squid CONNECT-logger uten å behandle TLS-avlytting som en rutinemessig loggjustering.
En post for shop.example:443 gir ikke Squid stien /orders/42. CONNECT ber om en vert/port; deretter bærer TLS-en til målet HTTP-stien inne i tunnelen.
| Bevis | Vanlig CONNECT-videresending |
|---|---|
| Målvert/port og tunnelresultat | Tilgjengelig for proxyen. |
| Indre HTTPS-sti og applikasjonsforespørsel | Kryptert mellom klient og nettsted. |
Nettleserens URL-fragment som begynner med # | Blir vanligvis i klienten, selv utenfor proxy-logging. |
Et loggformat kan registrere felt som 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 riktig utformet klienttelemetri. Ved proxyfeil, ta vare på målvert, timing, status og fullført tilkoblingstrinn; de lokaliserer ofte problemet uten å samle private sidestier.