Fix Clash System Proxy Not Working: Browser vs Terminal Troubleshooting

Start With a Three-Minute Baseline Check

Most "system proxy not working" issues actually break down at the most basic level. Before changing any settings, run through these four checks in order — chances are you'll spot the problem immediately.

Confirm the client is actually running. You should see the icon in the tray and be able to open the main window — not find it silently quit after being minimized.
Confirm the node actually works. Run a latency test on the current node in the Proxies tab. Swap out any node that times out or shows abnormal latency. The system proxy is just the entry point — if the node itself is broken, a correctly configured entry point won't help.
Confirm the system proxy was actually written to the OS. The client showing the toggle as "on" isn't enough — check the actual value at the OS level: on Windows, go to Settings → Network & Internet → Proxy and check "Use a proxy server"; on macOS, go to System Settings → Network → Details → Proxies and check Web Proxy and Secure Web Proxy; on Linux (GNOME), go to Settings → Network → Network Proxy and check whether it's set to Manual. The address should be 127.0.0.1, with the port matching the client.
Confirm the ports actually match. The port shown on the client's settings page must match the port written into the system. Changing the port but forgetting to retoggle the switch is one of the most common mistakes.

Always Check the Port on the Client's Settings Page

Most Clash-based clients default the mixed port to 7890, but some ship with a different default, such as 7897. Before troubleshooting, confirm the actual listening port in the settings page — replace 7890 in the commands below with your own port.

What the System Proxy Toggle Actually Does

Understanding how this works saves you from a lot of guesswork. The toggle does exactly one thing: it writes "127.0.0.1 + the client's listening port" into the OS-level proxy configuration. From then on, any app that respects the system proxy — most browsers and desktop software — routes its connections through the Clash core first, which applies rules to decide where traffic goes. Apps that don't read the system proxy are completely unaffected — command-line tools are the classic example.

So "toggle is on but nothing happens" can only come down to three possibilities:

Write failure: the config was never actually written to the system — usually caused by insufficient permissions, security software blocking it, or another proxy app overriding it.
App doesn't read it: the app uses its own proxy settings, or ignores the system proxy entirely.
Entry point is broken: the config is written correctly, but Clash's port isn't listening, or the current node is unreachable.

The first and third cases are already ruled out by the baseline check above. For the rest, troubleshoot browsers and terminals separately.

Browsers: Check Extensions and Standalone Settings First

First, confirm with a single command that the Clash entry point itself is working. Open a terminal and explicitly point an IP lookup request through the proxy:

curl -x http://127.0.0.1:7890 https://api.ip.sb

The response should be the node's exit IP. If this step fails, the problem is with the client or the node, not the browser — go back to the first section. If this works but the browser still doesn't route through the proxy, check the following in order:

Disable proxy extensions. Extensions like SwitchyOmega take over the browser's proxy settings and override the OS-level config. Disable them all, test again, then re-enable one at a time to find the culprit.
Test in an incognito/private window. Private windows don't load extensions by default. If it works in private mode but not in a normal window, an extension is almost certainly hijacking the proxy.
Check Firefox's standalone proxy settings. Firefox manages its proxy settings independently of the OS panel. If you've changed it manually before, go to Settings → Network Settings and switch back to "Use system proxy settings."
Clear out any leftover auto-config scripts. If "Automatic proxy configuration URL (PAC)" is still set in the system proxy settings, the browser will follow that script instead of Clash — turn it off.
Do a final check with your exit IP. Open an IP lookup site, switch nodes, and refresh — if the exit IP changes accordingly, the connection is working. If a specific site still won't load, that's a rules or node issue, not a system proxy issue.

Terminal: Command Lines Don't Read the System Proxy

This is the most common misunderstanding: terminals — and tools like curl, git, npm — never read the system proxy by default, no matter how long the toggle has been on, they'll still connect directly. To route the terminal through the proxy, you need to set environment variables separately.

macOS / Linux(bash、zsh):

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

Windows PowerShell:

$env:http_proxy="http://127.0.0.1:7890"
$env:https_proxy="http://127.0.0.1:7890"

Windows cmd:

set http_proxy=http://127.0.0.1:7890
set https_proxy=http://127.0.0.1:7890

After setting them, run curl https://api.ip.sb to verify — if it returns the node's IP, it's working. A few more details worth remembering:

