Hvorfor Squid logger HTTPS-værten, men ikke sidens sti
Forklarer manglende HTTPS-stier i almindelige Squid CONNECT-logs uden at behandle TLS-aflytning som en rutinemæssig logjustering.
En post for shop.example:443 giver ikke Squid stien /orders/42. CONNECT beder om en vært/port; derefter bærer destinations-TLS HTTP-stien inde i tunnelen.
| Bevis | Almindelig CONNECT-videreformidling |
|---|---|
| Målvært/port og tunnelresultat | Tilgængeligt for proxyen. |
| Indre HTTPS-sti og applikationsanmodning | Krypteret mellem klient og websted. |
Browser-URL-fragment, der begynder med # | Bliver normalt i klienten, selv uden for proxy-logning. |
Et logformat kan registrere felter, som Squid har, ikke dekryptere usete meddelelser. Almindelig HTTP-videreformidling er anderledes, fordi mellemleddet modtager den HTTP-anmodning. Mere detaljeret output ændrer ikke CONNECT-grænsen.
Administreret TLS-aflytning ændrer klienttillid og administrative krav. Det er ikke en lille logkontakt og er unødvendigt for en normal IP-skiftende forward-proxy.
Hvis du ejer applikationen og har brug for diagnostik på sideniveau, brug dens logs eller passende designet klienttelemetri. Ved proxyfejl, bevar målvært, timing, status og afsluttet forbindelsestrin; de lokaliserer ofte problemet uden at indsamle private sidestier.