Clash System Proxy Not Working? Fix Browser and Terminal Proxy Settings

First, distinguish the system proxy, rule mode, and TUN

Turning on “System Proxy” in the client usually sets the operating system’s HTTP and HTTPS proxy addresses to a local listening port. Whether an app uses those settings depends on the app. Browsers may follow system settings, while terminal tools such as curl, Git, and package managers may use environment variables or their own configuration. So “web pages load, but terminal connections time out” does not necessarily mean the proxy node is down.

In Clash or the mihomo core, “Rule” mode determines how connections that enter the core are routed; “Global” mode usually sends those connections through the global proxy group. Neither mode automatically routes traffic from every process through the core. TUN uses a virtual network interface and routing to capture traffic. It is a separate entry point and is still subject to routing, DNS, process exclusions, and rules.

Establish a baseline: check the local port and an explicit proxy request

Check the port the client is actually listening on

Open the client’s port or inbound settings and note the HTTP, SOCKS, and Mixed ports, along with the core currently in use. Menu names vary by client, so check the actual interface and running configuration. The examples below use 127.0.0.1:7890 as a Mixed port; 7890 is not a universal default. Don’t confuse the control interface port with a proxy port: external-controller provides the management API.

# Port reference only; do not overwrite your full subscription configuration
mixed-port: 7890
allow-lan: false
mode: rule

A Mixed port accepts both HTTP and SOCKS proxy connections. If your configuration only has port: 7890, use it as an HTTP proxy. If it only has socks-port: 7891, use the corresponding SOCKS address. For local access only, you don’t need to enable LAN access to troubleshoot, and you should never expose a proxy listening port to the public internet.

Use one request to separate an inbound issue from an outbound one

Run the curl command below in a macOS or Linux terminal. In Windows PowerShell, use curl.exe instead of curl to avoid parameter parsing issues caused by the legacy PowerShell alias. Temporarily turn off TUN for the test and leave only one client running to avoid interference from multiple entry points.

curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

• Connection refused: The port may be incorrect, the core may not be running, or nothing may be listening on that address.
• The local port accepts the connection, but CONNECT fails or returns 502: check the client logs, node reachability, and the selected proxy group.
• 200 Connection established: This only confirms that the HTTP tunnel was established. Check the TLS handshake and destination response as well.
• A response from the destination site confirms that this explicit proxy request worked. It doesn’t mean other apps are configured correctly.

Browser not using the proxy? Check system settings, extensions, then PAC

Confirm the system proxy settings were actually applied

In Windows 11, go to Settings → Network & internet → Proxy. If the client uses a manual proxy, check that the local address and actual port are shown. If it uses an automatic configuration script, make sure the script URL is still valid. Don’t enter a PAC URL as the manual proxy server address; these are different settings.

In macOS 14, go to System Settings → Network → your active network service → Details → Proxies. Make sure you’ve changed the active connection, such as Wi-Fi, not an Ethernet service that isn’t connected. The HTTP and HTTPS proxy fields usually both use the client’s HTTP or Mixed listening port. Visiting an HTTPS site does not mean the local proxy address must use HTTPS.

Proxy settings vary by Linux desktop environment. In GNOME, check Settings → Network → Network Proxy. Desktop proxy settings aren’t guaranteed to be used by every sandboxed app, background service, or command-line tool, so verify terminal access separately as described below.

Use only one proxy configuration source in the browser

1. In Chrome, open chrome://extensions/; in Edge, open edge://extensions/. Temporarily disable extensions that manage proxies, then fully quit and reopen the browser.
2. In Firefox, go to Settings → General → Network Settings → Settings. Check whether it’s set to “No proxy,” “Use system proxy settings,” or a manual configuration. For troubleshooting, first make it match the system settings.
3. For organization-managed browsers, also check chrome://policy/ or edge://policy/. If a policy enforces a proxy, changing the client’s system proxy settings may not affect browser behavior.
4. Visit the same test URL again with the client’s connection panel open. Check whether the destination domain, matched rule, proxy chain, and traffic appear.

Incognito mode is not a reliable way to isolate proxy settings: some extensions can run in incognito, and system proxy settings still apply. If needed, compare using a temporary browser profile instead of clearing your usual settings.

Check PAC and proxy bypass lists

A PAC script can return a proxy address or DIRECT for different domains. If the script sends a domain direct, its requests never reach the core, so changing Clash routing rules won’t affect them. Save the existing settings, then temporarily switch to a clearly specified manual proxy for comparison. Don’t stack multiple PAC scripts or proxy extensions from unknown sources.

Bypass lists in the system and browser also skip the proxy. Check for the test domain, wildcard domains, local network addresses, and options such as “Don’t use the proxy server for local addresses.” Testing with localhost does not show whether a public internet proxy works, because loopback addresses are usually bypassed separately.

Windows terminal: configure PowerShell and CMD separately

PowerShell, CMD, and terminals built into apps may not use the same proxy settings. The environment variables below affect only the current process and child processes started afterward. Already-running terminals, editors, and background tasks won’t update automatically. Test with temporary settings first; make them permanent only after confirming they work.

Current PowerShell session

$env:http_proxy = "http://127.0.0.1:7890"
$env:https_proxy = "http://127.0.0.1:7890"
$env:no_proxy = "localhost,127.0.0.1,::1"

curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

