Waarom Squid die HTTPS-gasheer maar nie die bladsypad aanteken nie
Verduidelik ontbrekende HTTPS-paaie in gewone Squid CONNECT-logboeke sonder om TLS-onderskapping as 'n roetine-logaanpassing te behandel.
'n Rekord vir shop.example:443 gee nie vir Squid die pad /orders/42 nie. CONNECT vra vir 'n gasheer/poort; die bestemming se TLS dra dan die HTTP-pad binne die tonnel.
| Bewyse | Gewone CONNECT-herleiding |
|---|---|
| Teikengasheer/poort en tonneluitkoms | Beskikbaar vir die volmagtigde. |
| Binneste HTTPS-pad en toepassingsversoek | Geenkripteer tussen klieent en webwerf. |
Blaaier-URL-fragment wat met # begin | Bly gewoonlik in die klieent, selfs buite volmagtigde-logboeke. |
'n Logformaat kan velde wat Squid het, aanteken, maar nie ongesiene boodskappe ontsyfer nie. Gewone HTTP-aanstuur verskil omdat die tussenganger daardie HTTP-versoek ontvang. Meer uitvoer verander nie die CONNECT-grens nie.
Bestuurde TLS-onderskapping verander klieentvertroue en administratiewe vereistes. Dit is nie 'n klein logskakelaar nie en is onnodig vir 'n normale IP-wisselende aanstuur-volmagtigde.
As jy die toepassing besit en bladsyvlak-diagnose nodig het, gebruik sy logboeke of gepas ontwerpte klieenttelemetrie. Vir volmagtigde-foute, hou teikengasheer, tydsberekening, status en voltooide verbindingstadium; dit vind dikwels die probleem sonder om private bladsypaaie te versamel.