Mirror Rotation Changes What Squid Can Reuse
Explain why identical RPM packages downloaded from different mirror URLs can occupy separate Squid cache entries.
Two clients download the same RPM through Squid, but the second transfer still reaches a mirror. Compare the complete request URLs:
http://mirror-a.example.net/packages/tool-1.0.rpm
http://mirror-b.example.net/packages/tool-1.0.rpmThe package filenames match; their target URIs differ. HTTP cache keys include at least the request method and target URI, so matching package checksums do not automatically join these entries.
Yum and DNF can use a fixed baseurl or discover mirrors through mirrorlist and metalink. Identical installations may therefore select different download URLs.
Using one approved mirror gives visible requests a consistent cache identity. Keep repository paths, architecture, and suite aligned. Pinning also changes availability and mirror-selection behavior, so make it a repository policy decision.
Check whether object caching is available
Inside an ordinary HTTPS CONNECT tunnel, Squid cannot see the RPM response body for HTTP caching. A common mirror hostname will not change that. Keep HTTPS repositories encrypted.
For responses Squid can cache, reuse still depends on freshness, request and response directives, and local cache policy. Record the selected URL, whether the transaction was visible HTTP or an encrypted tunnel, and its cache result to explain a miss.