Когда Squid может кешировать пакеты APT
Проверьте транспорт HTTP, хранилище кеша, размер объекта и параметры cache-control в APT, прежде чем ожидать, что запросы пакетов станут попаданиями Squid.
APT и aptitude могут получать файлы репозитория по HTTP. Squid может кешировать подходящий ответ HTTP; клиенту не обязательно быть веб-браузером.
При развёртывании Squid 6 или 7 проверьте эти входные данные, если каждая передача пакета всё ещё доходит до источника:
- Загрузка использует HTTP или Squid иным образом имеет доступ к обмену HTTP. Один только туннель HTTPS CONNECT не открывает ответ пакета для кеширования.
- В кеше настроено подходящее хранилище. Успешная пересылка не доказывает наличие дискового кеша.
- Архив помещается в максимальный размер объекта соответствующего каталога кеша. Небольшие метаданные и большой .deb могут давать разные результаты.
- Запрос и ответ разрешают хранение и повторное использование согласно их политике cache-control.
APT предоставляет Acquire::http::No-Cache, Max-Age и No-Store. No-Store может препятствовать сохранению запрошенных архивных файлов. No-Cache требует повторной проверки перед повторным использованием сохранённого ответа. Проверьте действующую конфигурацию APT, а также политику Squid.
Сравните тот же полный URL и проверьте результат кеша в access.log. Разные хосты зеркал, изменённые пути репозитория или локально закешированный пакет могут означать, что две установки никогда не запрашивают один и тот же сетевой объект.
Зеркало репозитория намеренно поддерживает содержимое репозитория, а не полагается только на повторное использование HTTP-кеша по запросу.