The Web Proxy Auto-Discovery Protocol (WPAD) is a method used by clients to locate a URL of a configuration file using DHCP and/or DNS discovery methods. Once detection and download of the configuration file is complete it can be executed to determine the proxy for a specified URL. WPAD is documented in an INTERNET-DRAFT which expired in December 1999, although it is still supported by all major browsers. In this article, I will give you some deep understanding regarding how IE detects WPAD, and how to resolve some of the WPAD problems for IE.
Internet Explorer goes down a list of predefined detection methods:
1. DHCP (252 option)
2. DNS A record query/queries
NOTE: Only applies when 'Automatically detect settings' in Internet Options -> connections -> Lan Connections is the only option checked.
Now, if DHCP is configured to provide the WPAD location, IE stops the detection and will make a GET request for the wpad.dat file and no further searching is done. This is true even if the DHCP 252 option is incorrect and a correct entry is configured as a DNS record. Please also be aware that IE still sends out the DNS query in this situation, even the DNS result won’t be adopted.
If the DHCP server does not provide the desired information, DNS is used. If, for example, the network name of the user's computer is pc.department.branch.example.com, the browser will try the following URLs in turn until it finds a proxy configuration file within the domain of the client:
If DNS is failed, a Netbios query for a machine named WPAD occurs.
When doing DHCP detection, IE tries to get the DHCP 252 option by calling DhcpRequestParams function. Based on MSDN article, DHCP clients store data obtained from a DHCP server in their local cache. If the DHCP client cache contains all data requested in the RecdParams array of a DhcpRequestParams function call, the client returns data from its cache. If requested data is not available in the client cache, the client processes the DhcpRequestParams function call by submitting a DHCP-INFORM message to the DHCP server.
So, DHCP-INFORM message is sent out only for the first time. The below is a sample of such a INFORM request/response.
55 10.0.0.101 255.255.255.255 DHCP DHCP:Request, MsgType = INFORM, TransactionID = 0x33276787
56 10.0.0.1 10.0.0.101 DHCP DHCP:Reply, MsgType = ACK, TransactionID = 0x33276787
Frame: Number = 56, Captured Frame Length = 371, MediaType = ETHERNET
- Dhcp: Reply, MsgType = ACK, TransactionID = 0x33276787
OpCode: Reply, 2(0x02)
HardwareAddressLength: 6 (0x6)
+ MessageType: ACK - Type 53
+ ServerIdentifier: 10.0.0.1 - Type 54
+ SubnetMask: 255.255.0.0 - Type 1
+ DomainName: ctest.local - Type 15
+ DomainNameServer: 10.0.0.1 - Type 6
+ WPAD: http://consto.ctest.local/wpad.dat - Type 252
For the next times, the 252 option is retrieved from DHCP local cache.
1. IE won’t do IPV6 DHCP detection, only supports IPV4.
2. IE tries to retrieve all Network interfaces’ DHCP settings.
As same as DHCP detection, DNS also has its own cache. This also means IE needn’t sends out DNS query every time.
After getting the URL of the wpad.dat file, IE will send a GET request to this URL to retrieve the wpad.dat file, this is a normal HTTP request just like you visiting a website from IE window. If the wpad.dat file is retrieved successfully, IE will cache the URL of the wpad.dat file into HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings. Also, the wpad.dat file will be cached in IE’s “Temporary Internet Files” folder if the HTTP response doesn’t contain any “Cache control” header. In most cases, such kinds of responses do not contain any “Cache control” header.
When IE starts the next time, it tries to retrieve the wpad.dat URL from registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings), and then tries to visit this URL. Please just wait a minute, IE does find the cached wpad.dat file from “Temporary Internet Files”, so it won’t really send out the HTTP request anymore.
Based on the above WPAD detection mechanism, we always encounter the below two issues with wpad.dat.
l We’ve updated the DHCP 252 option and pointed wpad.dat to another URL, or just changed the DNS entry and pointed to another web server, but IE never try to retrieve the wpad.dat file from the new URL.
As I mentioned before, IE always tries to retrieve the wpad.dat URL from registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings). If it exists, IE doesn’t need to do DHCP detection or DNS detection. If it doesn’t exist, IE still needn’t to send DHCP or DNS request every time because of the DHCP cache or DNS cache, so that IE may still get the old wpad.dat URL.
l We’ve modified the content of the wpad.dat file on the server, but IE still use the old content of the wpad.dat, even it doesn’t try to download the new wpad.dat file.
This is because the local cache in “Temporary Internet Files” folder. If the wpad.dat URL isn’t changed, IE won’t try to download wpad.dat file again if it is already cached in “Temporary Internet Files” folder, this is because of IE’s cache mechanism.
This also means IE won’t be aware of the modification of the wpad.dat file on your server.
If you are encountering the 1st problem, the only way is to clear all caches as below.
Clear DHCP cache
Clear DNS cache
Delete proxy cache from registry
Delete IE cache
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 8
If you are encountering the 2nd problem, we have two options as below.
l On the web server which hosts your wpad.dat file, add “Cache-Control” header for the wpad.dat response and set to “no-cache”. For example, the HTTP header could be like below.
For more details regarding Cache-Control in HTTP protocol, please refer to http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
l Clear IE’s cache folder(“Temporary Internet Files”) before starting IE
NOTE: To consider the browsing performance, the second option is preferred.
WPAD detection in Internet Explorer
Web Proxy Autodiscovery Protocol
Zhixing Lv from APGC DSI Team
Thanks for this, I've been banging my head against a wall trying to figure out why a new entry in WPAD was not working - added the no-cache option to the web server, cleared the temp internet files and now fine.
I'm so glad the article is helpful for you. Welcome back again if you have any IE related question in the future.
Thank you for your sharing. I am working on a WinINet application now. My machine is in the domain, and wpad is configurated, and "Automatically detect settings" is selected. I found for some urls, WinINet control doesn't get "INTERNET_STATUS_RESOLVING_NAME" and "INTERNET_STATUS_CONNECTING_TO_SERVER" message in InternetSetStatusCallback function. If I unselect the "Automatically detect settings", it is fine. Could you give some advice?