System Proxy Enabled but Not Working? A Complete Browser and Terminal Troubleshooting Guide

First, identify which layer is failing

“System proxy enabled” only means that the Clash client attempted to change the operating system’s proxy address to a locally listening port. It does not mean every application will read that setting. Chrome, Edge, and Safari usually follow the system proxy; Firefox can use its own connection settings; curl, Git, npm, Python package managers, and many terminal applications may connect directly. Start by separating browser, terminal, and Clash core issues instead of repeatedly switching nodes.

Before you begin, confirm three things in the client: the configuration is enabled, the proxy group has a working node, and the core is running. Menu names vary slightly between clients; common paths include “Profiles” → “Current Profile,” “Proxies” → “Proxy Groups,” and “Settings” → “System Proxy.” If the logs show no new connections at all, the problem is usually between the application and the local proxy port. If connections appear but time out, show rule errors, or fail at the node, investigate the configuration and remote node next.

Pinpoint the issue from four common symptoms

Verify the Clash listening port and system proxy address

Clash commonly exposes an HTTP port, a SOCKS5 port, and a mixed-port. Older configurations often use 7890 for HTTP and 7891 for SOCKS5. mihomo configurations also frequently enable only mixed-port: 7890, allowing the same port to accept both HTTP and SOCKS5 requests. Ports are not fixed, so use the actual value shown under the client’s “Settings” → “Port Settings” or in the active configuration.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

This configuration means the proxy listens only on 127.0.0.1:7890. The server address in the system proxy settings should also be 127.0.0.1; HTTP and HTTPS can use the same mixed port. Do not enter a subscription node’s remote address in the operating system proxy settings, and do not mistake Clash’s control port for its traffic port.

Windows 11 check path

1. Open “Settings” → “Network & internet” → “Proxy.”
2. Check whether “Use a proxy server” is enabled.
3. Verify that the address is 127.0.0.1 and the port matches Clash’s current listening port.
4. If the client uses an automatic setup script, confirm that the address under “Use setup script” is still valid.
5. After changing the system proxy, close and reopen the affected application so it does not continue using an old connection pool.

macOS check path

1. Open “System Settings” → “Network.”
2. Select the Wi-Fi or Ethernet connection currently in use.
3. Open “Details” → “Proxies.”
4. Verify the address and port for Web Proxy (HTTP), Secure Web Proxy (HTTPS), and SOCKS Proxy.
5. If the Clash client manages these settings, do not leave an old port written by another proxy tool in place.

Test whether the port is listening directly

On Windows, run the following command in PowerShell. If it shows Listen or establishes a TCP connection, the local port is open; if the connection fails, restart the core or resolve the port conflict first.

Test-NetConnection 127.0.0.1 -Port 7890
Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue

On macOS and Linux, use lsof to find the listening process:

lsof -nP -iTCP:7890 -sTCP:LISTEN
nc -vz 127.0.0.1 7890

If the listener is not the current Clash or mihomo process, exit the old client occupying the port before starting the client you use. You can also switch to an unused port, such as 7892, under “Settings” → “Port Settings,” then re-enable the system proxy so the operating system receives the new value.

Troubleshoot browser proxy failures step by step

Chromium-based browsers usually read the operating system proxy, but extensions, enterprise policies, and separate user profiles can change the actual route. Start with a regular window, temporarily disable any proxy-switching extension, and revisit the target page. Private windows do not necessarily disable every extension, so confirm the extension status on the extensions management page.

Chrome and Edge

• In Chrome, open “Settings” → “System” → “Open your computer’s proxy settings” and confirm that it takes you to the current system proxy page.
• In Edge, open “Settings” → “System and performance” → “Open your computer’s proxy settings.”
• Fully quit and relaunch the browser. Closing one tab does not clear existing long-lived connections.
• In the Clash logs, search for the target domain and inspect the rule match. If the record shows DIRECT, check the rule order instead of changing the browser port.
• If the browser is managed by an organization, open chrome://policy or edge://policy in the address bar and check for a forced proxy policy.

Firefox’s independent connection settings

