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

  • Did you get anywhere with this. I am having exactly the same problem. I am severely tempted to blame IE as firefox autodetects beautifully, however, IE fails to detect and choose the default root out! – Kip Sep 2 '09 at 14:35
  • I didn't. I ended up having to specify a value for "use automatic configuration script." It is exasperating because all the literature says what I have done is correct. However, using the suggestions given here (eg use WireShark to see what's happening, check IIS logs, etc) I am certain IE is just simply not seeking to open wpad/wpad.dat at all even though all documentation says it should! – David M Williams Sep 4 '09 at 12:16
  • For me, it was due to multiple interfaces, and IE picking the VirtualBox hostonly adapter when calling the WPAD myIpAddress(). See also serverfault.com/a/425966/11594 – Chris J Mar 6 '15 at 14:51

11 Answers 11



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

| improve this answer | |
  • I'm seeing this same issue Matto. We're hosting the wpad.dat on a server which hosts other websites so we used IIS binding with host headers wpad and wpad.our.domain to serve up the proxy config file. When our DNS was a CNAME wpad to the true fqdn.our.domain then Firefox would work but Internet Explorer / WinHttp Client would fail due to HTTP request against FQDN - it's being too smart and seeing the CNAME then redirecting to request directly the name from A record. Switch to direct A record for "wpad" fixed WinHTTP/IE! – Mister_Tom Jun 20 '17 at 22:28

Another method of resolving this for IE8 (may work for IE7 too) is to change a couple of settings in Group Policy.

  • Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Make proxy settings per-machine (rather than per-user) = Enabled
  • User Configuration > Administrative Templates > Windows Components > Internet Explorer > Disable caching of Auto-Proxy scripts = Enabled

With the above 2 settings modified, I was able to get WPAD settings to work in IE8.

NOTE: You dont need to be in a domain environment to use this. On a workgroup PC, simply use GPEDIT.MSC to change the local computer policy.

See: How to disable automatic proxy caching in Internet Explorer

Regards, Kym

| improve this answer | |

This serverfault question appears high in google searches which is why I am replying to it. I hope others find this useful as this problem was a real pain for me.

Almost every Windows 7 computer on our domain of about 50 users was affected - going around and resetting IE was not acceptable as far as I was concerned so I eventually resolved it as follows:

Firstly here are a couple of useful but very hard to find links I came across:




I would suggest you read each of the links first.

The following quote from the fist link is particularly interesting:

"It turns out that those smart guys at Microsoft have implemented a feature to stop checking for a WPAD server after a few failed attempts. It reckons it knows which network a roaming machine is on, leaves a note for itself in the registry if it’s not going to bother looking again. A fat lot of use if you’ve only just implemented it."

I found the wpad reg key noted in the links, which is actually how I found the links in google. I got ruthless during testing and found that the following works:

Close all IE sessions, Open Control Panel -> Internet Options -> Connections Tab -> Lan Settings and un-tick "Automatically Detect Settings" (and all other options) - DO NOT OPEN IE AGAIN.

Delete the following reg key:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad

Open Control Panel -> Internet Options -> Connections Tab -> Lan Settings and TICK "Automatically Detect Settings".

If you refresh your regedit window (F5) you should see the wpad reg key re-created but it will be empty.

Now open IE. Refresh the wpad reg again and you should see it populate with a subkey containing various wpad info.

This was a fix without having to reset IE but I still needed to deploy it across 50 machines somehow. I did that as follows:

I created the following reg by using a computer I had reset as above (do not copy this verbatim as it was created based on our domain and I edited the domain name), the wpadOverride line was manaully added:

Windows Registry Editor Version 5.00

[-HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\a4-0c-c3-62-7b-2d]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{F03DC3BF-50F6-4DB1-9570-CF84875F6EDC}]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Wpad\{F03DC3BF-50F6-4DB1-9570-CF84875F6EDC}\a4-0c-c3-62-7b-2d]

This was added to user login scripts and basically deletes the reg key and replaces it.

I then created a GPO to disable "Automatically Detect Settings" and manually added the wpad url:

User Configuration -> Policies -> Windows Settings -> Internet Explorer Maintenance -> Connection -> Automatic Browser Configuration | Un-tick "Automatically Detect Configuration Settings" and Tick "Enable Automatic Configuration" and insert "http://wpad.example.local/wpad.dat" into "Automatic Configuration URL".

