Warum Squid den HTTPS-Host, aber nicht den Seitenpfad protokolliert
Erklärt fehlende HTTPS-Pfade in gewöhnlichen Squid-CONNECT-Protokollen, ohne TLS-Interception als routinemäßige Protokollanpassung zu behandeln.
Ein Eintrag für shop.example:443 liefert Squid nicht den Pfad /orders/42. CONNECT fragt nach Host/Port; danach trägt das Ziel-TLS den HTTP-Pfad im Tunnel.
| Nachweis | Gewöhnliche CONNECT-Weiterleitung |
|---|---|
| Ziel-Host/Port und Tunnel-Ergebnis | Dem Proxy verfügbar. |
| Innerer HTTPS-Pfad und Anwendungsanfrage | Zwischen Client und Website verschlüsselt. |
Browser-URL-Fragment, das mit # beginnt | Bleibt normalerweise im Client, auch außerhalb der Proxy-Protokollierung. |
Ein Logformat kann Felder aufzeichnen, die Squid hat, aber keine ungesehenen Nachrichten entschlüsseln. Einfache HTTP-Weiterleitung ist anders, weil der Vermittler diese HTTP-Anfrage erhält. Ausführlichere Ausgaben ändern die CONNECT-Grenze nicht.
Verwaltete TLS-Interception ändert das Client-Vertrauen und administrative Anforderungen. Sie ist kein kleiner Protokollschalter und für einen normalen IP-wechselnden Forward-Proxy unnötig.
Wenn Ihnen die Anwendung gehört und Sie Diagnose auf Seitenebene benötigen, nutzen Sie ihre Protokolle oder angemessen gestaltete Client-Telemetrie. Für Proxy-Fehler behalten Sie Ziel-Host, Zeitpunkt, Status und abgeschlossene Verbindungsphase; diese lokalisieren das Problem oft, ohne private Seitenpfade zu erfassen.