First, Confirm What's Actually Happening: Is the System Proxy Even On?
"System proxy not working" is actually a vague description. It could mean traffic isn't going through the proxy at all, some apps aren't using the proxy, or the proxy is active but the rules are matching the wrong outbound target — three very different problems. Doing a basic sanity check before diving deeper saves most of the troubleshooting time.
Open the client's main window and confirm the "System Proxy" toggle on the sidebar or top bar is switched on. This step may look unnecessary, but in real support logs a good share of reports trace back to the toggle being accidentally switched off, or the system proxy setting not being rewritten after a system restart or a client update.
Next, check the ports. The Clash core listens by default on an HTTP (or mixed HTTP+HTTPS) port and a SOCKS5 port, commonly 7890 (HTTP) and 7891 (SOCKS). Open the operating system's network proxy settings panel and check the address and port against what the client's configuration page shows — if you've changed the port to a custom value inside the client but the system proxy settings still point to the old port, traffic simply never reaches the core.
- Whether the client's "System Proxy" toggle is switched on;
- Whether the mixed port / HTTP port / SOCKS port shown in the client matches the system proxy settings;
- Whether multiple proxy tools are fighting over the system proxy settings, with the one launched later overwriting the earlier one;
- Whether the currently selected policy in the proxy group is "DIRECT" or a node that's no longer working.
Note: Some clients reset the system proxy toggle after switching config profiles. After changing a subscription or local config, re-check the toggle state instead of assuming it's still on.
Browser-Side Checks: Proxy Toggle, Ports, and Extension Conflicts
The browser is the most common place where things "look like they're not going through the proxy" even when Clash itself is fine — the actual cause is usually in the browser's own network settings layer. Different browsers don't handle system proxy settings the same way, so it's worth narrowing things down in the order below.
Check Whether the Browser Reads the System Proxy
Most mainstream browsers follow the system proxy setting by default, but some offer a separate "built-in proxy" option that, once enabled, ignores the system-level setting entirely and uses whatever address the browser has saved on its own. Open the browser's network/proxy settings page and confirm the proxy mode is set to "Use system proxy" or "Auto-detect" rather than having been switched to "Manual configuration" with a stale address filled in.
Check for Conflicts from Extensions
Browser extensions are another frequent culprit. Some circumvention tools, ad blockers, or privacy-enhancing extensions take over proxy settings on their own or inject a PAC script, which conflicts with the system proxy and shows up as "no connection records at all in the client logs." Try disabling all network-related extensions temporarily and refresh the page to test again; if things work, re-enable extensions one at a time to pinpoint the culprit.
Use an Incognito Window as a Baseline
Incognito/private windows don't load ordinary extensions by default, which makes them a convenient way to isolate extension conflicts. If the proxy works fine in an incognito window but not in a normal one, the problem is almost certainly an extension or a stale cached proxy config in the browser — clearing the browser's network settings cache or reinstalling the relevant extension usually fixes it.
Tip: Typing something like about:net-internals or the equivalent network diagnostics page into the address bar shows the currently active proxy address and port in some browsers — far more direct than guessing.
Terminal-Side Checks: Environment Variables, curl Tests, and Common Pitfalls
Command-line programs usually don't read the system-level graphical proxy settings — they rely on environment variables instead. This is why many people find the browser proxy working fine while tools like git, curl, or npm still can't reach the outside network.
First, check whether the Clash client has enabled the terminal proxy environment variable feature for your platform (some clients set http_proxy/https_proxy automatically when the system proxy is on, others require manual setup). Print the current environment variables in your terminal to check:
echo $http_proxy
echo $https_proxy
echo $all_proxyIf the output is empty, the current terminal session has no proxy environment variables set and you'll need to export them manually — use whatever ports the client actually shows:
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:7891"Once set, run a verbose curl request to see whether it's actually going through the proxy:
curl -v -x http://127.0.0.1:7890 https://example.orgIf this command returns content successfully while a plain request without -x fails or gives a different result, the proxy chain itself is fine — the issue is that the target program isn't picking up the environment variables. A common cause is that the variables only apply to the current terminal session; a newly opened terminal window, or an app launched from a desktop icon rather than the terminal, won't inherit them at all. Adding the export statements to your shell's startup file (such as .zshrc or .bashrc) and reloading it, or setting them at the system-wide environment variable level, avoids this "works sometimes, doesn't others" illusion.
One Extra Step on Windows
PowerShell and CMD on Windows likewise don't automatically inherit the graphical system proxy setting — you need to set session variables separately, or set them permanently through the system environment variables panel:
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"After setting them, run a verification request with curl.exe -v or Invoke-WebRequest rather than assuming the terminal must work just because the browser does.
False Failures Caused by Bypass Rules
There's another category of problem where the proxy isn't actually failing — it's working, but the rules are deciding a request "should go direct," which makes it look exactly like the proxy isn't active at all. This is most likely to happen when the rules section of the config file, or the system proxy's bypass list, is set up incorrectly.
The system proxy settings usually include a "bypass the following addresses" field, which may default to include localhost, local network ranges, and similar entries. If a test target site — or an overly broad wildcard — has accidentally been added to that bypass list, that address will never go through the proxy no matter what state the client is in. When troubleshooting, try clearing the bypass list and testing again to see if the issue goes away.
Rules at the config-file level deserve the same scrutiny. Here's a typical rule snippet — check whether an overly broad direct-connect match is sitting ahead of the rules you actually care about:
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXYIf your test target happens to get matched by a rule like GEOIP,CN,DIRECT before reaching anything else, the request will be sent direct and skip the proxy node entirely, regardless of whether the node and port are working perfectly. Open the client's log panel, switch to a detailed log level, and revisit the target address to see exactly which rule the connection matched and which policy group ended up being used — this is the most direct evidence for telling apart "a rule mismatch" from "the proxy isn't actually active."
Suggested order of checks: Check which rule the logs matched → check the bypass list → check the port and toggle → and only then question whether the node itself is working. Following this order is the most efficient path and avoids jumping straight to reinstalling the client or switching subscriptions.
If Everything Checks Out, Consider TUN Mode
System proxy relies on application-layer protocol (HTTP/SOCKS) forwarding. Some programs don't honor the system proxy setting, or use their own custom network stack, and by design will never go through the system proxy — no amount of system proxy troubleshooting will fix that category of problem. If repeated checks confirm the proxy chain itself is fine and it's just a handful of stubborn programs bypassing the system proxy layer, consider switching to TUN mode, where the core takes over all traffic at the network layer instead of depending on whether an individual program reads the proxy settings. TUN mode covers a much broader scope, but it also demands more from permissions and network adapter configuration — treat it as the next step once system proxy troubleshooting has clearly ruled itself out, not as something to jump to before doing the basic checks.