Per què Squid registra l'amfitrió HTTPS però no el camí de la pàgina
Explica els camins HTTPS que falten als registres ordinaris de Squid CONNECT sense tractar la intercepció TLS com un ajust rutinari del registre.
Un registre de shop.example:443 no dona a Squid el camí /orders/42. CONNECT demana un amfitrió/port; després el TLS de destinació porta el camí HTTP dins del túnel.
| Evidència | Retransmissió CONNECT ordinària |
|---|---|
| Amfitrió/port de destinació i resultat del túnel | Disponible per al proxy. |
| Camí HTTPS intern i sol·licitud de l'aplicació | Xifrat entre el client i el lloc web. |
Fragment d'URL del navegador que comença amb # | Normalment es queda al client, fins i tot fora del registre del proxy. |
Un format de registre pot enregistrar els camps que Squid té, no desxifrar missatges no vistos. El reenviament HTTP simple és diferent perquè l'intermediari rep aquesta sol·licitud HTTP. Una sortida més detallada no canvia la frontera de CONNECT.
La intercepció TLS gestionada canvia la confiança del client i els requisits administratius. No és un petit interruptor de registre i no cal per a un proxy d'avançament normal que canvia la IP.
Si l'aplicació és vostra i necessiteu diagnòstic a nivell de pàgina, feu servir els seus registres o una telemetria de client dissenyada adequadament. Per a fallades del proxy, conserveu l'amfitrió de destinació, el moment, l'estat i l'etapa de connexió completada; sovint localitzen el problema sense recollir camins de pàgina privats.