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