[squid-users] a strange problem ( ORIGINAL_DST( can't be cache ) HIER_DIRECT ( can be cache )
squid3 at treenet.co.nz
Mon Apr 11 06:40:28 UTC 2016
On 11/04/2016 4:34 p.m., johnzeng wrote:
> Hello Dear Sir :
> i am trying to imporve hit ration for cache pic file now , but i found a
> strange problem .
> When i access the pic url via firefox browser , i found the content
> can't be cache .( http_port 8080 tproxy at bridge mode )
> and some helpful info is ORIGINAL_DST/188.8.131.52 at access.log
ORIGINAL_DST means that interception is being used and that NAT system
was used to find the server.
> When i access the pic url via firefox wget , i found the content can be
> cache .
> wget -e "http_proxy=http://localhost:8081" -e robots=off
> --user-agent="Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206)
> Gecko/2008092416 Firefox/3.0.3" -r -p -nd -np -H --level=2 --tries=1
> ( http_port 8081 via bridge self-host )
> and some helpful info is - HIER_DIRECT/220.127.116.11
DIRECT means regular forward-proxy is happening, and that DNS system was
used to find the server.
> if possible , please give me some advisement , thanks .
When NAT intercept or TPROXY are involved Squid has additional security
checks that have to be applied. Host header verification / forgery
detection is the most noticed one.
If Squid determines that the client is in fact *not* going to the server
mentioned in the Host header it will let the transaction happen to that
ORIGINAL_DST but cannot cache it.
Some things you can do to minimize the false verify results are detailed
in <http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery>. Due to
how some popular CDN operate we cannot completely eliminate the false
results, best we can do is let it through with disabled caching.
More information about the squid-users