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@xxxxxxxxxxxxxxx/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
