Clash System Proxy Not Working? Troubleshoot Browser and Terminal Connections

First, distinguish system proxy, app proxy, and TUN

The “System Proxy” switch in a Clash client usually writes the local proxy address to the operating system's proxy settings. It does not force all network connections through Clash. Browsers, command-line tools, and background services may each use different settings, so it's entirely possible for websites to load while terminal connections time out.

Start by checking two things: whether the request reaches the Clash core, and which rule it matches once it does. The first is an entry-point issue; the second involves subscription nodes, proxy groups, and routing rules. Don't assume the system proxy switch is broken just because your public IP hasn't changed.

Step 1: Verify the local proxy endpoint

Check the mixed port, not the external controller port

Find mixed-port in the client's settings or configuration view. The mixed port accepts both HTTP and SOCKS proxy requests. external-controller is the listening address for the management API, not a web proxy. A common example is 9090, but don't enter it in your browser's proxy settings just because something is listening on that port.

mixed-port: 7890
external-controller: 127.0.0.1:9090

Make sure the core is running and the intended subscription configuration is selected, then test with a command that explicitly specifies the proxy. In Windows PowerShell, use curl.exe to avoid older versions interpreting curl as a different command.

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/ -o /dev/null

--noproxy "" clears the proxy bypass list for this request, preventing an existing NO_PROXY setting from interfering. The 10-second limit is the connection timeout; 20 seconds is the total request timeout. Neither is a benchmark for node latency. You can replace the test URL with the site that's failing, but don't leave full URLs containing login tokens in public logs.

• If 127.0.0.1:7890 returns a connection-refused error, first check that the core is running, the port is correct, and no other process is using it.
• If you see 200 Connection established for the HTTP proxy tunnel, the local proxy accepted the CONNECT request. Check the subsequent TLS and HTTP results too.
• If the local connection succeeds but then times out or returns a TLS error, investigate the node connection, destination site, DNS, or certificates instead of focusing only on the system proxy switch.

Open the client's Connections or Logs page and make a new request. You can temporarily set the log level to info; use debug only when necessary, then switch it back. If an explicit proxy command works but the browser doesn't, the issue is usually in the browser's own proxy settings.

Step 2: Check where the system proxy is actually configured

Windows 11: Check manual proxy and setup script settings

Open Settings → Network & internet → Proxy, then check Use a proxy server under Manual proxy setup. For this guide's example, the address should be 127.0.0.1 and the port 7890. After enabling the system proxy in the client, return to this page and confirm the values actually changed rather than relying on the client's switch color.

Also check whether Use setup script is enabled and whether the proxy bypass list includes the destination domain. An automatic configuration script, organization policy, or another networking tool may affect the result. On a managed device, contact your administrator before changing organization-enforced settings.

netsh winhttp show proxy reports the WinHTTP proxy settings; it does not show the full state of this Settings page. Some services use WinHTTP, while browsers may use the system proxy mechanism or their own configuration. Don't run a global import command just to make the outputs match. First find out which network interface the affected program actually uses.

macOS: Check the active network service

On macOS 13 or later, open System Settings → Network → your active Wi-Fi or Ethernet connection → Details → Proxies. Check the web proxy (HTTP), secure web proxy (HTTPS), and automatic proxy configuration. If you switch from Wi-Fi to Ethernet, check the settings for the new service rather than the old Wi-Fi connection.

HTTPS websites typically use CONNECT to establish a tunnel through an HTTP proxy. Setting the local proxy address to http://127.0.0.1:7890 does not remove HTTPS encryption or mean you should change the local address to https://. Whether the proxy server itself supports TLS is a separate capability.

Linux: Desktop settings don't cover every program

On GNOME, check Settings → Network → Network Proxy for manual or automatic mode; the path may differ in other desktop environments. Desktop proxy settings usually affect only apps that read them. They don't automatically set environment variables for every shell, container, or systemd service. If a Linux terminal request fails, also check the environment and program settings in the next section.

