Clash Closed but Browser Won't Load?
Clear Stuck Windows System Proxy Step by Step

1. Why Windows keeps pointing at Clash after you quit

GUI clients based on Clash or Mihomo often expose a toggle labeled “Set as system proxy,” “System Proxy,” or similar. When enabled, the program writes the same values you would set manually: a loopback address (typically 127.0.0.1) and a port (often the mixed port or dedicated HTTP port). WinINet consumers—classic desktop browsers, parts of the Office stack, and many line-of-business tools—read those values from the user’s Internet Settings store, which is surfaced in both the modern Settings app and the older Internet Options control panel.

On a normal exit path, a well-behaved client clears those fields or turns the manual proxy off. Real life is messier: the tray app freezes, Task Manager ends the process, a Windows Update reboot interrupts shutdown, or you delete the folder while the profile still had system proxy engaged. The core is gone, but the OS configuration still says “send HTTP(S) to this local listener.” That mismatch is what people describe as “the whole PC lost internet right after I closed Clash.”

This article focuses on that class of failure: HTTP/HTTPS proxy residue at the OS layer. It is intentionally different from TUN virtual-adapter problems (routes, Wintun, firewall) and from pure DNS or fake-ip confusion, which can look similar in a browser but require different fixes.

2. Symptoms that point to a stuck system proxy

You will usually see one or more of the following patterns immediately after Clash stops running:

• Chrome, Edge, or Firefox (when set to “Use system proxy settings”) shows ERR_PROXY_CONNECTION_FAILED, “Unable to connect to the proxy server,” or endless loading with no DNS error page.
• Curl or PowerShell Invoke-WebRequest fails with proxy-related errors while ping to a numeric IP still works—suggesting L3 reachability but broken application-level forwarding.
• Some Microsoft Store or WinINet apps fail, while a game launcher that ignores OS proxy continues to patch—split behavior that confuses people into blaming the ISP.
• Opening Windows Settings → Network & internet → Proxy still shows Use a proxy server toggled on with 127.0.0.1 and a port you recognize from your old profile.

Collect one screenshot or note of the exact error string. It helps you distinguish this scenario from captive portals, VPN blackout, or resolver issues covered in our fake-ip and DNS troubleshooting guide.

3. Clear the proxy in Windows Settings (first stop)

On Windows 10 and Windows 11, the friendly path is Settings → Network & internet → Proxy. Work through the panel in this order:

1. Under Automatic proxy setup, turn Automatically detect settings on if your network expects WPAD; otherwise you may leave it off, but remember some workplaces require it—when in doubt, match a working colleague’s laptop or IT guidance.
2. Turn off Use setup script unless you intentionally use a PAC URL supplied by your organization. A leftover script pointing at a file from a removed client should be deleted.
3. Under Manual proxy setup, disable Use a proxy server. Expand the section if needed and clear Address and Port fields so nothing references 127.0.0.1 or an old mixed port.
4. Scroll to the bottom and use Save if the build shows an explicit save button; newer builds apply immediately.

Retry a browser tab. If it still fails, do not assume the UI lied—continue to the legacy dialog, because some third-party tools write values that sync late or expose mismatched toggles between APIs.

4. Internet Options (inetcpl.cpl) and LAN settings

The Internet Options dialog is the same surface historically labeled IE settings. It still controls WinINet defaults many components read.

1. Press Win + R, type inetcpl.cpl, press Enter.
2. Open the Connections tab → LAN settings.
3. Uncheck Use a proxy server for your LAN unless your enterprise requires it. If you must keep corporate proxy details, coordinate with IT instead of following consumer cleanup steps.
4. Uncheck Use automatic configuration script if it points to an obsolete path, then delete the script URL field.
5. Optionally enable Automatically detect settings for networks that rely on WPAD; many home users leave this on without issue.
6. Confirm with OK on both dialogs.

After this, hard-refresh the browser or open an InPrivate window to avoid cached HSTS or extension interference. If connectivity returns, you have confirmed WinINet-level proxy residue was the culprit.

5. Registry keys under Internet Settings (when the UI is wrong)

Power users can inspect the same data the UI edits. The per-user store lives at:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

Important value names include:

• ProxyEnable — 0 means off; 1 means manual proxy is active.
• ProxyServer — often looks like 127.0.0.1:7890 or includes schemes such as http=127.0.0.1:7890;https=127.0.0.1:7890.
• ProxyOverride — semicolon-separated bypass list; corrupt entries are rare but can be reset.
• AutoConfigURL — should be empty when you are not using PAC.

