Derfor fyller ikke CONNECT-trafikk Squids objektcache
En vanlig HTTPS-tunnel kan flytte store datamengder uten å gi en forward proxy HTTP-svarobjekter som kan brukes på nytt.
En ordinær CONNECT-tunnel gir Squid krypterte byte, ikke et nettstedssvar som kan caches. Store HTTPS-nedlastinger kan dermed føre til mye trafikk uten at det kommer en gjenbrukbar oppføring i objektcachen.
Squid kan logge hvor tunnelen går, hvor lenge den varer og antall byte. Den indre URL-stien, cacheinstruksjoner, representasjonen og validatorene kommer ikke som vanlige HTTP-meldinger den kan lagre og bruke igjen. Større disk eller en høyere grense for objektstørrelse gjør dem ikke synlige.
Se på forespørselsmetoder og tunnellogger før du konkluderer med at caching er ødelagt. En arbeidsmengde dominert av CONNECT kan gi store overføringer og lite objektgjenbruk. Test cachen med en HTTP-ressurs du kontrollerer, som har eksplisitte cache-headere og kjent innhold. Bekreft at du tester Squids objektbane, ikke en tunnel, nettlesercachen eller et CDN ved målet.
TLS til proxyen er et eget lag. Når Squid har terminert TLS på sin egen lytter, kan den håndtere en vanlig forespørsel til et HTTP-mål. Hvis forbindelsen heller ber om CONNECT til HTTPS, forblir TLS til målet inni tunnelen separat og ugjennomsiktig.
HTTPS-avskjæring gir andre krav til sertifikattillit, autorisasjon og personvern. Det er ingen rutinemessig endring av cacheplass. En vanlig forward proxy trenger ikke avskjæring for å virke.