Step 3: Check browser extensions, bypass rules, and existing connections

In the same browser, open a new window and visit the same test URL while watching the client's Connections page for a new request. Existing HTTP/2 or HTTP/3 connections may stay open and be reused, so refreshing once after changing a switch may not reveal the new connection path. If needed, fully quit and restart the browser.

1. Chrome and Edge: Open the browser settings, search for “proxy,” and open your computer's proxy settings. Desktop versions typically use the system proxy, but extensions, launch arguments, and enterprise policies can override it.
2. Check proxy extensions: Temporarily disable extensions that manage proxy settings or switch them to “Use system proxy.” Don't let a fixed proxy in an extension, a PAC script, and the client's system proxy override one another.
3. Firefox: Open Settings → General → Network Settings → Settings. Select “Use system proxy settings” or test with a manual proxy. Make sure “No proxy” isn't selected by mistake.
4. Check bypass lists: Review “Do not use proxy” and other exception lists in both the browser and the system. A destination domain on one of these lists may connect directly.

For manual setup in Firefox, enter 127.0.0.1 and the actual mixed port as the HTTP proxy, then use the interface option to apply the same HTTP proxy to HTTPS. If you switch to SOCKS v5, check the “Proxy DNS when using SOCKS v5” option. HTTP proxy and SOCKS DNS behavior are not the same.

If the request reaches Clash but matches DIRECT, check the rule mode, matching rules, and proxy group selection. The system proxy can pass a request to Clash without guaranteeing that every website exits through a remote node. A public IP check shows the route for that particular request, not for every browser connection.

Step 4: Check terminal environment variables and tool-specific settings

Terminals usually don't use the proxy automatically just because the system proxy is enabled. Start with the explicit proxy command above: if it works but a regular curl request doesn't, check the current shell's environment variables first. Support for variable name capitalization varies by tool. For example, curl does not accept uppercase HTTP_PROXY as an HTTP proxy variable for security reasons.

PowerShell: Change the current session only

# View existing proxy variables
Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

# Set a proxy for this PowerShell session and its child processes
$env:http_proxy = 'http://127.0.0.1:7890'
$env:https_proxy = 'http://127.0.0.1:7890'

# Test with a new request
curl.exe -v --connect-timeout 10 --max-time 20 https://example.com/ -o NUL

These assignments affect only the current PowerShell process and any child processes it starts. They don't update IDEs, other terminals, or system services that are already running. Windows environment variable names are generally case-insensitive; on macOS and Linux, capitalization matters.

macOS / Linux: Check the current shell

# View proxy-related variables
env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

# Set an HTTP proxy for the current shell
export http_proxy='http://127.0.0.1:7890'
export https_proxy='http://127.0.0.1:7890'

# Make a new request
curl -v --connect-timeout 10 --max-time 20 https://example.com/ -o /dev/null

Using http:// as the value for https_proxy is normal: it means an HTTP proxy will be used to reach an HTTPS destination. If NO_PROXY or no_proxy includes the destination domain, the request may bypass the proxy. Setting it to * may even send all requests from that tool directly. Keep local-address exceptions that you need and change only the entries relevant to this issue.

Environment variables look right, but the program still bypasses the proxy

Not every command-line program supports these variables. For Git, for example, check its dedicated settings and where they come from:

git config --show-origin --get-regexp '.*proxy.*'

If the output shows an old port or a proxy on another machine, note the configuration file and scope before changing the relevant setting. Repository, global, and URL-specific settings can coexist, so changing just one may not fix the issue. An IDE's integrated terminal inherits the environment from when the IDE starts. After changing system environment variables, you may need to fully quit and reopen the IDE.

WSL, Docker containers, virtual machines, and SSH sessions introduce network boundaries: inside them, 127.0.0.1 usually refers to that environment, not the host running Clash. WSL behavior also depends on its network mode and system configuration. First identify an address the environment can reach and the interface the proxy listens on. If you need LAN access, restrict the firewall's allowed sources; never expose the proxy port directly to the public internet.

