On 25/12/2013 9:12 p.m., Ge Jin wrote:
> Hi, all!
>
> We use squid with tproxy for caching. As our special construct,
> our client origin destination is useless for getting the right
> response.
Why? what mangling are you doing to the TCP packet routing that would
cause the client browser to be connecting directly (as it sees it) to an
invalid IP address?
> So if there is any workaround, can we force squid use the
> Host header query result as the origin destination server address for
> fetch response.
Dont. http://www.squid-cache.org/Advisories/SQUID-2011_1.txt
Fix the above mentioned design problem with client traffic instead.
Ability to use the Host header flows naturally from that.
> Here is the log I get
>
> 1387958630.972 7142 192.168.1.13 TCP_MISS/503 3817 GET
> http://www.yahoo.com/ - HIER_DIRECT/192.168.134.32 text/html
> #
> "HIER_DIRECT/192.168.134.32" is the right destination server address.
>
> And I search this
> http://www.mail-archive.com/squid-users@squid-cache.org/msg92356.html
> and it's the revserse side of my situation, and I tried
> client_dst_passthru off and seems no help.
"client_dst_passthru off" will only work in request cases where the
TCP-level destination IP and the HTTP-level Host: header can be
validated as pointing at the same service (not necessarily same server
IP) via an independent DNS lookup by Squid.
NP: Cases where it is possible to use the Host header for destination
selection are the same cases where caching is permitted for the
response. So your brokenness of the client destination IP is also
breaking caching.
>
> Does anyone here can help ?
>
Before any help is given we come back to the initial question of "why?".
There is very probably a better way to do what you want. So please
explain the full usage for this proxy.
Amos
Received on Wed Dec 25 2013 - 10:06:04 MST
This archive was generated by hypermail 2.2.0 : Wed Dec 25 2013 - 12:00:05 MST