Firefox can ignore the system proxy. Go to “Settings” → “General” → “Network Settings” → “Settings.” You will usually see four options: No proxy, Auto-detect proxy settings, Use system proxy settings, and Manual proxy configuration. To follow Clash’s system proxy, select “Use system proxy settings.” For an independent test, choose manual configuration and enter 127.0.0.1 with the actual port.

For a manual SOCKS5 configuration, enter 127.0.0.1 as the proxy address, use Clash’s SOCKS or mixed port, and select SOCKS v5. If the interface offers “Proxy DNS when using SOCKS v5,” enable it during diagnosis so DNS resolution follows the same route.

Check the bypass list

System proxies commonly bypass localhost, 127.0.0.1, local network addresses, or domains added manually. In Windows, “Don’t use the proxy server for addresses beginning with,” and in macOS, “Bypass proxy settings for these hosts & domains,” can make matching destinations connect directly.

If a domain never appears in the Clash logs, remove that domain and its wildcard entries from the bypass list, then restart the browser. Local network administration pages should generally remain direct, such as a router at 192.168.1.1; do not delete every local-address exception just for testing.

How to handle terminals that bypass the system proxy

A terminal is simply an environment for running commands. Whether a proxy is used depends on the specific program, such as curl, Git, npm, or pip. Many command-line tools read HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY, while some read only lowercase variables or prefer their own configuration files. Even when the browser works, the terminal may need separate proxy settings.

macOS, Linux, Bash, and Zsh

The following sets an HTTP proxy for the current terminal session only. The http:// in the proxy address means that the terminal program connects to the local port using the HTTP proxy protocol; it does not restrict the destination websites to HTTP.

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export NO_PROXY="localhost,127.0.0.1,::1"
export no_proxy="$NO_PROXY"

For SOCKS5, set the following for programs that support this variable:

export ALL_PROXY="socks5h://127.0.0.1:7890"
export all_proxy="$ALL_PROXY"

The h in socks5h means that the SOCKS proxy resolves the domain name, which can reduce mismatches between the local DNS path and the proxy path. Not every program recognizes this format; if unsupported, use the program’s own proxy option.

Windows PowerShell

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5h://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

These variables affect only the current PowerShell window and child processes launched from it. They expire when the window closes, making them useful for diagnosis. To clear them, run:

Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue

Windows Command Prompt

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

When diagnosing temporarily, do not immediately set permanent environment variables. Once an old port is written at the system level, new terminal programs may continue connecting to it even after Clash switches to another port, creating the “system proxy is correct but commands always fail” symptom.

Use curl to isolate proxy, DNS, and destination-site issues

curl is useful for specifying a proxy directly, without relying on the system proxy or current environment variables. Start with an explicit HTTP proxy request and add -v to inspect the connection:

curl -v --proxy http://127.0.0.1:7890 https://example.com/

If the output first shows a connection to 127.0.0.1:7890 and the Clash logs also show a new example.com entry, the terminal-to-Clash path is working. If you see Connection refused, check the port and core first. If the local connection succeeds but the request later times out, inspect the proxy-group node, rule match, and remote connection.

For a SOCKS5 test, use:

curl -v --proxy socks5h://127.0.0.1:7890 https://example.com/

Then run the command without specifying a proxy for comparison:

curl -v https://example.com/

If the explicit proxy succeeds but the ordinary command fails, Clash itself is working and the issue is in environment variables or application settings. If both commands fail, continue with the logs: if the explicit proxy request never appears, the port is probably wrong; if it appears but the connection fails, investigate configuration, rules, or the node path.

Confirm the actual environment variable values

On macOS and Linux, run:

env | grep -i proxy

In PowerShell, run:

Get-ChildItem Env: | Where-Object Name -Match "PROXY"

Look specifically for old addresses, old ports, and duplicate variables. For example, HTTPS_PROXY may point to 127.0.0.1:7890 while lowercase https_proxy still points to 127.0.0.1:1080. Programs use different precedence rules, so duplicate values can produce inconsistent results. During diagnosis, keep the uppercase and lowercase variables identical.

Independent proxy settings for Git, npm, and other tools

