How do I check whether a Windows proxy affects my server tests?
Different Windows applications can use different proxy mechanisms. Inspect the proxy settings relevant to the failing client instead of assuming that a working browser proves every command-line tool has the same route.
Instructions
1. Inspect WinHTTP settings
This is a read-only view of one Windows HTTP stack’s configuration.
netsh winhttp show proxyThe output describes WinHTTP proxy settings. It does not necessarily describe your browser, curl environment or OpenSSH configuration.
2. Inspect the actual client path
For SSH, review whether a host alias defines ProxyJump or ProxyCommand. For HTTPS, compare the client’s documented proxy settings and the organisation’s approved configuration.
ssh -G example-server | Select-String -Pattern "^proxyjump |^proxycommand |^hostname "This reads effective SSH connection routing without contacting the server. Treat any internal proxy names as private.
3. Resolve a specific mismatch with the network policy owner
If the command-line client is required to use a managed proxy or VPN, configure that client through the approved mechanism. Do not reset all Windows proxy settings or bypass access controls merely to make a single test succeed.
Check the result
- The diagnostic client uses the intended approved route.
- The service test succeeds with the same identity and certificate protections as normal use.
Troubleshooting
- Browser access works but SSH fails
- An HTTP proxy can serve browser traffic without permitting direct SSH. Check the approved SSH access path.
- WinHTTP reports direct access but curl uses a proxy
- curl can read its own configuration or environment settings; inspect those privately without exposing credentials.
Official references
Use the documentation for your installed version when a flag, service name or platform feature differs.