Warum CONNECT-Verkehr Squids Objektcache nicht füllt
Warum ein gewöhnlicher HTTPS-Tunnel viele Bytes übertragen kann, ohne einem Forward-Proxy wiederverwendbare HTTP-Antwortobjekte zu liefern.
Ein gewöhnlicher CONNECT-Tunnel liefert Squid verschlüsselte Bytes statt einer cachefähigen Website-Antwort. Ein großer HTTPS-Download kann daher viel Verkehr erzeugen, ohne einen wiederverwendbaren Objektcache-Eintrag hinzuzufügen.
Squid kann Tunnelziel, Dauer und Bytezahl protokollieren. Inneren URL-Pfad, Cache-Anweisungen, Repräsentation und Validatoren erhält es nicht als normale HTTP-Nachrichten zum Speichern und Wiederverwenden. Mehr Speicherplatz oder ein höheres Objektgrößenlimit machen sie nicht sichtbar.
Vor der Diagnose eines defekten Caches Anfrageverfahren und Tunnelaufzeichnungen prüfen. Eine CONNECT-dominierte Last passt zu großen Übertragungen bei geringer Objektwiederverwendung. Für einen echten Cache-Test eine eigene HTTP-Ressource mit ausdrücklichen Cache-Headern und bekanntem Inhalt nutzen; sicherstellen, dass Squids Objektpfad geprüft wird, nicht Tunnel, Browsercache oder Ziel-CDN.
TLS zum Proxy ist eine eigene Schicht. Nach dem Terminieren seines eigenen TLS-Listeners kann Squid eine gewöhnliche HTTP-Zielanfrage verarbeiten. Fordert diese Verbindung stattdessen CONNECT zu HTTPS an, bleibt das innere Ziel-TLS getrennt und undurchsichtig.
HTTPS-Interception verändert Zertifikatsvertrauen, Autorisierung und Datenschutzanforderungen. Sie ist keine gewöhnliche Anpassung des Cacheplatzes; ein normaler Forward-Proxy benötigt sie nicht zum Betrieb.