Deleting Hidden Proxy Settings that Break Windows Apps

Ever disabled proxy settings in Windows only to find that some apps still can't connect to the internet? You're not alone. Windows has a sneaky habit of leaving behind hidden proxy configurations that continue to interfere with network connections long after you've "turned off" proxy settings through the GUI. This isn't just an annoyance—it's a design flaw that can break everything from Windows Store apps to enterprise software.

In my case, my first experience with this problem was after installing and uninstalling Fiddler Everywhere. Through my work at Devolutions, I had been pulling my hair out wondering why KDC proxying was broken. Using Process Monitor, I could see failed connections from lsass.exe going to a localhost proxy that was no longer there.

In this post, I'll show you how to identify these phantom proxy settings and completely eliminate them from your system.

Enable and Disable Proxy Settings

Follow these steps to enable and disable proxy settings in Windows, which is sufficient to reproduce the problem. Don't worry, I will show you how to remove the hidden proxy settings after:

1. Open Windows Settings - Press Win + I
2. Navigate to Network & Internet → Proxy
3. Turn on proxy settings:
   • Toggle "Use a proxy server" to On
   • Enter any proxy server information
   • Click Save
4. Turn off proxy settings:
   • Toggle "Use a proxy server" to Off
   • Click Save

Beware that if you leave bogus proxy settings enabled, you will experience networking issues.

Hidden Proxy Settings: The Real Problem

Here's where things get ugly. Windows automatically creates additional proxy settings that the GUI never shows you and never cleans up. These phantom settings live under:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iphlpsvc\Parameters\ProxyMgr

Let's expose these hidden configurations:

PS> Get-ChildItem "HKLM:\SYSTEM\CurrentControlSet\Services\iphlpsvc\Parameters\ProxyMgr" | Format-Table -AutoSize

Name                                   Property
----                                   --------
{6A42EAA0-3831-4006-8F95-7A6C372D26B1} StaticProxy : http://proxy-server:808
                                       LastUseTime : 133985369088357795
{9A02AD85-8292-4B3D-B9D0-36AAB45B42E9} StaticProxy : http://proxy-server:808
                                       LastUseTime : 133985369088357795
{C9A5E798-F5DF-460F-8AEE-837A463CBC27} StaticProxy : http://proxy-server:808
                                       LastUseTime : 133985369088357795

Unlike Internet Settings, ProxyMgr entries don't have a ProxyEnable registry key, and since they are stored under HKEY_LOCAL_MACHINE, they affect the entire system, not just the current user.

From an elevated PowerShell terminal, remove the ProxyMgr registry keys:

Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\iphlpsvc\Parameters\ProxyMgr" -Recurse -ErrorAction SilentlyContinue

If you have already tried everything to disable proxy settings that were mysteriously still used by some applications, this is the command that will finally fix things.

Internet Proxy Settings

The proxy settings for the current user are stored under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings:

You can also inspect them through PowerShell:

PS> Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

ProxyEnable ProxyServer             ProxyOverride AutoConfigURL
----------- -----------             ------------- -------------
          0 http://proxy-server:808

These settings are also often called the "Internet Explorer" proxy settings. This is what the Windows Settings app lets you see.

Testing .NET Proxy Detection

In .NET, applications dynamically detect proxy settings based on the target URL. You can easily test this behavior using some PowerShell:

function Test-ProxyConnection {
    param([string]$Url = "http://example.com")
    
    $proxy = [System.Net.WebRequest]::GetSystemWebProxy()
    $proxyUri = $proxy.GetProxy($Url)
    $isBypassed = $proxy.IsBypassed([System.Uri]$Url)
    $isDirectConnection = $isBypassed -or !$proxyUri -or ($proxyUri.ToString() -eq $Url)
    
    if ($isDirectConnection) {
        Write-Host "Direct connection (no proxy)"
    } else {
        Write-Host "Using proxy: $proxyUri"
    }
}
PS > Test-ProxyConnection "http://example.com" # with proxy disabled
Direct connection (no proxy)
PS > Test-ProxyConnection "http://example.com" # with proxy enabled
Using proxy: http://proxy-server:808/

This is a good code snippet to have at hand, because I once investigated a weird customer issue where complex proxy resolution logic was not the same between .NET Framework (Windows PowerShell) and .NET Core (PowerShell 7).

WinHTTP Proxy Settings

WinHTTP maintains a completely separate proxy configuration from Internet Settings. This separation is by design—WinHTTP is used by system services and applications that need more control over networking. You can inspect those settings using the netsh winhttp show proxy command:

PS> netsh winhttp show proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

While the Settings app doesn't modify the WinHTTP proxy settings, the ProxyMgr registry keys can affect system components using WinHTTP, such as KDC proxying in lsass.exe. Yes, this means that simply enabling and disabling bogus proxy settings from your unelevated user context can result in broken Kerberos with an NTLM downgrade. If you have malicious intent, this is also a good way to redirect KDC proxying traffic somewhere else without elevated permissions.

You can manually configure WinHTTP proxy settings (requires elevated privileges):

PS> netsh winhttp set proxy proxy-server:8080

Current WinHTTP proxy settings:

    Proxy Server(s) :  proxy-server:8080
    Bypass List     :  (none)

You can then remove WinHTTP proxy settings using netsh winhttp reset proxy:

PS> netsh winhttp reset proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

Broken Glass

Which broken parts of Windows are involved here? I did spend some time identifying the system component responsible for creating the ProxyMgr registry settings.

httpprxym.dll hosts an RPC server in a system service, with 3 relevant functions:

• ProxyMgrConfigReadConfigCacheEntry
• ProxyMgrConfigWriteConfigCacheEntry
• ProxyMgrConfigDeleteConfigCacheEntry

Here's the critical issue: ProxyMgrConfigDeleteConfigCacheEntry is never called by the Windows Settings app. The GUI only "disables" proxy settings by modifying user-level registry entries, but it never actually deletes the system-wide ProxyMgr cache entries.

If there's a documented Windows API or GUI method to properly clear these phantom proxy settings, I'm not aware of it and could not find it—manual registry deletion appears to be the only reliable solution.

Conclusion

Windows proxy management has a fundamental design flaw that creates persistent networking issues long after you think you've disabled proxy settings. The root cause is simple: when you enable proxy settings, Windows creates per-interface configurations in both user (HKCU) and system (HKLM) registry locations, but when you disable them, only the user-level settings get cleared.

This leaves behind hidden ProxyMgr registry entries that continue affecting system services and applications. The most concerning impact is on WinHTTP-based components like the Kerberos KDC proxying client in lsass.exe, where a simple proxy configuration mistake can break enterprise authentication and force NTLM downgrades—all from an unprivileged user context.