Wêrom't Squid de HTTPS-host mar net it sidenpaad logt
Ferklaret ûntbrekkende HTTPS-paden yn gewoane Squid CONNECT-logs sûnder TLS-ôflústerjen as in routineuze logynstelling te behanneljen.
In record foar shop.example:443 jout Squid it paad /orders/42 net. CONNECT freget in host/poarte; dêrnei draacht it TLS fan it doel it HTTP-paad binnen de tunnel.
| Bewiis | Gewoane CONNECT-oerdracht |
|---|---|
| Doelhost/poarte en tunnelresultaat | Beskikber foar de proxy. |
| Ynterne HTTPS-paad en applikaasje-oanfraach | Fersifere tusken klant en webside. |
Browser-URL-fragmint dat begjint mei # | Bliuwt normaal yn 'e klant, sels bûten proxylogging. |
In logformaat kin fjilden fêstlizze dy't Squid hat, net ûnsjoen berjochten ûntsiferje. Gewoane HTTP-oerdracht is oars, om't de tuskenpersoan dy HTTP-oanfraach ûntfangt. Mear detaillearre útfier feroaret de CONNECT-grins net.
Beheard TLS-ôflústerjen feroaret it fertrouwen fan 'e klant en bestjoerlike easken. It is gjin lytse logskaakel en is net nedich foar in normale IP-feroarjende forward-proxy.
As jo de applikaasje hawwe en diagnostyk op sidenivo nedich binne, brûk dan syn logs of passend ûntwurpen klanttelemetry. Foar proxyflaters, bewarje doelhost, timing, status en foltôge ferbiningsfaze; dy fine it probleem faak sûnder privee sidenpaden te sammeljen.