Typical recovery sequence in Registry Editor (regedit): set ProxyEnable to 0, delete or clear ProxyServer if you are sure you do not need it, clear AutoConfigURL if it references a stale script, then restart the browser. Always export a .reg backup of the key before changes.

Some all-in-one cleaners promise “reset network”—they may nuke wider keys than necessary. Prefer targeted edits so you do not lose legitimate corporate overrides elsewhere.

6. WinHTTP: the separate stack system services use

Not every program uses WinINet. Windows services and certain binaries consult the WinHTTP proxy, which can diverge from the user’s IE settings. Symptoms include “some apps work in my session but updates or background tasks fail.”

Open an elevated Command Prompt or PowerShell and inspect:

netsh winhttp show proxy

If you see a direct connection, WinHTTP is fine. If it lists a proxy you no longer run, reset it:

netsh winhttp reset proxy

Some documentation suggests importing IE settings into WinHTTP (netsh winhttp import proxy source=ie) after you have cleaned Internet Options. That is appropriate when you intentionally want both stacks aligned. After a Clash mishap, starting from reset proxy plus a clean Settings UI is usually clearer than importing half-broken values.

7. PAC files, WPAD, and less common leftovers

Occasionally a client or IT script leaves behind a pointer to a PAC file on disk. Windows then tries to fetch rules from a path that no longer exists, which can stall connections intermittently. Clearing AutoConfigURL in both Settings and LAN settings, plus the registry value mentioned above, covers most cases.

Enterprise Group Policy objects can force proxy mode regardless of user toggles. The Local Group Policy Editor (gpedit.msc) path User Configuration → Windows Settings → Internet Explorer Maintenance (older) or newer Administrative Templates branches may contain enforced connection settings. On unmanaged PCs this is uncommon, but it is worth five minutes if everything keeps reverting.

8. When it is not system proxy: DNS, fake-ip, and TUN

If you cleared every proxy field and ran netsh winhttp reset proxy but browsers still behave oddly, widen the diagnosis:

• DNS only: Pages fail with explicit name-resolution errors, or work when you type an IP. Review adapter DNS servers, Clash DNS settings, and fake-ip filters in the dedicated DNS guide.
• TUN / Wintun: Blackouts that appear only with TUN enabled usually involve routes or firewall, not the HTTP proxy dialog. Use the TUN routing and firewall checklist instead of repeating proxy resets.
• macOS contrast: Apple’s Network Extension path differs; see Clash Verge on macOS: system proxy for parity reading—not because the registry steps here apply, but because mental models carry over.

Keeping those scenarios separate saves time: proxy cleanup is fast when it is the right fix, and frustrating when the real issue is an orphaned default route under TUN.

9. Cheat sheet: where each layer is cleared

For broader configuration concepts—rules, DNS modes, and ports—our documentation hub stays the authoritative starting point once connectivity is back.

10. Prevention and healthier shutdown habits

After you recover, adopt a small routine:

• Turn off system proxy inside the client before uninstalling or upgrading.
• If you frequently switch between TUN and system proxy modes, document which mode your daily driver uses so you do not stack conflicting assumptions.
• Prefer downloading updates from the official download page so the installer’s cleanup hooks match the build you actually run.
• When testing experimental cores, keep a known-good portable copy that can still open the UI and clear toggles if the bleeding-edge build crashes.

None of this replaces backups of working YAML, but it dramatically reduces “mystery offline” incidents that are really just an empty port where a proxy used to listen.

11. Summary

Clash is powerful on Windows precisely because it can integrate with the OS: system proxy mode steers WinINet apps through your rules without TUN. The trade-off is responsibility—when the client disappears unexpectedly, proxy residue leaves the machine talking to nowhere. Clearing Settings, the legacy Internet Options dialog, optional registry values under Internet Settings, and the separate WinHTTP store restores ordinary direct routing for most users.

Compared with opaque one-button VPNs, a maintained Clash stack exposes what changed and lets you verify it. That transparency matters most on the day something breaks: you can see the loopback port, remove it deliberately, and return to a sane baseline instead of reinstalling Windows on a hunch.

When you are ready to run the client again, grab a current build from this site, re-import your profile, and toggle system proxy only when the core is healthy enough to shut down cleanly.

→ Download Clash for free and experience the difference