Re: [squid-users] tproxy can't connect to target url after url rewrite program to different host

From: Eliezer Croitoru <>
Date: Sun, 29 Jul 2012 02:32:32 +0300

On 7/29/2012 2:21 AM, Ming-Ching Tiew wrote:
> From: Eliezer Croitoru <>
> To:
>> now that you remind me.
>> i have seen this kind of problem!!!
>> it was nasty on squid 3.1.
>> you can see in iptables connection tracking that squid is opening the
>> socket but it sends the first syn and wont get the incoming syn from the
>> destination.
>> but there are two different situations bridge and routing.
>> on bridge it's pretty obviates.
>> you must tell the bridge to "drop" the incoming traffic from of source
>> port 8080 otherwise it will be bridged to the client and wont get back
>> to squid.
> If it is an external web server, the ebtable rule will probably fix it.
> But for my case, on the squid machine, I have a web server, and
> the url rewrite redirect the traffic to this web server. And I don't seem
> to be able to get a reply back into squid. Which is blocking the reply
> ?
This is a problem with + tproxy and servers that hosts a webserver on
the same machine.
it seems like when squid on tproxy mode it opens a Socket to the origin
server and since it's on the same machine the routing on the machine
main routing table is to send it strait to the client machine without
intercepting\redirecting it into the lookback\squid.

the simple solution for that is to use cache_peer to port 8080 and use
acls to apply the rewritten request through the cache_peer remember to
add the cache_peer "no-tproxy" option.

if there was an option\acl "no-tproxy alllow acl_name" this would give
some nice option but since it's not needed for most of the users i dont
thing it will be implemented.


Eliezer Croitoru
IT consulting for Nonprofit organizations
eliezer <at>
Received on Sat Jul 28 2012 - 23:32:54 MDT

This archive was generated by hypermail 2.2.0 : Mon Jul 30 2012 - 12:00:02 MDT