Proxy settings, Windows 10 and 11: the screen is in the same place on both, and it takes about twenty seconds to fill in. The part nobody mentions is that Windows keeps more than one proxy, and the one on that screen is not the one Windows Update reads.
That is the whole reason this page exists. Every guide on this query shows you the same Settings screen and stops. None of them tells you that the box you just ticked is a per-user setting, that services read a different one entirely, and that the command line tools on your machine read a third.
So: where the screen is, which store it writes, why Windows Update ignores it, the command that reads the other store, what Edge actually does, why SOCKS5 is not an option on any Windows screen, and how to turn the whole thing off in all three places rather than one.
Quick Answer: Proxy Settings on Windows
Proxy Settings, Windows 10 and 11: Where They Are and What They Write
Same path on both. Open Settings, choose Network & internet, then Proxy. Microsoft's own page for this is short enough to quote: under Automatic proxy setup, "turn on Automatically detect settings"; for a script, "next to Use setup script, select Set up"; and for a manual one, "next to Use a proxy server, select Set up", then enter the "Proxy IP address and Port".
Three blocks, three different things, and most of the confusion on this topic starts with people reaching for the wrong one. Microsoft's instructions for this screen are correct, but they run to about 670 words and stop inside the Settings app.
| Block on that screen | What it actually does | When you want it |
|---|---|---|
| Automatically detect settings | Asks the network for a script address over DHCP and DNS, using WPAD. Usually finds nothing at home | A corporate network that publishes one. Harmless otherwise |
| Use setup script | Downloads a PAC script from an address you paste and follows its rules | Somebody gave you a script address ending in .js, .pac or .dat |
| Manual proxy setup | One address, one port, one bypass list. No protocol field, no username field | Somebody gave you exactly those values |
If you arrived here because something asked you to configure a proxy and you are not sure what it wanted, the general version of that question is answered in what that Configure Proxy setting is asking for. And if you want the mechanism from the ground up rather than the Windows screen, our explanation of how a proxy server works and where it sits in a network covers it properly.
Filling that screen in is the easy part. The question worth asking is which proxy you just set.
Windows Keeps More Than One Proxy, and Only One Is on That Screen
The Windows proxy settings you just edited belong to WinINET, the networking stack the browsers and most desktop applications use, stored per user. There is a second one called WinHTTP, stored per machine, and it is the one built for services. They are separate values. Writing one does not write the other.
Microsoft is direct about the split. From its own WinINet versus WinHTTP comparison: "you should use WinINet unless you plan to run within a service or service-like process that requires impersonation and session isolation." In the feature table on that page, services support is listed as "no" for WinINet and "yes" for WinHTTP, which "can be run from a service or a service account". Microsoft's overview of WinHTTP spells out what that costs: "A number of WinINet features are not supported in WinHTTP, including URL caching and persistent cookies, autoproxy, autodialing, offline support, and File Transfer Protocol (FTP)." The two stacks are genuinely different software, not two names for one setting.
| Store | What writes it | What reads it |
|---|---|---|
| WinINET, per user | The Settings app · Control Panel, Internet Options, LAN settings | Edge, Chrome, and most applications you open by clicking something |
| WinHTTP, machine or user scope | netsh winhttp, from an elevated prompt | Services and background components, including Windows Update |
| Environment variables | setx, or your shell for the current session | curl, git, pip, npm, Docker, and most things you run by typing |
Two symptoms come out of this split and they look unrelated until you know about it. "I turned the proxy off and something is still using one" is usually the machine-level store still set. "I set the proxy and half my software ignores it" is usually the reverse.
Android has the same shape of problem with a completely different mechanism, which we covered in why Android's proxy reaches some apps and not others. On Windows the clearest example is the one almost everybody hits.
Why Windows Update Skips the Proxy Server Windows Just Saved
Because Windows Update does not look at your Settings screen first. It looks at the machine-level store, and it only falls back to yours if that fails in a particular way. Microsoft documents the order plainly.
From Microsoft's page on how the Windows Update client picks a proxy, for the URLs used to detect updates: first, "The system proxy is attempted (WinHTTP)." Then, "If the Windows Update Agent (WUA) fails to reach the service due to certain proxy, service, or authentication error codes, then the user proxy is attempted. (Generally, it's the signed-in user IE settings or WinINet.)"
Microsoft says the quiet part out loud, twice
Which means fixing a background failure usually means writing the other store. There is no screen for that one.
How to Set a Proxy in Windows From the Command Line
Read before you write. The single most useful command on this topic tells you what the machine-level store currently holds, and it takes a second.
netsh winhttp show proxy
# set it
netsh winhttp set proxy proxy-server="192.0.2.10:8080" bypass-list="<local>"
# copy whatever the user-level store currently has, once
netsh winhttp import proxy source=ie
# clear it back to DIRECT
netsh winhttp reset proxy
Two things about that block. import proxy source=ie takes only one source: Microsoft's documentation says "Importing settings from IE is the only available option". Whether it keeps the two stores in step afterwards is not documented either way, and my reading of the word import is that it does not, so treat it as a one-time copy and re-run it when the user-level value changes.
reset proxy does exactly what it says: it "Resets the WinHTTP proxy setting to DIRECT", which is the state a clean machine is in.
The command every guide teaches is the one Microsoft has deprecated
netsh winhttp set proxy. The old commands work today. Treat advproxy as where this is heading, not as something that has already replaced the other.A note on elevation, because it costs people ten minutes. netsh winhttp writes machine-level configuration, so it needs an administrator prompt, and in an ordinary terminal you get an access error rather than a helpful hint about why.
It makes no difference whether you set proxy in Windows cmd or in PowerShell. Netsh is the same tool in both, and both need the elevation.
Once both stores agree, verify from outside the machine with our proxy, VPN and Tor detection check, because a saved field is not evidence of a working proxy. Browsers are the next question, and Edge is where people expect a setting that is not there.
Microsoft Edge Proxy Settings: There Is No Such Screen
There is no separate page of MS Edge proxy settings to find, because Edge keeps no proxy store of its own. It reads the platform's. Microsoft's deployment documentation puts it in one line: "When using system proxy settings, one should use the platform's rule format and not Edge's." So the answer to "where are the proxy settings in Edge" is the screen in Section 1. Searching for proxy inside Edge today simply offers to open that screen for you, though that is what I see on the current build rather than something Microsoft documents.
That same page lists the other ways Edge can be pointed somewhere else: manual rules, a PAC script, autodetect, the --proxy-server command-line flag, policy, and extensions. That page does not rank them against each other, so I am not going to invent an order from it. Edge is Chromium, and we worked out Chromium's actual precedence from its source in where Chrome's proxy settings really come from. The same ranking applies here, for the same reason.
Chrome on Windows behaves the same way. Chromium's own networking documentation describes Windows' WinINet configuration as the system proxy settings it follows, and both browsers can be overridden at launch. Which leaves the old Control Panel route.
Internet Options is still on Windows 11, under the Connections tab as LAN settings, and it is the only screen that gives you a box per protocol: HTTP, Secure, FTP and Socks. Those labels are what the dialog shows rather than something Microsoft still publishes a field list for.
One ranked guide tells readers that dialog is for "Windows versions (7, 8, and older)". It is not. It is on the machine in front of you.
And that Socks box is the one field in Windows that names a protocol, which makes it the obvious place to go looking for SOCKS5. It is also the place where this topic is settled, in writing, by a source nobody cites.
Windows 11 SOCKS5 Proxy: What the Settings Screen Cannot Do
The Manual proxy setup screen takes an address and a port. That is the entire form. There is no protocol selector, no type dropdown, and no username or password field, which is why a Windows 10 SOCKS5 proxy authentication question has no answer on that screen either.
A widely read guide claims otherwise, and it is worth quoting because a lot of people have followed it: "By default, Windows will consider your proxy as an HTTP proxy. So, you do not have to manually enter the protocol 'HTTP.'" There is no protocol to default to. The field has no concept of one. The same page then sends readers to Internet Options for a SOCKS proxy, which at least points at the right dialog.
Microsoft documents this, and nobody quotes it
Which turns a Microsoft Q&A thread that reads like a mystery into a confirmation. A user sets a SOCKS proxy through Internet Options, finds TCP works and UDP does not, captures the traffic in Wireshark, and reports seeing only SOCKS4 commands. He then proves it by disabling SOCKS4 on the proxy server and watching browsing break.
A Microsoft staff member replies by pointing him at the Settings app, which has no protocol field at all. That capture is one person's observation rather than documentation, and it matches the reference table exactly.
The routes that do work are all per-application rather than system-wide. Launching a Chromium browser with --proxy-server="socks5://192.0.2.10:1080" is explicit about the version. An SSH dynamic forward gives you a local SOCKS5 endpoint that individual applications can be pointed at. Tools that speak SOCKS natively take their own configuration and ignore Windows entirely.
Notice the pattern: none of those touch a Windows proxy setting. There is a whole category of software on this machine that never reads one.
The Tools That Read None of This: Command Line, WSL and Docker
Set a Windows HTTP proxy in Settings, open a terminal, run git or curl, and nothing changes. That is not a bug and it is not a permissions problem. Those tools follow a convention that predates the Settings app and has nothing to do with it: environment variables.
set HTTP_PROXY=http://192.0.2.10:8080
set HTTPS_PROXY=http://192.0.2.10:8080
set NO_PROXY=localhost,127.0.0.1,.internal.example
# persist for your user account, new terminals only
setx HTTP_PROXY "http://192.0.2.10:8080"
# check what a shell can actually see
echo %HTTP_PROXY%
| Tool | Does it read the Settings screen? | What it reads instead |
|---|---|---|
| Edge, Chrome | Yes, unless overridden at launch or by policy | The per-user WinINET store |
| Windows Update, services | Not first, and sometimes not at all | The machine-level WinHTTP store |
| curl, git, pip, npm | No | HTTP_PROXY, HTTPS_PROXY and NO_PROXY |
| Docker Desktop | Only if you ask it to | Its own Proxies setting, whose System proxy mode reads the host's configuration |
| WSL 2 | On Windows 11, yes by default | autoProxy in .wslconfig, then variables inside the distro |
WSL deserves a paragraph of its own, and it is the one place where the usual advice is out of date. On Windows 11 22H2 and higher, WSL 2's autoProxy setting defaults to true, and Microsoft's documentation says it "Enforces WSL to use Windows' HTTP proxy information". So the proxy you set in Windows does reach the distro, on Windows 11, unless somebody turned it off in .wslconfig.
Two catches. On Windows 10 there is no autoProxy at all, so there you really are exporting variables by hand. And there is a timing window: initialAutoProxyTimeout defaults to 1000 milliseconds, and Microsoft warns that "If proxy settings are resolved after this time, the WSL instance must be restarted to use the retrieved proxy settings". A distro that started before the proxy resolved will keep ignoring it until you restart it, which looks exactly like the setting not working.
None of this hides anything, incidentally. If the reason you are here is privacy rather than a network that requires a proxy, check what is actually leaking with our guide to checking whether your IP is leaking past a VPN, and see what a page can still read from your browser with our browser leak test.
How to Disable a Proxy on Windows 10 and 11, Properly
Three stores, three switches. Turn off Use a proxy server in Settings, run netsh winhttp reset proxy from an elevated prompt, and clear any HTTP_PROXY and HTTPS_PROXY variables you set. To remove proxy settings, Windows 10 and 11 both need all three done. Doing one and calling it finished is the reason a Windows 10 proxy appears to come back.
Two Windows-specific cases are worth telling apart before you start fighting the machine. On a domain-joined work or school device, Group Policy can rewrite the setting after you change it. The giveaway is that the change reverts within a minute or two and the field may be grayed out. That is management doing its job, and you are not meant to win that argument.
The same applies to "Automatically detect settings". On a domain network, WPAD can hand your machine a configuration every time it connects, so switching the box off locally lasts until the next reconnect. If that is what you are seeing, the fix is a conversation with whoever runs the network, not another pass at the checkbox.
The other case looks similar and is not benign: unwanted software sets a proxy so it can sit in the middle of your traffic. The way to tell them apart is ownership rather than behavior. A managed device is one you were issued or enrolled; if you bought the machine yourself and nobody has ever administered it, a proxy you did not set is worth treating as an intrusion and cleaning up as one.
While you are in there: the same Settings area is where people go looking to change a local address, which is a different job covered in changing your IP address on Windows, and if the actual goal is to stop a specific address reaching you, that is a Windows Firewall rule rather than a proxy.
The Short Version
Proxy settings, Windows 10 and 11, live under Settings, Network & internet, Proxy, and that screen is identical on both operating systems. It writes a per-user WinINET value with an address, a port and a bypass list. No protocol, no credentials.
It is not the only proxy on the machine. Services read a machine-level WinHTTP value that only netsh winhttp writes, and Microsoft documents Windows Update trying that one first. Command-line tools read environment variables and never look at either.
Docker Desktop and WSL 2 can both be pointed at the Windows configuration, but only through settings of their own. Every "my proxy is not working" question on Windows is really a question about which store you wrote.
Two currency notes. Windows 10 reached end of support on 14 October 2025, and consumer Extended Security Updates now run through 12 October 2027, a year later than first planned. Windows 11's newest generally available version is 26H1, with 26H2 in the Release Preview Channel since August 2026.
Whatever you change, confirm it from the outside rather than from the checkbox. Our IP trust score checker tells you how the address you are actually leaving from is classified, which answers the real question faster than any settings screen can.