Internet Explorer isn’t auto-discovering http://wpad/wpad.dat auto-config

domain-name-systeminternet explorerPROXYproxy.pacwpad.dat

I am being driven to frustration by this problem.

I have set up a file called wpad.dat (essentially, a proxy.pac file renamed) and put it on an internal web site. I've set up DNS entries so host name wpad is a CNAME for the web server. I set the appropriate MIME type for .dat files on the web site. I removed wpad from the DNS global query block list.

I know the config file is syntactically correct because if I manually set Internet Explorer's "use automatic configuration script" to http://wpad/wpad.dat the proxy is clearly being used (ie, I see my browsing show up in log files plus certain sites I've denied come up with my replacement page.)

However, it is my understanding that all I should need to do is tick the box for "Automatically detect settings" and Internet Explorer should itself go look for http://wpad/wpad.dat – or, more correctly, http://wpad.localdomain/wpad.dat – which does also work.

Can anyone help me diagnose this problem? I just cannot see what I have missed or what is wrong.

Thank you !!

(Note, it is also possible to set the auto config file using DHCP, however we have a multi-site organisation with DHCP provided by a mixture of servers and routers depending on location as well as remote offices using 3G cellular modems which have very basic DHCP facilities. Plus, it is only Internet Explorer which allegedly supports web proxy auto discovery via DHCP – neither Firefox nor Safari do. We don't actually use either of those browsers but for the sake of maximum compatibility plus ease of future administration/changes I think it's surely better to get this working via a nice single DNS entry.)

Best Answer

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 :)