MicrosoftHello Dave_Roth,
Does this align with the timing of your Microsoft article, and can you confirm whether you have made any changes regarding the handling of WPAD.dat via DNS?
We recently ran into a problem that may help others who are experiencing similar issues with WPAD and WinHTTP on Windows 11.
In our environment, WPAD via DNS continued to work in browsers (WinINET), but it stopped working for WinHTTP‑based system services. This affected:
Windows Update
Microsoft Defender (MAPS, cloud lookups, platform initialization)
OOBE / first‑boot processes
Licensing and attestation endpoints
Any service running under the SYSTEM account
The symptoms were always the same:
WinHTTP ignored WPAD
WinHTTP fell back to DIRECT
DIRECT traffic is blocked in our network
SYN retransmissions to Microsoft endpoints
Windows Update failures
Defender cloud failures
OOBE delays or failures
This happened suddenly, without any changes on our side.
Root Cause (Observed)
After analyzing network traces and system behavior, we found that Windows 11 applies much stricter rules to WPAD when used by WinHTTP (SYSTEM context). Specifically:
1. CNAME‑based WPAD is no longer trusted
Our WPAD record looked like this:
Code
http://wpad.xxx.de/ → CNAME http://www1.xxx.de/→ A 172.xx.xx.xx
Browsers still accept this, but WinHTTP now rejects it.
2. Domain mismatches cause WPAD to be discarded
If the WPAD host resolves outside the client’s primary DNS suffix, WinHTTP treats it as untrusted.
3. PAC parsing is now sandboxed
WinHTTP executes PAC files inside an AppContainer with restricted APIs.
Functions like myIpAddress() or DNS‑dependent logic can fail silently.
4. When WPAD fails, WinHTTP always falls back to DIRECT
This fallback is silent and unavoidable.
In enterprise networks, DIRECT is blocked → SYN retransmissions.
5. Defender platform updates increased dependency on early proxy availability
Recent Defender platform versions require:
cloud access during first boot
a valid PAC file
a working WinHTTP proxy configuration
If WPAD fails, Defender enters a degraded state.
Solutions That Worked for Us
✔ 1. Enforce the PAC file via Group Policy
We enabled:
“Define proxy auto-config (.pac) for connecting to the network”
with:
Code
http://wpad.xxx.de/wpad.dat
This forces WinHTTP to load the PAC file directly, bypassing WPAD trust restrictions.
Result:
WinHTTP uses the proxy again; no DIRECT fallback.
✔ 2. Embed the Defender Platform Engine into the OS image
By integrating the Defender platform version into the image, the system no longer needs to download it during OOBE.
Result:
Defender initializes correctly without requiring early WinHTTP proxy access.
✔ 3. Set the WinHTTP proxy manually after WinPE
Using:
Code
netsh winhttp set proxy <proxy:port>
This ensures WinHTTP uses the proxy regardless of WPAD behavior.
Result:
All system services operate correctly; no SYN retransmissions.
