Почему CONNECT не заполняет объектный кэш Squid
Почему обычный HTTPS-туннель может передавать много байтов, не давая прямому прокси повторно используемых объектов HTTP-ответов.
Обычный туннель CONNECT даёт Squid зашифрованные байты, а не кэшируемый ответ сайта. Поэтому большая HTTPS-загрузка может создать много трафика и ни одной повторно используемой записи объектного кэша.
Squid может записывать адресат туннеля, длительность и количество байтов. Он не получает внутренний URL-путь, директивы кэша, представление и валидаторы как обычные HTTP-сообщения для хранения и повторного использования. Больше диска или более высокий предел размера объекта их не раскрывают.
Проверьте методы запросов и записи туннелей, прежде чем считать кэширование сломанным. Нагрузка преимущественно из CONNECT соответствует большим передачам и малому повторному использованию объектов. Для настоящей проверки используйте свой HTTP-ресурс с явными заголовками кэша и известным содержимым; убедитесь, что проверяете объектный путь Squid, а не туннель, кэш браузера или CDN адресата.
TLS до прокси — отдельный слой. Завершив TLS собственного слушателя, Squid может обработать обычный запрос к HTTP-адресату. Если соединение вместо этого запрашивает CONNECT к HTTPS, внутренний TLS адресата остаётся отдельным и непрозрачным.
Перехват HTTPS меняет требования к доверию сертификатов, авторизации и конфиденциальности. Это не обычная настройка места для кэша; нормальному прямому прокси перехват для работы не нужен.