Browser works through the proxy, but the terminal does not? System proxy not working: troubleshoot by scenario

First, identify which layer is failing

Clash, Clash Meta (mihomo), and desktop clients built on these cores typically listen locally on HTTP, SOCKS5, or mixed proxy ports. The “system proxy” switch in a client only changes the operating system’s proxy address to a local listener such as 127.0.0.1:7890. Whether an application reads this setting, whether the request reaches the core, and which policy is ultimately selected are three separate steps.

So, “system proxy enabled” does not mean every program will automatically use Clash. Browsers such as Chrome and Edge usually follow the system proxy; Firefox can use its own proxy settings; curl, Git, npm, Python package managers, and remote terminals often read environment variables or their own configuration files. Games, UDP applications, and some store apps may also bypass traditional HTTP system proxies and require TUN mode to take over traffic.

Use four outcomes to narrow the scope quickly

Step 1: Verify the port Clash is actually listening on

Default ports vary between clients. Common configurations use 7890 for HTTP or mixed traffic, 7891 for SOCKS5, and 9090 for the external control port. Port 9090 is used by the control panel to call the API, not for web proxying; pointing the system proxy to it will fail. Always follow the client’s current settings and configuration file rather than guessing from common port numbers.

In a graphical client, open “Settings” → “Preferences” or “Settings” → “Network”, then check the HTTP, SOCKS, and Mixed Port values. If the configuration contains only mixed-port: 7890, both HTTP and SOCKS5 can connect through 7890. If it separately defines port and socks-port, match the protocol when connecting.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

Test the local HTTP proxy directly

Explicitly specifying a proxy in the terminal bypasses the system proxy setting and verifies the Clash port independently. The command below accesses a standard test page and should normally return HTTP response headers; adding -v also shows whether the connection is going to 127.0.0.1:7890.

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

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

If the explicit proxy works but the command without -x fails, the core, node, and port are probably fine; focus on the system proxy or terminal configuration. If the explicit proxy returns Connection refused, the port is usually wrong, the core is not running, or local security software is blocking the listener. If the local port connects but a later timeout appears, continue with the node, rules, and DNS.

Check whether the port is listening

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp | grep 7890

The output should include a local listening address. For local-only use, listening on 127.0.0.1:7890 is normal; enable allow-lan and check the firewall only when other devices on the LAN need to connect. Do not expose a LAN listener just to fix a browser issue on the same machine.

Browser bypasses the proxy: check overrides and proxy sources

Chrome and Edge usually read the system proxy on Windows and macOS, but extensions, enterprise policies, launch arguments, and security software can override it. Firefox has separate network settings with options for “No proxy”, “Use system proxy settings”, or “Manual proxy configuration”. Different browser results are often caused by these different configuration sources.

Chrome and Edge troubleshooting order

1. Fully quit the browser and reopen it so an old connection pool does not continue reusing direct connections.
2. Open the browser’s “Settings” → “System and performance” → “Open your computer’s proxy settings”, then confirm the address is 127.0.0.1 and the port matches Clash.
3. Temporarily disable extensions that manage proxies, especially those that switch PAC files, force a proxy, or use proxy profiles.
4. Check the shortcut or launch script for parameters such as --proxy-server and --no-proxy-server.
5. Open the Clash connection list or live logs, then refresh the page and check whether the target domain appears.

If no new connection appears in the browser logs at all, the request has not reached Clash; continue checking the system proxy or browser overrides. If a connection appears but the policy is DIRECT, the system proxy is working and the current rules simply allow that domain to connect directly. Check the rule match instead of repeatedly toggling the system proxy.

Firefox uses its own proxy configuration

In Firefox, open “Settings” → “General” → “Network Settings” → “Settings”. To follow Clash’s system proxy, select “Use system proxy settings”. For “Manual proxy configuration”, set the HTTP proxy to 127.0.0.1 and the port to 7890, then enter the actual SOCKS host and port if needed. With SOCKS5, also confirm “Proxy DNS when using SOCKS v5” if DNS queries should be resolved through the proxy.

Terminal bypasses the proxy: set environment variables instead of only enabling the system proxy

Terminal programs on macOS and Linux generally do not share one unified desktop proxy setting. On Windows, PowerShell commands, curl.exe, WSL, and development tools also behave differently. The most reliable test is to set proxy environment variables for the current terminal session and then run the request.

Current macOS and Linux session

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

curl -I https://example.com/

Using http:// as the value of https_proxy is not a contradiction: it means HTTPS sites use an HTTP proxy to establish a CONNECT tunnel. In socks5h, the h means the SOCKS proxy resolves the domain name, which can avoid mismatches between local DNS and the proxy exit.

To affect only one command, put the variables before the command. After confirming the result, decide whether to add them to ~/.zshrc, ~/.bashrc, or a project script. Persisting them in a startup file means the terminal will still try to connect to the local port when Clash is stopped, so prepare unset commands as well.

https_proxy=http://127.0.0.1:7890 curl -I https://example.com/

unset http_proxy
unset https_proxy
unset all_proxy

Current Windows PowerShell session

$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"

curl.exe -I https://example.com/

In older Windows PowerShell, curl may be an alias for Invoke-WebRequest, whose arguments behave differently from standard curl. During troubleshooting, explicitly run curl.exe and use curl.exe --version to identify the actual program. The environment variables expire when the current PowerShell window is closed.

WSL needs a reachable Windows host address

