Коли 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-кешу на запит.