strange things with disabled web proxy autodiscovery

Question

I'm using proxy server for Internet and Windows 10/11 clients are in Microsoft domain.

Proxy settings of system configuration is set with only one of these options:

1. "Automatically detect settings" to ON
2. "use setup script"

First option uses web proxy auto-discovery protocol so It searches automatically this file "http://wpad.<mydomain.it>/wpad.dat" which is hosted on my web server.

Second option is referencing the same script "http://wpad.<mydomain.it>/wpad.dat"

Now I turned off proxy server service and my network connection is direct without proxy so I disabled all 3 options of proxy server of current user on each client:

1. "Automatically detect settings" to OFF
2. "use setup script" to OFF
3. "use a proxy server" to OFF

I noted major part of traffic go directly but a minor part of request pass through proxy server, e.g. www.msftconnecttest.com or some windows update sites

I don't understand what happens, I think Windows 10/11 have others references to this wpad.dat file but it's normal behaviour ? What other configuration I can change ?

I used only 3 settings which I previously shown.

Answer 1

Hi WilliamDaveo,

You are very close to the correct conclusion, but the technical "why" is slightly different.

To answer your specific question: No, system components do not "fallback" to the user-level configuration. However, Yes, they will go direct to the Internet.

Here is exactly what happens when you remove the wpad DNS record: The WinHTTP Web Proxy Auto-Discovery Service attempts to find the PAC file via DHCP (Option 252) and then DNS (wpad.yourdomain.it). Since you disabled DHCP and removed the DNS record, both attempts will fail (timeout or "Name Not Resolved"). When the auto-discovery process fails to find a PAC file, the WinHTTP stack does not look at the logged-in user's settings (the "User-level" config). Instead, it reverts to its own default state. The default state for WinHTTP (when netsh is empty and WPAD fails) is Direct Access. The traffic is simply handed to the TCP/IP stack to be routed out via the Default Gateway.

So, the result is exactly what you want, the traffic goes directly to the Internet, but it does so because "Direct" is the fail-safe default, not because it is reading your user's "OFF" settings.

Simply deleting the DNS record might not stop the proxy traffic immediately due to caching. You need to perform these specific steps to ensure the clients realize the WPAD file is gone:

1. Remove the DNS Record: Delete the A or CNAME record for wpad on your internal DNS servers.
2. Flush DNS on Clients: Run ipconfig /flushdns on the client.
3. Restart the WinHTTP Service (Reboot recommended): The WinHTTP AutoProxy service caches the result of the discovery process (even the success of finding the WPAD file). It will not query DNS again until its internal Time-To-Live (TTL) expires or the network state changes. Immediate Test: To test without rebooting, you can restart the "IP Helper" service and the "Network Location Awareness" service, but a full reboot is the only way to guarantee the WinHttpAutoProxySvc clears its memory.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer then. Should you have more questions, feel free to leave a message. Have a nice day!

VPHAN

Answer 2

The behavior you are observing confirms that while static user-level and system-level proxies are disabled, the WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc) is still active and successfully locating your WPAD file via DNS or DHCP. The command netsh winhttp show proxy only displays statically configured system proxies; it does not report on dynamically discovered proxies via WPAD. The traffic you are seeing, specifically Certificate Trust Lists (CTL) from ctldl.windowsupdate.com, connectivity checks (msftconnecttest or ipv6.msftncsi.com), and telemetry, originates from system components (CryptoAPI and NCSI) that invoke the WinHTTP AutoProxy service directly. This service runs under LocalService or LocalSystem and typically ignores the user's specific toggle for "Automatically detect settings" if the underlying network infrastructure (DNS A record for wpad or DHCP Option 252) explicitly advertises a proxy configuration script.

To definitively stop this traffic, you must attack the discovery mechanism at the source rather than just the client configuration. As long as wpad.<mydomain.it> resolves in your internal DNS or your DHCP servers are broadcasting Option 252, Windows system services will attempt to utilize that PAC file for critical OS functions to ensure connectivity. You should remove the wpad DNS record and the DHCP Option 252 scope immediately. Once the network advertisement is removed, you must clear the client-side cache. Windows caches the compiled PAC file and the result of the auto-discovery process. Flush the DNS cache using ipconfig /flushdns and, more importantly, reboot the client to force the WinHttpAutoProxySvc to discard its memory-resident cache of the wpad.dat file.

If you can't immediately change DNS/DHCP infrastructure, you must modify the registry to forcibly disable WPAD for the WinHTTP service specifically, which is distinct from the WinINet (IE/Edge) settings you changed in the GUI. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp and create or modify a DWORD value named DisableWpad. Set its value to 1. This registry key explicitly tells the system-level HTTP stack to ignore WPAD protocols regardless of what the network is broadcasting. Additionally, verify that HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet\ManualProxies is empty, as the Network Location Awareness service can sometimes latch onto residual configurations.

Answer 3

Good moring VPHAN,

I followed your suggestions, I run Powershell with both administrator and user rights where I typed:

netsh winhttp show proxy

There is set no proxy in both cases.

I took a sample WIndows 10 client, currently I see these accesses to proxy server:

• http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/pinrulesstl.cab
• http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab
• CONNECT settings-win.data.microsoft.com:443
• http://go.microsoft.com/fwlink/
• CONNECT login.live.com:443

All other Internet traffic goes directly with no proxy server.

Answer 4

Good morning WilliamDaveo,

Windows operates with two distinct proxy stacks: WinINet and WinHTTP. The settings you disabled in the GUI affect WinINet, which governs user-level applications like browsers. However, system services like Windows Update and the Network Connectivity Status Indicator (which pings msftconnecttest.com) operate under the Local System account and use the WinHTTP stack. WinHTTP does not automatically synchronize with the GUI settings when you disable them; it retains the last configuration it was given until explicitly reset. This means your system services are still acting on old instructions even though your user interface says everything is off.

To resolve this, you need to manually clear the proxy configuration for the system scope. Open a Command Prompt as Administrator and type netsh winhttp show proxy. You will likely see your old proxy settings defined there. To remove them, run the command netsh winhttp reset proxy. This will clear the persistent system-level configuration and force those background services to connect directly, aligning them with the changes you already made in the Settings app.

Answer 5

When you disable the proxy settings on your Windows 10/11 clients, the expected behavior is that all traffic should bypass the proxy server. However, there are a few reasons why you might still see some traffic being routed through the proxy:

1. System Services and Applications: Some Windows services and applications may have their own proxy settings that are independent of the user settings. For example, Windows Update and certain system services might still attempt to use the proxy if they were configured to do so previously.
2. DNS Resolution: Even if the proxy settings are disabled, certain applications might still resolve the WPAD name through DNS, leading to unexpected behavior. This can occur if applications are not fully respecting the system proxy settings.
3. Group Policy Settings: If your clients are part of a Microsoft domain, there may be Group Policy Objects (GPOs) that enforce proxy settings. These GPOs can override local settings, causing some traffic to still route through the proxy.
4. Cached Settings: Sometimes, settings may be cached, and it may take time for changes to propagate fully across the system. A restart or a refresh of the network settings may be required.

To further troubleshoot and ensure that all traffic bypasses the proxy:

• Check for any Group Policy settings related to proxy configurations that might be applied to the clients.
• Review the settings of specific applications that may have their own proxy configurations.
• Consider using tools like netsh to view and configure proxy settings at a more granular level.

If you want to ensure that all traffic is routed directly, you may need to investigate these areas further.

---

References:

• How to disable HTTP proxy features
• Configure device proxy and internet connection settings for Information Protection