If only one tool fails after the environment variables are correct, check its dedicated settings. Dedicated settings are often more consistent than system proxy settings, but they must also be updated when the port changes.

Git

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890
git config --global --get-regexp "http.*proxy"

To remove the global proxy, run:

git config --global --unset http.proxy
git config --global --unset https.proxy

If the repository has its own proxy configuration, enter the repository and run git config --local --get-regexp "http.*proxy". Local configuration takes precedence over global configuration and may cause only one repository to fail.

npm

npm config set proxy http://127.0.0.1:7890
npm config set https-proxy http://127.0.0.1:7890
npm config get proxy
npm config get https-proxy

To clear the settings, use:

npm config delete proxy
npm config delete https-proxy

Prefer one-off commands over permanent changes

During troubleshooting, start with curl’s --proxy option, an application command-line argument, or environment variables for the current session. Once the route is confirmed stable, decide whether to write the setting to ~/.zshrc, ~/.bashrc, or the tool’s configuration. This prevents startup scripts from continuing to inject an old value after the client port changes.

Rules, proxy modes, and false-positive connectivity

Once the request appears in the Clash logs, inspect the rule match. Rule mode evaluates domains, IPs, GeoSite, GeoIP, and fallback rules from top to bottom. When a domain matches DIRECT, it connects directly instead of using the selected proxy node. When troubleshooting one website, confirm the matched proxy group in the logs, then inspect the rule order in the configuration file.

Global mode usually sends requests to the global proxy group and is useful for briefly determining whether rules are the problem. If Rule mode fails but Global mode works, the local port and node are basically available; return to the rule configuration instead of relying on Global mode permanently. Direct mode connects requests directly and cannot verify a proxy node.

A successful latency test does not prove the destination request works

• A latency test visits only the test address predefined by the client and usually cannot represent access to every domain.
• A node showing a latency of a few dozen milliseconds only means that the test request completed at that moment; it does not prove the browser is using that node.
• A proxy group may be set to “Auto,” while the actual request matches a different proxy group.
• Existing browser connections may reuse an old channel. After switching nodes, refresh the page or restart the application before testing again.
• UDP, IPv6, and ordinary TCP requests may take different paths, so one type of test cannot represent all traffic.

When to consider TUN mode

System proxy settings mainly cover programs that actively read HTTP, HTTPS, or SOCKS proxy settings. Some desktop applications, game launchers, system components, and software with its own network stack ignore the system proxy. mihomo’s TUN mode uses a virtual network interface to handle a broader range of IP traffic, making it useful for these applications, but it is not a substitute for correcting a wrong port.

Before enabling TUN, make sure the configuration, node, and rules work in an ordinary proxy test. Then open the client’s “Settings” → “TUN Mode” and enable it. Windows may ask you to allow the client to install or enable a network component; macOS may require approval for a network extension. Watch the logs again afterward to confirm that requests from the previously missing application now appear.

Complete the final troubleshooting sequence

1. Confirm that the active configuration is enabled, the proxy group has selected a working node, and the Clash or mihomo core is running.
2. Read the actual port under “Settings” → “Port Settings”; do not assume it is always 7890.
3. Use Test-NetConnection, lsof, or nc to confirm that the port is listening.
4. Verify that the operating system proxy address is 127.0.0.1 and that the port matches the client.
5. Disable interference from browser proxy extensions, and check Firefox’s independent settings and the system bypass list.
6. Run an explicit test with curl’s --proxy option while watching the Clash logs.
7. If the browser works but the terminal fails, set HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY for the current session.
8. If only one tool, such as Git or npm, fails, check that tool’s dedicated proxy configuration.
9. If the request reaches the logs but fails, check Rule, Global, and Direct modes and the proxy group actually matched.
10. Enable TUN mode only after verifying the ordinary proxy path and confirming that the application completely ignores the system proxy.

A reliable troubleshooting process should always preserve comparison results: whether the browser creates a log entry, whether explicit curl succeeds, whether ordinary curl reads the environment variables, and which rule matches the target domain. Splitting the problem into “application to local port,” “Clash rule processing,” and “node to destination” usually identifies the exact point where an enabled system proxy stops working.