Зашто Squid бележи HTTPS домаћина, али не путању странице
Објашњава недостајуће HTTPS путање у обичним Squid CONNECT дневницима без третирања TLS пресретања као рутинског подешавања дневника.
Запис за shop.example:443 не даје Squid-у путању /orders/42. CONNECT тражи домаћина/порт; затим TLS одредишта носи HTTP путању унутар тунела.
| Доказ | Обично CONNECT прослеђивање |
|---|---|
| Циљни домаћин/порт и исход тунела | Доступно проксију. |
| Унутрашња HTTPS путања и захтев апликације | Шифровано између клијента и веб-сајта. |
Фрагмент URL-а прегледача који почиње са # | Обично остаје у клијенту, чак и изван дневника проксија. |
Формат дневника може да забележи поља која Squid има, али не дешифрује невиђене поруке. Обично HTTP прослеђивање је другачије јер посредник прима тај HTTP захтев. Детаљнији излаз не мења CONNECT границу.
Управљано TLS пресретање мења поверење клијента и административне захтеве. Није мали прекидач за дневник и није потребно за нормални forward proxy који мења IP.
Ако поседујете апликацију и потребна вам је дијагностика на нивоу странице, користите њене дневнике или одговарајуће дизајнирану телеметрију клијента. За кварове проксија задржите циљни домаћин, време, статус и завршену фазу везе; они често лоцирају проблем без прикупљања приватних путања страница.