일반적인 CONNECT 터널은 Squid에 캐시할 수 있는 웹사이트 응답이 아니라 암호화된 바이트를 전달합니다. 따라서 대용량 HTTPS 다운로드로 트래픽이 크게 늘어도 객체 캐시에 재사용 가능한 항목이 하나도 추가되지 않을 수 있습니다.

Squid는 터널의 대상, 지속 시간, 바이트 수를 기록할 수 있습니다. 하지만 내부 URL 경로, 캐시 지시문, 표현, 검증자를 저장하고 재사용할 수 있는 일반 HTTP 메시지로 받지는 않습니다. 디스크 공간이나 객체 크기 제한을 늘려도 이러한 정보가 드러나지는 않습니다.

캐시가 고장 났다고 판단하기 전에 요청 메서드와 터널 기록을 확인하세요. CONNECT가 대부분인 작업 부하에서는 전송량이 많고 객체 재사용이 적어도 이상하지 않습니다. 캐시를 실제로 점검하려면 직접 제어하며 명시적인 캐시 헤더와 알려진 콘텐츠가 있는 HTTP 리소스를 사용하세요. 터널, 브라우저 캐시, 대상 CDN이 아니라 Squid의 객체 처리 경로를 시험하는지 확인하세요.

프록시까지의 TLS는 별도의 계층입니다. Squid는 자체 리스너에서 TLS 연결을 종료한 뒤 일반 HTTP 대상을 향한 요청을 처리할 수 있습니다. 그 연결이 대신 HTTPS로의 CONNECT를 요청하면 내부 대상 TLS는 별개로 유지되며 내용을 볼 수 없습니다.

HTTPS 가로채기는 인증서 신뢰, 권한 부여, 개인정보 보호 요구 사항을 바꿉니다. 이는 일상적인 캐시 공간 조정이 아니며, 일반적인 포워드 프록시는 작동하는 데 가로채기가 필요하지 않습니다.

관련 글