I also enabled the "IE WPAD Decision Caching Override" (see the second link above).

I then left this for a few days to deploy to as many computers as possible then disabled the "Automatic Configuration URL" and ticked "Automatically Detect Configuration Settings" again and removed the reg key from the login script.

I did this as it did not appear to work by simply unticking and then ticking the "Automatically Detect Configuration Settings" box via GPO so the addition of the URL may not be ultimately necessary.

I had hoped the WpadOverride would work without the extra steps but unfortunately it didn't in my case.

Incidentally using a cname works perfectly well on our network.

Any computers that were off for the duration of the fix were just handled manually after that.

I hope this helps other who come across this question like I did via google. This "feature" by Microsoft is just downright stupid.

| improve this answer | |

I had the exact same issue but only for a few computers...

Wireshark showed that IE doesn't attempt anything on the network before hitting the target web server. The web server that is set to host wpad responds to any hostname on that particular IP address.

I got the non-working IE8 clients to download wpad.dat again by doing this:

  1. Tools->Internet Options->Advanced->Reset
  2. Closed IE and re-opened it

Unfortunately, after making modifications to the wpad.dat file it is apparent that IE8 after the first download of wpad.dat doesn't do any further downloads :-(

| improve this answer | |

Another thing to look out for is detailed in the following URL: https://technet.microsoft.com/en-au/library/cc995158.aspx

DNS may have a block list enabled of which wpad is defined as a blocked record, this is a protective measure.

| improve this answer | |

Try running wireshark on a client machine... see where IE is looking? Does your webserver log that it has served any wpads?

| improve this answer | |
  • Thanks for the Wireshark suggestion. It gave interesting, but surprising, results. Although 'Automatically detect settings' checked IE did not refer to wpad once. There were no DNS lookups to resolve the name wpad with any suffix. When I put in a manual entry for 'use automtic configuration script' I can see nslookups being performed on wpad. So, it seems IE is not actually trying to find the auto-configure file at all ! – David M Williams Aug 15 '09 at 15:40
  • 1
    Make sure option 252 on your DHCP isn't set to "" or similar - that may be causing a confusion. Also wpad may not work if you don't have the local domain set up. – Tom Newton Aug 17 '09 at 8:24

Internet Explorer will attempt to access "http://wpad.your-machine's-dns-suffix.com/wpad.dat". Make sure the web server that's configured to serve the wpad.dat file is answering for the fully-qualified hostname. (BTW, IE will decompose the DNS suffix trying each parent domain, too. Have a look at http://wpad.com. The guy that owns that domain could've been really, really evil if he'd wanted to...)

| improve this answer | |

IE Version 6.0.2900.xxxx looks for the filename "wpad.da" instead of "wpad.dat" BE CAREFUL! ;) Just use a sniffer or check your webserver logs.

Hope this helps!

| improve this answer | |

As Tom Newton suggest run wireshark to see what IE is doing (DNS query, HTTP GET, ...), also look at your webserver logs.
Take care that IE send the IP instead of the Host name (wpad) as 'Host' in the GET query so that you can't use a virtualhost 'wpad' on the webserver.

| improve this answer | |
  • This second point is interesting; if what you say is true then that's most likely the problem. I didn't want wpad.dat in the root of the main web site so I made a new directory and virtual host for the wpad 'web site' so to speak. However, if IE is auto-looking for instead of wpad.domain.local/wpad.dat then that will be the problem. I'll try this first ... – David M Williams Aug 15 '09 at 15:00
  • Nope, that didn't work. I'm thinking that IE is just not doing anything despite the 'automatically detect settings' box being checked. – David M Williams Aug 17 '09 at 1:59
  • As, per comment on Tom answer, you did not see anything in wireshark, it may be a bug in the IE version (what version ?) or something in the windows configuration (Security Policy?, GPO?) that disable this. (but I have no idea of what settings it could be, it's just an idea) – radius Aug 17 '09 at 2:22

This method work for me

   1. Tools->Internet Options->Advanced->Reset
   2. Closed IE and re-opened it

I think IE8 make me confuse a lot , they from MS but why it work inproperly. While Firefox work very well.

| improve this answer | |

If you're using DHCP, then there is a setting (option 252, IIRC), for declaring the location of your wpad file. I believe you are incorrect about Firefox not being able to use this.

Additionally, do you have localdomain in the search list?

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.