Greetings! Today I bring you a Squid cache mystery.
I configured a simple transparent proxy to cache package downloads for
Debian, using Squid on Debian 10. When apt clients download packages
from deb.debian.org, Squid says TCP_MISS, downloads the package, and
then doesn't cache it. The myster
On 4/3/20 16:34, Alex Rousskov wrote:
On 4/3/20 4:26 PM, zrm wrote:
In the first case we get TCP_MISS every time because it isn't caching
the data, in the second case it's only the first time and after that we
get TCP_REFRESH_UNMODIFIED. But how and why is this happening?
Those que
On 4/4/20 10:53, Alex Rousskov wrote:
The headers you have posted tell us that the object was not in Squid
cache when apt and wget transactions started. Since wget was started
after apt, we can speculate that apt transaction did not cache the
object. This is consistent with your observations. I s
cache.log for apt-apt-wget-wget with squid -k debug:
https://www.trustiosity.com/squid/cache-debug.log.xz
On 4/6/20 11:49, Alex Rousskov wrote:
On 4/4/20 8:02 PM, zrm wrote:
Attached cache.log excerpt for wget-wget-apt-apt-wget-wget. It answers
the apt requests from the cache once it'
On 4/8/20 10:46, Alex Rousskov wrote:
On 4/7/20 8:48 PM, zrm wrote:
https://www.trustiosity.com/squid/cache-debug.log.xz
I found the reason for the difference.
After the destination IP address of your apt requests fails Host header
validation, Squid marks the request as "not cachable&
On 4/8/20 13:13, Matus UHLAR - fantomas wrote:
On 08.04.20 13:01, zrm wrote:
I checked the DNS query apt is making to see why it's different. It's
making a SRV query for _http._tcp.deb.debian.org and then using the IP
address of the name (prod.debian.map.fastly.net) returned in the
