Testing WPAD file locally with Internet Explorer 11

Here's a slightly modified WPAD.DAT I'm using at a Customer site. It's working fine on IE6, unmodified... (because they won't give me the go-ahead to upgrade to IE8). The only modifications I put in were to obscure the Customer's domain names.

function FindProxyForURL(url, host) {

  if ( isPlainHostName(host) ) { return "DIRECT"; }

  if ( shExpMatch(url, "https:*") ) { return "DIRECT"; }

  if ( shExpMatch(url,"http://*.customer.domain.com")) { return "DIRECT"; }

  if ( isInNet(host,"127.0.0.1", "255.255.255.255") ) { return "DIRECT"; }

  if ( isInNet(host,"10.35.0.0", "255.255.0.0") ) { return "DIRECT"; }

  if ( isInNet(host,"192.168.0.0", "255.255.0.0") ) { return "DIRECT"; }

  return "PROXY proxy.customer.domain.com:8080";
}

The only difference that I see is that you're not matching "http:" at the beginning, but that shouldn't matter.

You're not supposed to do it, but you can put alert() statements in and IE6 will display them. You may be able to get some traction in debugging by doing that.

David,

In case you're still hitting up against this problem, it's actually rather simple to fix. But it's not documented ANYWHERE, and it took me ages to sort it out in my environment. Everything you've done is good, and it's what I'd call a bug in how IE gets it's WPAD info and connects to the web server.

First of all, you can't use a CNAME record for WPAD. Use an A record. Silly, I know, and it shouldn't make any difference, but it's definitely the case. So remove your CNAME in your DNS, and make an A record for the IP Address of the web server.

Secondly (and this may be more tricky for you), you need to have the WPAD.DAT file located on the root of the default website that's listening on the IP Address that you've assigned above. This is the key. It WILL NOT work with a host-header field or anything like that.

Explanation: What IE does is resolve the name WPAD to an IP Address. It's got to be able to resolve it directly to an IP Address. If it resolves as a CNAME query does to a different name, it won't work. So once IE's got the IP address that WPAD resolves to, what it actually does is connect to http://<>/WPAD.dat. If you've got a different website set up on the same webserver, listening on port 80 but using a host header field like I had (IE, "default web site", as well as "WPAD Website"), then you'll have everything set up correctly, but it won't work for that very reason. Put a copy of your WPAD.DAT file on the root of your default website, and things should start working.

Of course, if you can't get access to the root of that website (or you can't secure the root of that website), then you may need to look at moving your WPAD site to a different server where it can be at the root of the IP Address assigned to that server.

Give that a shot anyway. That's the process that worked for me. It took me ages to get it working, but it's been reliably working now for a long time. All the above though is simply my understanding of how IE works in relation to WPAD.DAT files, and might not be correct - it's simply based on the observation of what it does in my own environment. Yours may be different, but I'd put some money at least on that fixing your issue.

Let me know how you get on! Matto :)