[squid-users] reverse proxy cache_peer selection weirdness

Hi,

I ran into this problem lately with a Squid-2.6-STABLE6 running as a reverse Proxy.
The meaningful parts of a squid.conf:

https_port ip_squid_1:443�� cert=/usr/local/squid/etc/cert1.pem defaultsite=site1.com
https_port ip_squid_2:443�� cert=/usr/local/squid/etc/cer2.pem defaultsite=site2.com

cache_peer ip_server_1 parent 443 0 no-query originserver proxy-only login=PASS ssl sslcert=/usr/local/squid/etc/cert1.pem sslflags=DONT_VERIFY_PEER nam
e=server1
cache_peer ip_server_2 parent 443 0 no-query originserver login=PASS ssl sslcert=/usr/local/squid/etc/cert2.pem sslflags=DON'T_VERIFY_PEER name=server2

acl DMZ dst ip_net_dmz
acl Site1 dstdomain .site1.com

cache_peer_access server1 allow Site1

never_direct allow DMZ

As you can see, the cache_peer server2 is not used (no cache_peer_access exists).
However, when accesing the the site1.com, the following could be seen in access.log:

1168861138.061��� 140 client_ip TCP_MISS/200 550 POST https://site1.com/path/to/app.swe - FIRST_UP_PARENT/ip_server_1 text/html
1168861138.124���� 28 client_ip TCP_MISS/404 1875 GET https://site1.com/path/to/app.swe? - ANY_PARENT/ip_server_2 text/html

How is this possible? It actually happened with two different sites published through the proxy, and always the requests were forwarded to the server2.
The proxy is used to publish a lot of sites and I haven't bee able to figure out why the requests of these two were forwarded to this server.

Could it have something to do with the defaultsite=site2.com that doesn't have an acl?

I fixed it by removing the cache_peer for server2, as it wasn't used anyway. After that all the requests goes to the right cache_peer.

Kind regards,

Tuukka
Received on Fri Jan 19 2007 - 04:07:35 MST