# Check the current proxy-related environment variables
Get-ChildItem Env: | Where-Object Name -Match 'proxy'

# Remove these settings after testing
Remove-Item Env:http_proxy, Env:https_proxy, Env:no_proxy -ErrorAction SilentlyContinue

Current CMD window

set "http_proxy=http://127.0.0.1:7890"
set "https_proxy=http://127.0.0.1:7890"
set "no_proxy=localhost,127.0.0.1,::1"
curl.exe -I --connect-timeout 10 --max-time 20 https://example.com/

rem Clean up after testing
set "http_proxy="
set "https_proxy="
set "no_proxy="

https_proxy specifies the proxy to use for HTTPS requests; it does not mean the connection to the proxy itself uses TLS. This example uses the CONNECT method through a local HTTP proxy, so the value remains http://127.0.0.1:7890.

macOS and Linux: environment variables, SOCKS, and persistent settings

Test in the current shell first

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"
export no_proxy="localhost,127.0.0.1,::1"

curl -I --connect-timeout 10 --max-time 20 https://example.com/

# Check both cases to rule out stale settings
env | grep -i proxy

# Remove these settings
unset http_proxy https_proxy no_proxy

Programs differ in their support for uppercase and lowercase variable names. curl specifically uses lowercase http_proxy for HTTP proxies, so don’t conclude that the proxy is broken after setting only uppercase HTTP_PROXY. If your environment also has older ALL_PROXY, HTTPS_PROXY, or other case variants, note their values before removing conflicting entries. The domain-matching syntax for no_proxy also varies by tool, so avoid copying complex lists between tools without checking compatibility.

Test SOCKS when you need the proxy to resolve domain names

# Use only if 7890 is actually a Mixed or SOCKS port
curl -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

With curl, socks5h:// sends the destination hostname to the proxy for resolution; socks5:// resolves it locally by default. This difference can help isolate local DNS issues, but it doesn’t mean every program supports the same URL format. If a tool doesn’t support SOCKS environment variables, use its documented HTTP proxy settings.

After confirming it works, add the necessary export lines to ~/.zshrc or ~/.bashrc for your shell, then test in a new terminal. Login shells, desktop apps, and systemd services load environments differently, so changing one file may not affect every process. sudo may also filter environment variables.

In WSL, containers, and virtual machines, 127.0.0.1 usually refers to their own network environment, not necessarily the host. WSL’s network mode affects loopback access; if a connection fails, first check the host address and whether the port is reachable. When access across environments is required, expose only the necessary listener on a trusted network and configure the firewall. Don’t open it to all networks.

Command still failing? Check tool settings, rules, and DNS

Tools such as Git may override environment variables

Git’s global settings, repository settings, and URL-specific proxy settings can produce different results. Check where the setting comes from, then test with a one-off command override to avoid forgetting to restore a change. The test below uses a public repository; you don’t need to include a username or password.

git config --show-origin --get-regexp '.*proxy'
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

Package managers, IDEs, and download tools may also have their own settings. A successful browser test only confirms that the browser’s connection path works; it doesn’t replace testing the tool itself. When sharing logs, redact subscription URLs, access tokens, account details, and proxy addresses that include credentials.

Check the rules only after the request reaches the core

If the target request appears in the connection panel, check the final proxy chain. If it shows DIRECT, check the matched rule and whether the selected proxy group is set to direct connection. If it shows a specific node, check that node’s connectivity to the destination. Successfully importing a subscription doesn’t mean the configuration is active or that every proxy group has a working node selected.

Temporarily switch to Global mode and select a verified node for comparison. If Global mode works but Rule mode doesn’t, check rule matching and group selection first, then restore the original mode. Global mode still only handles connections that reach the core; it can’t fix a browser that ignores the proxy or a terminal without a configured entry point.

If the error clearly points to name resolution, first identify where resolution happens: in the app, the local system, the HTTP proxy, or the SOCKS proxy. Browser Secure DNS settings may change the resolution path, but they aren’t the cause of every browser proxy issue. Don’t start by clearing DNS settings or changing the Fake-IP range, which would change multiple variables at once.

When to use TUN and how to retest

For apps that don’t support explicit proxies, consider TUN in a mihomo client that supports it. Before enabling it, check the client version, core capabilities, permission requirements, and existing VPN routes. TUN may require administrator privileges and can conflict with other virtual network interfaces, routes, or DNS interception. It’s not a default fix to try before checking the port.

1. First, with TUN off, confirm that a request using the local proxy explicitly succeeds. This verifies the node and listening entry point.
2. Restore the browser’s system proxy settings, test the browser separately, and check the domain and rule in the client’s connection log.
3. In a new terminal session, verify the proxy environment variables and check the tool’s own settings and bypass list.
4. Enable TUN only if an app truly doesn’t support a proxy, then observe changes to the default route, DNS, and app connections.
5. After quitting the client, check whether the network recovers. If traffic still points to a local port that is no longer listening, disable the leftover system proxy or clear the variables in the current session.

Keep a troubleshooting record with at least the OS version, client and core versions, listening port, test command, exact error, and matched result from the connection panel. Verifying each step in order—app entry point → local listener → rules and proxy group → node egress → destination—is more effective than repeatedly reinstalling the client. For the basics, see the Quick Start; for field definitions, see the Protocol Reference; and for common questions, visit the Help Center.