Почему Squid записывает хост HTTPS, но не путь страницы
Объясняет отсутствие путей HTTPS в обычных журналах Squid CONNECT, не считая перехват TLS рутинной настройкой журналирования.
Запись для shop.example:443 не даёт Squid путь /orders/42. CONNECT запрашивает хост/порт; затем TLS назначения несёт путь HTTP внутри туннеля.
| Доказательство | Обычная передача CONNECT |
|---|---|
| Целевой хост/порт и результат туннеля | Доступно прокси. |
| Внутренний путь HTTPS и запрос приложения | Зашифровано между клиентом и сайтом. |
Фрагмент URL браузера, начинающийся с # | Обычно остаётся в клиенте, даже вне журнала прокси. |
Формат журнала может записывать поля, которые есть у Squid, но не расшифровывает невидимые сообщения. Обычная пересылка HTTP отличается, потому что посредник получает этот HTTP-запрос. Более подробный вывод не меняет границу CONNECT.
Управляемый перехват TLS меняет доверие клиента и административные требования. Это не маленький переключатель журналирования, и он не нужен обычному форвардному прокси, меняющему IP.
Если приложение ваше и нужна диагностика на уровне страницы, используйте его журналы или должным образом спроектированную клиентскую телеметрию. При сбоях прокси сохраняйте хост назначения, время, статус и завершённый этап соединения; они часто находят проблему без сбора приватных путей страниц.