On this page
After Clash exits, Windows may keep sending requests to the old port
A classic symptom is that pages work while Clash is running, but the browser immediately shows ERR_PROXY_CONNECTION_FAILED after the app exits and recovers as soon as Clash is reopened.
The broadband connection is usually not the problem. Proxy settings still point to 127.0.0.1 and an old port; the process is no longer listening, but Windows continues forwarding requests, which naturally produces connection refused.
First connect a phone to the same Wi-Fi, or ping the router's management address from the computer. If other devices have internet access and the computer can reach the router, do not reset the network adapter yet. Windows user proxy settings, automatic configuration scripts, WinHTTP, environment variables, and per-app proxies are independent; identify which layer retained the setting.
Where each symptom usually points
| Symptom | Check first | Common message |
|---|---|---|
| Chrome, Edge, and system apps all lose connectivity | Windows manual proxy or setup script | ERR_PROXY_CONNECTION_FAILED |
| The browser works, but an installer or system service fails | WinHTTP | Connection refused or unable to download |
| Git and npm fail in the terminal | Environment variables and the tool's own proxy settings | Failed to connect to 127.0.0.1 |
| Only one browser behaves abnormally | An extension, browser policy, or secure DNS | Other apps remain accessible |
| Everything breaks after exiting whenever TUN has been used | Virtual adapter, service, and routes | No explicit proxy error |
Restore direct access from the Windows “Proxy” page first
Where to check in Windows 11
Open proxy settings
Go to “Settings → Network & Internet → Proxy” and first check whether “Use a proxy server” is still enabled.
Disable the old manual address
If the address is 127.0.0.1 and the port matches Clash's mixed-port, disable “Use a proxy server” and save.
Check the setup script
If “Use setup script” contains an old PAC address, disable it too; leave “Automatically detect settings” enabled for now.
Completely exit the browser and test again
Close every browser window, confirm that background processes have ended, then open an incognito window and visit ordinary HTTP and HTTPS sites.
If the Windows page already looks disabled, press Win + R, run inetcpl.cpl, and check “Connections → LAN settings” again. Some older programs still read the user proxy through these Internet options. Do not leave the enable toggle on while changing only the address.
After this restores access, keep Clash closed. If the router dashboard and common websites open directly, you have located a stale user proxy. There is no reason at this point to run winsock reset or remove network adapters.
If the browser recovers but system downloads still fail, inspect WinHTTP
WinHTTP is primarily used by system services, installers, and some enterprise software; it is not the same toggle as the Windows “Proxy” page. Inspect it only when the browser already connects directly but winget, an installer, or a service still tries to use the old proxy.
netsh winhttp show proxy
# 只有输出仍显示旧代理时才执行
netsh winhttp reset proxyIf only the terminal has no network access, variables or tool settings probably remained after Clash exited
Many development guides temporarily set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, while others save a proxy in Git or npm configuration. These settings do not disappear automatically when the Clash window closes. In a new PowerShell session, inspect process-level and user-level variables first, then check the failing tool's own configuration source.
Get-ChildItem Env: | Where-Object Name -match '^(HTTP|HTTPS|ALL|NO)_PROXY$'
[Environment]::GetEnvironmentVariable('HTTP_PROXY', 'User')
[Environment]::GetEnvironmentVariable('HTTPS_PROXY', 'User')
git config --show-origin --get-regexp "http.*proxy"
npm config get proxy
npm config get https-proxyGit reports Failed to connect to 127.0.0.1 port 7890
Common cause:Git configuration or an environment variable still points to the old port
Resolution:Use the file returned by --show-origin to remove the corresponding proxy entry; do not delete unrelated Git settings.
npm fails, but curl works
Common cause:The npm user configuration still contains proxy/https-proxy
Resolution:After confirming the source, run npm config delete proxy and npm config delete https-proxy.
A new terminal works, but an old terminal fails
Common cause:The old window inherited proxy variables at startup
Resolution:Close the old terminal and open a new one; no system-network changes are needed.
If only the browser is affected, remove the browser's own proxy settings
First open an incognito window and disable every proxy extension. An extension may switch to its own PAC or continue intercepting requests after the system proxy is disabled. A corporate browser may also receive proxy settings through policy; chrome://policy or edge://policy shows the source. If a managed policy exists, do not force an override through the registry.
ERR_NAME_NOT_RESOLVED is more consistent with resolution failure, while ERR_PROXY_CONNECTION_FAILED explicitly indicates a proxy connection. For the former, temporarily disable the browser's “Use secure DNS” option for comparison. Receiving a 403 or 404 proves that the network request reached the server, so do not keep clearing caches or resetting adapters.
If the whole computer is offline without a proxy error, inspect the TUN service and default route
TUN mode creates a virtual adapter and changes routes, so its troubleshooting differs from the system proxy. Reopen Clash, disable TUN and service mode, then exit normally from the tray menu. Use route print to confirm that the default route returns to the real Wi-Fi or Ethernet gateway. Do not delete a driver simply because you see a virtual adapter; another VPN may use it too.
Get-NetAdapter | Sort-Object Status, Name
route print- The default route still points to an inactive virtual interface
- First disable the corresponding VPN/TUN service normally and restart the computer. Record the interface name before deciding whether to uninstall client components.
- The physical adapter has no gateway or has a 169.254 address
- This is now a DHCP or local-network problem. Reconnect to Wi-Fi or renew the address instead of changing more proxy settings.
- Routes and addresses are correct, but only DNS fails
- Check the adapter DNS and browser secure DNS; a full network reset should be the last resort after a backup.
Use “direct access still works after Clash closes” as the repair criterion
After closing Clash, verify each item
- Windows “Use a proxy server” and the old PAC are both disabled
- netsh winhttp show proxy displays Direct access on a computer that should connect directly
- No proxy variables in the new terminal point to the old port
- The browser, system update checker, and at least one terminal tool all have access
- The result remains stable after restarting the computer
When enabling Clash again, use only one capture method at a time. Start with the system proxy and confirm that enabling and exiting both restore state correctly. Test TUN separately only if an app genuinely ignores the system proxy. Do not let the client, a browser extension, and a script all modify the system proxy; the next stale setting will be difficult to attribute.