Step 5: Use SOCKS and logs to distinguish DNS, rules, and node issues

If the local HTTP proxy accepts connections but a particular domain fails, run a SOCKS test on the same mixed port. The command below uses socks5h, which sends the domain to the SOCKS proxy for resolution instead of having curl resolve it locally first.

# Windows PowerShell
curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o NUL

# macOS / Linux
curl -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/ -o /dev/null

For curl, socks5:// and socks5h:// resolve domain names in different places. After the proxy receives a domain, the core continues processing it according to its DNS and routing configuration, so a successful SOCKS test doesn't prove that DNS works everywhere on your computer. Compare the result with the destination domain, matched rule, and proxy chain in the client logs.

Secure DNS in a browser can change how domain names are resolved, but it doesn't mean HTTP proxying is bypassed. Don't treat secure DNS being enabled as proof that the system proxy is broken. Compare results for the same domain before and after a change, and check the actual connection logs before deciding whether to adjust DNS settings.

Step 6: Check TUN only if you need to handle apps that don't use proxies

TUN mode routes traffic through a virtual network interface, making it useful for apps that ignore system proxy settings. It isn't a workaround for an incorrect port. First make sure an explicit proxy command works, then test TUN separately. This helps distinguish a proxy egress problem from a virtual interface capture problem.

1. Confirm that your client and core support TUN. Clients using mihomo may offer different options from older Clash clients; don't paste a random configuration snippet from the web into every version.
2. Follow the client's instructions to install its service or grant the required permissions, then enable TUN. Windows clients may require service mode or administrator privileges, macOS may prompt for authorization, and Linux typically requires network administration permissions.
3. Check the logs for errors creating the virtual interface, insufficient permissions, or failed route updates. An enabled switch doesn't mean every operation succeeded.
4. For troubleshooting, use only one traffic-capture method at a time. Record the original settings, turn off the system proxy, then make a new request to see whether TUN captures it. Restore your original setup when testing is complete.
5. If another VPN, virtual interface, or network filtering tool is running, pause them one at a time and compare results. Don't delete routes or network interfaces outright, and don't change the default route on a machine that depends on remote access.

In mihomo, tun.enable, auto-route, auto-detect-interface, and DNS interception settings each serve a different purpose. Clients may generate or merge configuration at startup, so editing the original subscription file may not change the active values. Check the runtime configuration or client-provided overrides, then restart the core and review the logs.

TUN is also affected by route exclusions, process rules, DNS configuration, and other networking components. It doesn't simply mean “all traffic is proxied when enabled.” If a request reaches the core and a rule sends it DIRECT, it may still use your local connection.

Restore settings and verify in order

When troubleshooting is complete, keep only the proxy method you actually need. Restore temporary environment variables to their original values. The commands below apply only if these variables were unset before testing. If you had a work or development proxy configured, restore the values you recorded instead of removing them.

# PowerShell: Remove variables added temporarily for this test
Remove-Item Env:http_proxy, Env:https_proxy -ErrorAction SilentlyContinue

# macOS / Linux: Remove variables added temporarily for this test
unset http_proxy https_proxy

• Verify the local endpoint first: Explicitly specify the actual mixed port and confirm the request reaches the core.
• Then check the browser: Verify the system proxy, extensions, Firefox's separate settings, and bypass lists.
• Test the terminal separately: Check the current session's environment variables, program settings, and host network boundaries.
• Check routing last: Review the rules and proxy chain, then decide whether to adjust DNS or enable TUN.

When asking for help, include your OS version, client and core versions, actual port, result of the explicit proxy command, and relevant logs from the same time period. Remove subscription URLs, node credentials, API keys, and personal browsing history before sharing. This information is much more useful than simply saying “Clash system proxy isn't working.”

For initial setup, see the system proxy guide. If you've confirmed that requests reach the core but still time out, see connection timeout troubleshooting. Keep a copy of your configuration before changing it, and change one thing at a time so you can identify what affected the result.