When Squid Can Cache APT Packages
Check HTTP transport, cache storage, object size and APT cache-control settings before expecting package requests to become Squid hits.
APT and aptitude can retrieve repository files through HTTP. Squid can cache an eligible HTTP response; the client does not have to be a web browser.
For a Squid 6 or 7 deployment, check these inputs when every package transfer still reaches the origin:
- The download uses HTTP, or Squid otherwise has access to the HTTP exchange. An HTTPS CONNECT tunnel alone does not expose the package response for caching.
- The cache has suitable storage configured. Successful forwarding does not establish that a disk cache exists.
- The archive fits the applicable cache directory's maximum object size. Small metadata and a large .deb can have different outcomes.
- The request and response permit storage and reuse under their cache-control policy.
APT exposes Acquire::http::No-Cache, Max-Age and No-Store. No-Store can prevent requested archive files from being stored. No-Cache asks for revalidation before a stored response is reused. Inspect the effective APT configuration as well as Squid's policy.
Compare the same complete URL and inspect the cache result in access.log. Different mirror hosts, changed repository paths or a locally cached package can mean that two installs never request the same network object.
A repository mirror maintains repository content deliberately rather than relying only on demand-driven HTTP cache reuse.