Hi, Amos!
Thanks for your reply!
To make a long story short, our struct is like this.
tproxy tproxy
client -------------> haproxy -------------> squid cluster ---------->
Router -------> internet
We use haproxy for load balance, and squid for caching. And the most
difficult part is the Router must see the clients source addresses. So
we want to deliver the client address by tproxy. But haproxy just
delivers the clients addresses and the squid address as the
destination address. So I supposed there can be some workaround on
squid for my purpose.
On Wed, Dec 25, 2013 at 6:05 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
> 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
>
