On 30/10/2015 8:44 a.m., Patrick Blair - Peapod wrote: > Since then, everything has been working fine, apart from one site, > Facebook, not loading correctly. It varies based on the particular browser > accessing it, but some/most of the style sheets or content don't appear to > load correctly, resulting in a very mangled look. Running the developer > tools for each respective browser give us information that the connections > to the stylesheets or content are aborted. Most of this content is hosted > on fbcdn.net, which we've made sure is on our allowed domains list. > What is interesting is that the first object (or multiple ones) is > retrieved successfully through the proxy, but subsequent ones are denied. > Again, this appears to vary depending on browser/os combinations, with > Chrome on OSX and IE (on Windows) seeming to work the best. > > We are NOT running a Tproxy or any other sort of intercepting proxy, all > the clients are explicitly aware of the proxy's existence through a .pac > configuration file pushed out through Group Policy. > Are these https:// traffic arriving to the proxy in the form of CONNECT requests? Or regular http:// URLs arriving as GET method? Is a POST or PUT method request involved with the fetch or just prior? Is there an unusual port being used? Or an OPTIONS request happening for some reason? > I've tried disabling ssl_bump (which shouldn't be enabled anyway) for the > facebook domains, setting cache deny for those domains, and setting always > direct for those domains, none of which has had any effect. Nod. As long as you do not use "ssl-bump" on any http_port or https_port bumping will not happen. > > I've also tried reverting to a more "simple" config, even the exact config > that we were using on the "old" Squid that was working on Solaris, but that > too fails. I've also changed from using Squid 3.5.10 to the version > packaged by CentOS (squid-3.3.8-12.el7_0.x86_64), tried this with both > configurations to no avail. > > The only thing that has worked is setting up a "test" squid at our primary > datacenter, same configurations, but this one does work. We've checked and > verified that there are no custom routes or any other network > configurations that vary between the servers, only IP addresses. Both are > on unrestricted vlans that allow direct access to the internet. We are > checking with our networking team to see if there is any custom routing > that is in place on their end, but it's very doubtful that is the case. I'm also a bit suspicious in these situations that it might have something to do with the network IP-range the clients are on vs the uplink being used. Is it breaking only when Squid is in the "other" datacenter from the client(s) ? Is one datacenter IPv6-enabled but not the other ? You could possibly set "debug_options ALL,0 17,4" to track the Squid outbound message forwarding and see what appears to be going on when it is connecting out for that domain. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
