Waarom Squid de HTTPS-host wel en het paginapad niet logt
Verklaart ontbrekende HTTPS-paden in gewone Squid CONNECT-logs zonder TLS-interceptie als routinematige logaanpassing te behandelen.
Een vermelding voor shop.example:443 geeft Squid niet het pad /orders/42. CONNECT vraagt om een host/poort; daarna draagt de TLS van de bestemming het HTTP-pad in de tunnel.
| Bewijs | Gewone CONNECT-doorsturing |
|---|---|
| Doelhost/poort en tunnelresultaat | Beschikbaar voor de proxy. |
| Intern HTTPS-pad en applicatieverzoek | Versleuteld tussen client en website. |
Browsers-URL-fragment dat begint met # | Blijft normaal in de client, ook buiten proxylogging. |
Een logformaat kan velden vastleggen die Squid heeft, niet ongeziene berichten ontsleutelen. Gewone HTTP-doorsturing is anders omdat de tussenpartij dat HTTP-verzoek ontvangt. Uitgebreidere uitvoer verandert de CONNECT-grens niet.
Beheerde TLS-interceptie verandert clientvertrouwen en administratieve eisen. Het is geen kleine logschakelaar en is onnodig voor een normale IP-wisselende forward-proxy.
Als de applicatie van jou is en je diagnose op paginaniveau nodig hebt, gebruik dan de logs of passend ontworpen clienttelemetrie. Bewaar bij proxyfouten doelhost, timing, status en afgeronde verbindingsfase; die lokaliseren het probleem vaak zonder privépaden te verzamelen.