Skip to content
WindowsDeep Dive Published Updated 5 min readViews unavailable

WinHTTP Proxy Configuration: Scope, PAC, and Service Diagnostics

Separate WinHTTP from browser proxy state, inspect user and machine scopes, configure advanced proxy settings, and trace service-side connectivity failures safely.

“The browser can reach the site” does not prove a Windows service can. WinHTTP is an API used by applications and system components to make HTTP requests; it has proxy configuration and authentication behavior distinct from the interactive browser stack. A service runs under its own identity and session, and may not inherit the signed-in user’s PAC, bypass list, credentials, or per-user settings. Diagnose the application’s networking stack and account context before changing machine-wide proxy configuration.

Current netsh winhttp commands can inspect and manage WinHTTP settings. The older set proxy and show proxy forms are deprecated in favor of advanced proxy commands. Advanced settings support user or machine scope and include proxy, bypass, auto-configuration URL, and auto-detection properties. SOCKS5 is not supported by the documented advanced setting. Importing browser settings is a specific compatibility operation; it does not make WinHTTP dynamically identical to every browser’s configuration behavior.

Record the current state before making changes

Capture the effective WinHTTP configuration and save a configuration dump before editing it. Verify the scope of the setting and which Windows account runs the failing process. A system service can behave differently from an administrator’s interactive console even on the same host. Record the application, destination URL, timestamp, TLS result, DNS result, proxy identity, and HTTP status without capturing credentials or authorization headers.

$case = Join-Path $env:TEMP ("winhttp-proxy-{0:yyyyMMdd-HHmmss}" -f (Get-Date))
New-Item -ItemType Directory -Path $case -Force | Out-Null

netsh winhttp show advproxy 2>&1 |
    Out-File -LiteralPath (Join-Path $case 'advproxy.txt') -Encoding utf8
if ($LASTEXITCODE -ne 0) { throw "Unable to inspect WinHTTP proxy state." }

netsh winhttp dump 2>&1 |
    Out-File -LiteralPath (Join-Path $case 'winhttp-dump.txt') -Encoding utf8
if ($LASTEXITCODE -ne 0) { throw "Unable to export WinHTTP configuration." }

Get-FileHash -LiteralPath (Join-Path $case 'winhttp-dump.txt') -Algorithm SHA256

The dump is a recovery aid, not a secret-free artifact; review it before sharing. Machine-scope changes commonly require elevation and can affect unrelated services. Coordinate such changes through the normal configuration-management channel instead of improvising on a production server.

Configure only the intended scope

The set advproxy command accepts a JSON object with the documented Proxy, ProxyBypass, AutoconfigUrl, and AutoDetect properties. The following shape demonstrates a machine-level proxy with a PAC URL. Replace example hosts with approved organization values and confirm the expected behavior with the application owner. Avoid simultaneously enabling several discovery methods unless the design calls for it; ambiguous policy complicates incident analysis.

$settings = '{"Proxy":"proxy.example.net:8080",' +
            '"ProxyBypass":"*.internal.example.net",' +
            '"AutoconfigUrl":"https://config.example.net/proxy.pac",' +
            '"AutoDetect":false}'
netsh winhttp set advproxy setting-scope=machine settings=$settings
if ($LASTEXITCODE -ne 0) { throw "WinHTTP proxy configuration failed." }

netsh winhttp show advproxy
if ($LASTEXITCODE -ne 0) { throw "Could not verify the resulting WinHTTP settings." }

This is a configuration example, not a universal policy. Test PAC reachability, proxy DNS resolution, certificate trust, bypass matching, and the application’s use of WinHTTP. Do not put proxy credentials in command history or plain-text scripts. Use the enterprise’s supported authentication method and credential protection.

WinHTTP proxy settings are not a firewall rule and do not establish that the proxy is reachable. A DIRECT result may be intentional for a particular service; resetting proxy to direct can also bypass required egress controls. Preserve the before-state and confirm the authorized route before using netsh winhttp reset proxy as a diagnostic.

Distinguish configuration from application behavior

Applications can set proxy behavior on a WinHTTP session or override it on a request. They may query current-user settings only when running under an appropriate user account; a LocalSystem service cannot simply assume the interactive user’s profile is available. Some apps use WinINet, .NET networking, a third-party HTTP stack, or an explicit proxy configuration instead. Consequently, a successful netsh winhttp show advproxy proves what WinHTTP reports at that scope, not which proxy a particular process actually selected.

Collect a failing request with process identity and application logs first. Then compare a controlled request made by the same account using the same stack. PowerShell Invoke-WebRequest or curl.exe can help test DNS and TLS but may not exercise the application’s precise WinHTTP session settings. The most direct evidence is an application-side diagnostic or ETW trace that records proxy resolution and connection errors while redacting secrets.

Use tracing briefly and clean up

WinHTTP tracing can write verbose information to a file or debugger. Restrict duration and access because traces may contain request destinations and diagnostic details. Record the trace configuration before starting, reproduce one failed operation, stop tracing immediately, and reset tracing settings afterward. The separate netsh trace scenarios can collect broader network activity but create a larger evidence set; use them only when the narrower WinHTTP trace cannot answer the question.

After any change, rerun the same request under the same service identity and compare connection outcome, selected route, latency, and application response. Preserve the configuration diff and rollback command. If a host is managed by Group Policy or another configuration service, check for policy reapplication before assuming a manual setting will persist.

Proxy diagnosis is an identity-and-stack problem as much as a settings problem. Distinguishing WinHTTP from browser behavior, user scope from machine scope, and application overrides from system configuration avoids broad changes that fix one process while breaking another.

Related:

Sources:

Comments