Clash System Proxy Not Working: Fixing Browser and Terminal/CLI Proxy Issues Separately

B-01First, identify which layer the problem is in

"Clash is running but it's not working" is too vague to act on. Before you dig further, lay out how system proxy scope actually works. In system proxy mode, the Clash client modifies OS-level network settings (Windows' Internet Options registry key, or macOS' network service proxy fields) so that any program honoring the system proxy stack automatically routes through the local listening port (typically an HTTP proxy at 127.0.0.1:7890 or a mixed port). But this "system proxy" switch only affects apps that actually respect system proxy settings — and browsers, terminal command-line tools, and various background services vary widely in how well they comply.

That's why the same "not working" symptom needs completely different troubleshooting depending on whether it's a browser or a terminal issue — mixing the two up just makes things messier. This guide splits the checklist into three sections — browser side, system layer, terminal side — with verification commands at the end. Work through them in order; don't skip steps.

B-02Browser-side checks: extension conflicts and built-in proxy priority

A browser not using the proxy is the most common complaint, and the cause usually falls into one of three categories — check them in this order.

1. A proxy management extension is installed

Extensions like SwitchyOmega or Proxy SwitchySharp take over the browser's proxy configuration interface. Once installed and enabled, the browser follows the extension's settings instead of the OS system proxy. If the extension is currently set to "direct connection" or pointing at a dead port, the browser won't be able to connect even if Clash has correctly set the system proxy. Fix it by adding a rule in the extension pointing to Clash's local port, or temporarily disable the extension to see if things recover.

2. Enterprise policy or leftover browser configuration

Some browsers — especially ones pre-installed in corporate environments — have their proxy settings locked by group policy, making system proxy changes ineffective. Check the browser's built-in network settings page and confirm the proxy source shows "Use system proxy settings" rather than "Direct connection" or "Manual configuration." If it's manually configured and pointing at a stale address, clear it and restart the browser.

3. Incorrect port or rule logic in PAC script mode

Some Clash client versions support taking over the system proxy via a PAC (Proxy Auto-Config) script. If the logic in the PAC script is wrong, or the listening port doesn't match what the client is actually using, requests evaluated against the PAC script will resolve to "direct connection" — which looks exactly like the proxy isn't working at all. Switch back to standard "system proxy" mode (non-PAC) first to see if the problem disappears before deciding whether to keep using PAC.

B-03System-layer checks: confirm the system proxy was actually written

If the browser checks turn up nothing, take a step back and confirm the system proxy layer itself was actually applied — don't assume that flipping the Clash toggle guarantees it got written correctly.

Windows: check Internet Options

Open Control Panel → Network and Internet → Internet Options → Connections → LAN Settings, and confirm "Use a proxy server for your LAN" is checked, with the address and port matching what's shown in the Clash client. If this field is empty, the client's "Set as system proxy" toggle didn't actually take effect — usually because the client lacks sufficient permissions (try running as administrator) or another proxy tool (like a corporate VPN client) is conflicting, with whichever one started last overwriting the other's settings.

macOS: check the network service's proxy fields

Go to System Settings → Network → [the active network service] → Details → Proxies, and check whether "Web Proxy (HTTP)" and "Secure Web Proxy (HTTPS)" are enabled with Clash's listening address and port filled in. On macOS, if multiple network services are active at once (say, both Ethernet and Wi-Fi are connected), Clash may only be writing to the higher-priority one while actual traffic is routing through the other — creating the illusion that "it's configured but not working." Make sure the active network service is the same one Clash wrote to.

B-04Terminal command line not using the proxy: environment variables are the key

Command-line tools in your terminal (Terminal, PowerShell, Bash) — curl, wget, git, npm, pip, and most others — do not read system proxy settings. Instead, each reads its own set of conventional environment variables, which is the single most overlooked reason terminals don't route through the proxy. It's completely normal for the system proxy to be set correctly and the browser to work fine, while the terminal still times out or fails to connect — this isn't a bug, it's just a step you still need to configure.

Environment variables you need to set manually

Most command-line tools follow the http_proxy and https_proxy convention (and their uppercase counterparts HTTP_PROXY, HTTPS_PROXY), set to Clash's local HTTP proxy listening address.

macOS / Linux (Bash or Zsh), applies temporarily for the current terminal session only:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

To make this apply automatically every time you open a terminal, append these two lines to the end of ~/.zshrc or ~/.bash_profile, then run source ~/.zshrc to apply it immediately.

Windows PowerShell, applies temporarily:

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"

For a permanent setup, append the same two lines to your PowerShell profile script (the file pointed to by $PROFILE), or create user-level variables through the system environment variables panel.

Some tools have their own separate proxy configuration

Even with the environment variables above set, some versions of git still need extra configuration to work with HTTPS repositories:

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

The same applies to npm and pip — use npm config set proxy / npm config set https-proxy for npm, and either append --proxy to pip install or configure it in pip.conf for pip. These tool-specific settings take priority over environment variables, so if the environment variables are set but the tool still isn't using the proxy, check whether it has its own proxy config that's overriding them.

B-05Use TUN mode to skip dual configuration of system proxy and environment variables

If you keep running into apps that neither respect the system proxy nor read environment variables (common with certain GUI apps, game clients, and some language runtimes' networking libraries), the easier fix is switching to TUN mode. Supported by Clash Meta (the mihomo core) and clients built on it — Clash Verge Rev, FlClash, and others — TUN mode works by creating a virtual network adapter that intercepts all outbound traffic at the system level, regardless of whether the app itself reads proxy settings. Browsers and terminal commands both work automatically, with no separate configuration needed.

Enabling TUN mode usually requires the client to request administrator/root privileges to create the virtual adapter, and macOS and some Linux distributions may need an additional network extension component installed. The exact toggle is typically found under "TUN Mode" or "Tun Adapter" in each client's settings. It's a good idea to turn off the system proxy option before enabling TUN mode, to avoid routing conflicts from having both take over traffic at once.

B-06Verify step by step: confirm the fix actually worked

Don't conclude "it works now" just because things feel fine — run the following commands one at a time to clearly determine whether the system proxy, the terminal, or neither, is actually working.

Verify whether the terminal is reading the environment variables and successfully routing through the proxy:

curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I

A response of HTTP/1.1 204 No Content confirms the proxy port itself is working correctly. Next, run the same test without the -x flag, relying only on the environment variables you set:

curl https://www.gstatic.com/generate_204 -I

If this also returns 204, the environment variables are being correctly read by curl. If it times out or fails outright, the variables aren't being exported into the current session — double-check the variable name casing and whether your config file is actually being loaded.

Verify whether the system proxy port is correctly registered with the OS (Windows PowerShell):

netsh winhttp show proxy

This command shows the WinHTTP-layer proxy configuration, which may not match the WinINet-layer configuration used by browsers. If the two show different addresses, that's often a separate cause of browsers not using the proxy — you'll need to confirm and correct it directly in the browser's proxy settings.

• Browser not using the proxy: check extensions first, then the built-in proxy source, then whether the PAC script logic is wrong.
• System proxy toggle has no effect: verify whether Windows Internet Options / macOS network service proxy fields were actually written, and check for conflicts between multiple active network services.
• Terminal command line not using the proxy: set the http_proxy / https_proxy environment variables, and check git, npm, pip, and similar tools for their own separate config settings.
• Same issue keeps recurring: consider switching to TUN mode to take over all traffic in one go.