Environment variables only apply to the current terminal window — they're gone once you close it. For a persistent setup, add them to your shell config file (e.g. ~/.zshrc).
To route just a single command through the proxy on macOS/Linux, prefix it temporarily: https_proxy=http://127.0.0.1:7890 curl https://api.ip.sb.
Local and LAN addresses should bypass the proxy: export no_proxy=localhost,127.0.0.1.
To disable the terminal proxy: on macOS/Linux run unset http_proxy https_proxy all_proxy; in PowerShell, just clear the corresponding variables.
git uses its own config and in some setups ignores environment variables entirely: git config --global http.proxy http://127.0.0.1:7890; to remove it, use git config --global --unset http.proxy. Note this only affects HTTP(S) remotes — SSH remotes are unaffected.

Port Conflicts: A Failed Listener Makes the Toggle Meaningless

When another program is already using the port, Clash's port listener fails silently — the toggle still turns on, and the system config still gets written, but there's no service behind the entry point to actually handle traffic. The result looks exactly like "the toggle does nothing." First, check who's holding the port. On Windows (PowerShell or cmd): ```bash netstat -ano | findstr :7890 ``` If there's output, the port is already in use — the last column is the PID of the process holding it. Run `tasklist | findstr ` to see which program it belongs to. On macOS/Linux: ```bash lsof -i :7890 ``` On Linux you can also run `ss -lntp | grep 7890`. If the process shown isn't your Clash client, that confirms the conflict. There are two ways to fix it: - Change the port: switch the mixed port to a free value (e.g. 7897) in the client's settings page, save, then turn the system proxy toggle off and back on so the new port gets rewritten into the system. - Free up the port: the most common culprit is another proxy client that didn't fully quit, or a leftover process from a previous crash. Quit it from the tray, or kill the process directly.

You Must Retoggle the Switch After Changing the Port

The system proxy config still points at the port from before your change. If you only update the setting without retoggling the switch, the system keeps pointing at the old port and the problem persists.

Permissions, Leftover Configs, and Multiple Clients Fighting Over the Proxy

If the port is fine but it's still not working, check these three common causes next:

macOS authorization was cancelled. The first time you enable the system proxy, macOS prompts for your password. Clicking "Cancel" means the write silently fails — the toggle looks on, but nothing was actually written to the system. Retoggle it and complete the authorization this time.
Security software is blocking it. Some Windows security software blocks third-party apps from modifying the system proxy. Add the client to the trusted list, then retoggle the switch.
Multiple clients competing for the proxy. Running two proxy clients at once means the one opened later overwrites the system proxy config written by the first — so the first one naturally "stops working." Keep only one running at a time.

There's also a reverse issue worth knowing: if you quit the client without turning off the system proxy first, the OS keeps the 127.0.0.1:7890 entry indefinitely, even though nothing is listening on that port locally anymore — which looks like "quitting Clash broke my internet." The fix is to reopen the client and toggle the switch off once, or manually disable it in the system proxy settings.

On corporate or school devices where proxy settings are locked down by group policy or configuration profiles, any manual change gets reverted immediately. There's no point fighting the system proxy in this environment — use terminal environment variables instead, or see the TUN mode section below.

Heavy Terminal Users Should Just Switch to TUN Mode

The system proxy's inherent weakness is that it depends on app cooperation — if an app doesn't read the system settings, the toggle simply can't reach it. For users who regularly run git, npm, or docker in the terminal, TUN mode is the more hands-off solution: it creates a virtual network adapter and takes over traffic at the OS network layer, regardless of app — command-line tools route through the proxy automatically, with zero configuration.

Clients built on the mihomo core (Clash Verge Rev, Clash Nyanpasu, FlClash, etc.) all offer a TUN toggle in their settings page. On Windows and macOS, enabling it for the first time usually requires installing a service-mode component or completing one administrator authorization. TUN mode and the system proxy can run at the same time without conflict — TUN handles routing at the network layer, while the system proxy handles the application layer.

A One-Page Checklist

If you're stuck, go through this checklist from the top:

The client is running and the current node passes a latency test.
The system proxy settings show 127.0.0.1, with the port matching the client's settings page.
Running curl -x http://127.0.0.1:7890 https://api.ip.sb in the terminal returns the node's IP.
All proxy extensions are disabled in the browser, and you've tested with a private window.
The http_proxy / https_proxy environment variables are configured separately for the terminal.
netstat or lsof confirms there's no port conflict, and the switch was retoggled after changing the port.
Only one proxy client is running, and the system proxy is disabled before quitting it.
For heavy terminal use, TUN mode is enabled to take over traffic globally.

Most "system proxy not working" issues can be narrowed down by the third step: if the entry point works, check the app; if it doesn't, check the client and the port. Troubleshooting each path in order is far faster than reinstalling the client.