Mobile Proxy Configuration on Windows
Windows does not have one proxy setting — it has several, and they do not talk to each other. This guide covers which layer each application reads, how to configure all of them, and how to find out which one is being ignored.
- Two proxy stacks, not one — WinINET serves the Settings app and browsers; WinHTTP serves Windows services and much of the command line.
- The Settings page is not system-wide — it configures WinINET only, which is why a service can ignore a proxy Windows says is on.
- netsh reaches the other half — one command sets WinHTTP, and one more shows you what is actually configured.
- Some applications read neither — curl, git and npm follow environment variables and nothing else.
Windows already speaks HTTP(S) and SOCKS5 natively.
Settings, netsh, environment variables and per-app dialogs.
Windows Has Two Proxy Stacks, Not One
The reason Windows proxy configuration feels unreliable is that there is no single setting to get right. Windows ships two entirely separate HTTP stacks, each with its own proxy configuration, and neither one reads the other. Software picks whichever stack its developer used, and nothing tells you which that was.
WinINET is the older, user-facing stack. It backs the Settings app, Internet Explorer’s legacy dialog, Edge and Chrome. WinHTTP is the service-oriented stack, designed for software running without a logged-in user, and it backs Windows services and a good deal of background and enterprise software. Setting a proxy in Settings configures WinINET and leaves WinHTTP completely untouched.
| Layer | What reads it | Where you set it |
|---|---|---|
| WinINET | Edge, Chrome, most desktop applications, the Settings page itself | Settings, then Network and Internet, then Proxy |
| WinHTTP | Windows services, background updaters, a lot of enterprise software | netsh winhttp set proxy in an elevated terminal |
| Environment variables | curl, git, npm, pip, Python and most ported command-line tools | Per session, or permanently for your user account |
| Application settings | Firefox, many download managers, antidetect browsers | The application’s own proxy dialog |
Work out which row the failing application belongs to before you change anything. Setting the same credentials in the wrong layer three times is the usual shape of a wasted afternoon, and each attempt feels like it should have worked.
Setting the Proxy in Settings and in netsh
Start with the Settings page, because it covers browsers and most of what you will actually use. Open Settings, go to Network and Internet, then Proxy. Under manual proxy setup, turn on the toggle, enter your proxy host in the address field and the port in the port field, and save. The address field wants the host on its own — not a colon-delimited string, and not a URL with credentials in it.
Windows will prompt for the username and password the first time an application uses the proxy. If it does not prompt, and requests fail instead, that is the sign your proxy needs credentials the WinINET dialog is not offering to collect — configure that application directly instead.
netsh winhttp show proxy netsh winhttp set proxy proxy-server="http=proxy.example.net:8000;https=proxy.example.net:8000" netsh winhttp set proxy proxy-server="proxy.example.net:8000" bypass-list="<local>" netsh winhttp import proxy source=ie netsh winhttp reset proxy
The import line is worth knowing: it copies whatever is configured in the Settings page into WinHTTP, so you configure once and both stacks agree. It is a copy rather than a link, so running it again after changing the Settings page is necessary. The reset line clears WinHTTP back to direct, which is the first thing to try when a service that used to work stops.
WinHTTP configuration is machine scope, so the terminal must be elevated. The Settings page applies to your user account and needs no elevation at all.
Browsers, Terminals and Individual Applications
Edge and Chrome both follow WinINET, which means the Settings page configures them and there is nothing else to do. Firefox is the exception worth remembering: it ships its own proxy dialog under network settings, and while it defaults to following the system, anyone who has previously set it manually will find it stubbornly ignoring Windows until that dialog is changed back.
The command line is a different world. Tools ported from Unix — curl, git, npm, pip, and most Python code — read environment variables and nothing else. Windows has no equivalent of the Settings page for them.
:: Current session only (Command Prompt) set HTTP_PROXY=http://user123:[email protected]:8000 set HTTPS_PROXY=http://user123:[email protected]:8000 set NO_PROXY=localhost,127.0.0.1 :: Persist for your user account setx HTTP_PROXY "http://user123:[email protected]:8000" # PowerShell, current session only $env:HTTP_PROXY = "http://user123:[email protected]:8000" $env:HTTPS_PROXY = "http://user123:[email protected]:8000"
Note that HTTPS_PROXY still takes an http:// scheme. The scheme describes how to reach the proxy, not the protocol of the target — the client opens a tunnel through it and TLS runs end to end inside that tunnel. Writing https:// there is a common and confusing failure.
Setting these permanently with setx writes the password into your user environment, where any process you run can read it. On a shared or managed machine, prefer setting them per session, or ask your provider to whitelist the machine’s address so no credentials are needed at all. The setup overview covers that trade-off in more detail.
When Windows Says the Proxy Is On and Nothing Uses It
Almost every Windows proxy problem is a layer problem rather than a credentials problem. Before changing any setting, find out what the failing application actually sees.
| Symptom | Most likely cause |
|---|---|
| Browsers proxied, a Windows service is not | WinHTTP was never set. Run the import command, or set it explicitly. |
| curl or git returns the real IP | No environment variables. Neither Windows stack reaches these tools. |
| Repeated authentication prompts | Credentials being sent to the wrong port. HTTP and SOCKS5 are separate ports with separate logins. |
| Everything fails after a working setup | A stale WinHTTP entry pointing somewhere that no longer exists. Reset it and set it again. |
| Firefox alone ignores the proxy | Its own connection settings are set to manual or to no proxy. |
If you would rather confirm the endpoint in a browser than a terminal, the free PXM2 proxy checker tests it and reports the detected proxy type and exit country.
Get a Mobile Proxy for Windows
Live PXM2 locations — pick the country you need an exit IP in, and configure it with the steps on this page:
France
India
Singapore
Frequently Asked Questions
How do I set up a proxy on Windows 11?
Open Settings, go to Network and Internet, then Proxy, and under manual proxy setup enter the host and port and save. That covers Edge, Chrome and most desktop applications. It does not cover Windows services or command-line tools, which read a separate configuration you set with netsh.
What is the difference between the Windows proxy settings and netsh winhttp?
They configure two independent stacks. The Settings page writes the WinINET configuration used by browsers and ordinary desktop software. The netsh winhttp commands write the WinHTTP configuration used by Windows services and a good deal of background software. Setting one has no effect on the other, and this is the single most common reason a Windows proxy appears half-applied.
Why does my Windows proxy not work for some applications?
Because those applications read a configuration you did not set. Command-line tools such as curl, git and npm look at environment variables. Windows services look at WinHTTP. Firefox keeps its own proxy dialog. Each is independent of the Settings page, so the fix is to configure the layer the failing application actually reads rather than setting the same value again somewhere else.
How do I check which proxy Windows is using?
Run netsh winhttp show proxy in a terminal to see the WinHTTP configuration, and open Settings then Network and Internet then Proxy to see the WinINET one. Then make a request through the tool that is failing and compare its exit IP to your real address, because a configuration being present is not the same as the application using it.
Do I need admin rights to set a proxy on Windows?
Not for the Settings page, which applies to your own user account. You do need an elevated terminal for netsh winhttp set proxy, because WinHTTP configuration is machine scope. Environment variables can be set per user without elevation.
Related Mobile Proxy Guides
The same layered problem exists on every operating system, and the answer differs on each.
Setup guides
Core mobile proxy guides
Run Windows Behind a Real Carrier IP
Dedicated 4G/5G modems with unlimited bandwidth and unlimited rotations — HTTP(S) and SOCKS5 endpoints that Windows speaks natively, with no client to install.
Get a Mobile Proxy