>From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] >Sven Edge wrote: >>> From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] >>> >> I think that's what I'm trying, and it fails to find a web server to >> talk to. > >Hmm, you can do a spot-check on squid with > "squidclient mgr:ipcache | grep www.scran.ac.uk" It's definitely doing the lookup and caching the right destination IP addresses. >> 2008/02/19 10:14:30| fwdStart: 'http://www.scran.ac.uk/' >> 2008/02/19 10:14:30| storeLockObject: key >> 'B13D9EB5D8D657257342FBE9C74C77D8' count=3 >> 2008/02/19 10:14:30| peerSelect: http://www.scran.ac.uk/ >> 2008/02/19 10:14:30| storeLockObject: key >> 'B13D9EB5D8D657257342FBE9C74C77D8' count=4 >> 2008/02/19 10:14:30| cbdataLock: 0xdc6968 >> 2008/02/19 10:14:30| peerSelectFoo: 'GET www.scran.ac.uk' >> 2008/02/19 10:14:30| peerSelectFoo: direct = DIRECT_NO > >Looks like possibly a never_direct or a deny ACL getting in the way. Turning up debug_options, it happily gets past the ACL stuff, including a destination check on a correctly-resolved web server ip address, spits out a "The request GET ... is ALLOWED, because..." message, and then does peerSelect stuff and dies. Poking around the source for the squid-2.6.STABLE17 release currently in Fedora, there's appears to be another source of DIRECT_NO besides a never_direct, in peer_select.c. http://www.squid-cache.org/cgi-bin/cvsweb.cgi/squid/src/peer_select.c I've got version 1.131, where there's an "if (request->flags.accelerated)" that can cause a DIRECT_NO, but the most recent version 1.134 has changed that. Not sure what the code's testing for in either version, but from the commit comment it sounds like up to now 2.6 was deliberately blocking direct access when in accelerator mode. Maybe it's just a case of waiting for the next release? Sven