WSL2 runs on a separate virtual network, so 127.0.0.1 inside WSL does not necessarily refer to Clash’s listener on Windows. First confirm that the client allows LAN connections, then query the default gateway from WSL and use that address as the proxy host. Behavior varies by WSL network mode, so do not blindly copy a fixed private IP.

ip route | awk '/default/ {print $3}'

export https_proxy=http://Windows host address:7890
curl -I https://example.com/

If WSL can reach the Windows host but the port is refused, check whether Clash is listening only on 127.0.0.1, whether LAN access is enabled, and whether Windows Firewall allows the relevant private network. After testing, restore local-only listening to reduce unnecessary LAN exposure.

Git, npm, and development tools need separate checks

After environment variables are set, some tools may still prioritize their own configuration. The reverse can also happen: the system proxy is off, but an old proxy saved in Git or npm still points to 7890, causing every request to fail after Clash exits. Check both missing settings and stale settings.

View, set, and clear the Git proxy

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

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 --unset http.proxy
git config --global --unset https.proxy

Also run git config --show-origin --get-regexp proxy to see where the settings come from. Project-level .git/config, user-level, and system-level configuration can coexist; a higher-priority project setting overrides the global configuration. SSH-style remote URLs do not use Git’s HTTP proxy. Configure SSH’s ProxyCommand or test with an HTTPS URL instead.

npm and other package managers

npm config get proxy
npm config get https-proxy

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

npm config delete proxy
npm config delete https-proxy

pnpm, Yarn, pip, Maven, and Docker may read environment variables or maintain their own settings. If the browser works but dependency installation times out, start with the tool’s verbose logs and confirm whether it is connecting to the target domain, a mirror, or an old proxy port. Inside a container, 127.0.0.1 refers to the container itself, not the host’s Clash instance.

Requests reach Clash but still fail: check rules, DNS, and nodes

Once the target domain appears in the live logs, the system proxy step is complete. Break down subsequent failures using the logs: did the rules select the expected policy group, did that group choose a working node, did DNS return the right address, and did the remote connection time out? Calling every failure “proxy not working” leads to repeated actions in the wrong place.

Use log fields to identify the next direction

• DIRECT: The request reached the core and was classified as direct by the rules. Check rule order, rule-set updates, and the current mode.
• REJECT: The request matched a reject rule. Check whether the domain is blocked by an advertising or privacy rule set.
• dial tcp timeout: The local port accepted the request, but the target or node connection timed out. Check node latency, the exit network, and the firewall.
• connection refused: The destination actively refused the connection. The node service port, destination service, or local port may be incorrect.
• dns resolve failed: DNS resolution failed. Check the DNS server, Fake IP settings, DoH reachability, and rules.

For testing, temporarily switch the client to Global mode and choose a verified working node for comparison. If Global mode works but Rule mode does not, focus on rule matching; if both fail, focus on the node, subscription configuration, and network connection. Switch back to Rule mode after testing instead of treating Global mode as a permanent fix.

When to switch to TUN mode

The system proxy mainly serves applications that explicitly support HTTP or SOCKS proxies. Game launchers, some desktop software, UDP traffic, and programs that force direct connections may ignore the system proxy entirely. Those applications can still connect directly even when the browser works. TUN mode takes over traffic at the network layer through a virtual network adapter, usually covering more traffic, but it requires administrator permissions and adds DNS, routing, and exclusion-rule configuration.

TUN is worth trying first when an application has no proxy settings, persistently bypasses the system proxy, needs UDP support, or when multiple command-line tools should follow Clash rules consistently. For browsers and a small number of development tools, the system proxy plus environment variables is usually clearer and easier to control per application.

Check these four items before enabling TUN

1. Confirm that the client uses a mihomo core with TUN support and has permission to create the required virtual network adapter.
2. Record the current DNS settings so layered system DNS, browser DoH, and Clash DNS do not make troubleshooting harder.
3. Add LAN addresses, printers, development servers, and local services to direct-connection rules where necessary.
4. Disable other VPNs and virtual network tools for a single-variable test, preventing them from overriding the default route and DNS.

If all network access stops immediately after enabling TUN, disable TUN first to restore connectivity, then inspect the core logs and virtual adapter status. Do not change the subscription, DNS, rules, and system firewall at the same time; change one item per test and record before-and-after results to identify the real failure point.

Complete a full troubleshooting pass in order

1. Confirm that the Clash core is running, the current configuration loaded successfully, and the policy group has selected a reachable node.
2. In “Settings” → “Preferences”, verify the mixed, HTTP, or SOCKS5 port. Do not mistake control port 9090 for a proxy port.
3. Use curl -x with 127.0.0.1:7890 explicitly specified to determine whether the local proxy port is available.
4. Check the operating system’s proxy address and port, then inspect browser extensions, Firefox’s independent proxy settings, and launch parameters.
5. Set http_proxy, https_proxy, or all_proxy for the current terminal session and repeat the same request.
6. Check separate proxy settings saved by Git, npm, and other tools, and remove obsolete ports.
7. Watch Clash live logs. No connection record means the investigation should return to the application; a record means continuing with rules, DNS, and the node.
8. Only after confirming that the target program bypasses the system proxy should you evaluate enabling TUN mode.

When the browser works but the terminal does not, the most common cause is not a Clash core failure but the different ways these applications read proxy settings. First verify the port with an explicit proxy command, then handle browser overrides and terminal environment variables separately to narrow the scope quickly. Only after the request reaches the core should rules, DNS, nodes, and TUN become the next checks.