Clash System Proxy Not Working? Troubleshoot Browser and Terminal Settings

Verify the proxy endpoint before checking app settings

Leave your current configuration unchanged and test the local port with a request that explicitly specifies the proxy. Turning on the system proxy only means the client attempts to write a proxy address to the operating system settings. It does not confirm that the core is listening or that every app reads those settings. Browsers, command-line tools, and virtual network adapters use different routes. Troubleshooting them together can make an expected direct connection look like a proxy failure.

Establish three baseline checks

Confirm that the client core is running and the active configuration is enabled. Importing a subscription without switching to that configuration does not mean its rules are loaded.
Note the current HTTP or mixed port, operating mode, and selected policy group node. Turn off TUN while troubleshooting to avoid overlapping traffic paths.
Open the client's Connections and Logs views, then send a request to the same destination. Check the destination domain, matched rule, and resulting policy—not just the toggle's color.

Menu names vary between clients. In a configuration file, port is the HTTP proxy endpoint, socks-port is the SOCKS endpoint, and mixed-port accepts both HTTP and SOCKS. A client may override these values, so check the final runtime configuration rather than just the original subscription. If you only need local access, you do not need to enable “Allow LAN.”

Use curl with an explicit proxy to distinguish port issues from direct-routing rules

In Windows PowerShell, use curl.exe to avoid the Windows PowerShell 5.1 curl alias, which calls Invoke-WebRequest. On macOS and Linux, you can use curl directly. The example.com URL below is only for checking the request path—not for testing geo-unblocking or measuring node speed.

Windows: explicitly specify the HTTP proxy

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

macOS / Linux: retest the same destination

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 bypass list for this request, preventing an existing NO_PROXY value from interfering. Verbose output should first show a connection to 127.0.0.1:7890, followed by a CONNECT example.com:443 request for the HTTPS destination. A successful tunnel means the request reached the local proxy, but check the client's connection log to see whether it used a proxy node or DIRECT.

Result	What it indicates	Next step
Local connection refused	No listener on the port, or the port is incorrect	Check core status, the effective port, and port usage
Request times out after tunnel is established	The endpoint is working, but a later part of the route is not	Check the selected node, destination reachability, and core logs
Client log shows DIRECT	Traffic reached the core, but a rule routed it directly	Check the matched domain rule and policy group
Explicit proxy works, but the browser does not	The browser may use different proxy settings	Check extensions, PAC, and browser-specific settings

On Windows, run Get-NetTCPConnection -LocalPort 7890 -State Listen to see listening connections and their owning processes. On Linux, run ss -ltnp 'sport = :7890'; on macOS, run lsof -nP -iTCP:7890 -sTCP:LISTEN. If another program is using the port, resolve the conflict instead of repeatedly updating the subscription.

Troubleshoot the browser: extensions, system proxy, and PAC

Once the explicit proxy test succeeds, check the browser. Chrome and Edge typically use the system proxy, but extensions, launch arguments, and organization policies can override it. Firefox also has separate connection settings. A browser that loads a page is not necessarily using the proxy: cached pages and direct-routing rules can both be misleading.

First check the settings written to the operating system

Windows 11: Go to Settings → Network & internet → Proxy and check the address and port under “Manual proxy setup.” For a local HTTP endpoint, the address should be 127.0.0.1, with the port matching your client.
macOS 13 and later: Go to System Settings → Network → your current connection → Details → Proxies. Check Web Proxy, Secure Web Proxy, or Automatic Proxy Configuration, and make sure you are editing the network service currently in use.
Firefox: Go to Settings → General → Network Settings → Settings and check whether “Use system proxy settings” is selected. If using a manual proxy, note its address, port, and list of addresses that bypass the proxy.

On Windows, netsh winhttp show proxy displays WinHTTP settings; it does not directly show the user proxy settings a browser uses. Do not assume the client failed to set the system proxy just because this command reports direct access, and do not change the machine-wide WinHTTP configuration to troubleshoot a browser.

Temporarily disable extensions that control the proxy

Open chrome://extensions/ in Chrome or edge://extensions/ in Edge, temporarily disable extensions that can control the proxy, then fully quit and relaunch the browser. Incognito or InPrivate mode may not isolate the source of proxy settings or disable every extension. On a managed device, check chrome://policy/ or edge://policy/; ask your administrator to confirm settings controlled by policy.

If PAC returns DIRECT, the local core never receives the request

PAC is a browser-side proxy selection script, separate from the rules in the Clash core. If PAC returns DIRECT, the browser connects directly. If it returns PROXY 127.0.0.1:7890, the request goes to the local HTTP endpoint. If PAC specifies PROXY 127.0.0.1:7890; DIRECT, the browser may fall back to a direct connection when the proxy is unavailable.

For troubleshooting, temporarily disable the automatic configuration script and use a single manual proxy setting. Restart the browser and repeat the request to the same destination. Note the old PAC URL so you can restore it, and avoid enabling two configurations at once and guessing which takes priority. If the browser request never appears in the client but the explicit curl request does, check the browser bypass list and PAC before changing the rule set.

Troubleshoot the terminal: environment variables and tool settings

Terminal apps do not necessarily use the system proxy. curl, Git, and package managers each have their own configuration sources, so they may connect directly even when the system proxy is on. First check the current terminal's environment variables, then check each tool's settings. Already-running processes usually do not pick up environment variable changes made later.

macOS / Linux: set the proxy for a single command

env | grep -iE '^(http_proxy|https_proxy|all_proxy|no_proxy)='

https_proxy=http://127.0.0.1:7890 http_proxy=http://127.0.0.1:7890 \
curl -v --noproxy "" --max-time 20 https://example.com/ -o /dev/null

Here, https_proxy still starts with http://: it connects to the local HTTP proxy, which then establishes a tunnel to the HTTPS site using CONNECT. Do not change the local proxy URL to https://127.0.0.1:7890 just because the destination uses HTTPS; a standard HTTP proxy port does not provide a TLS proxy endpoint.

curl uses lowercase http_proxy for HTTP proxy environment variables; support for uppercase and lowercase variants of other variables depends on the tool. If NO_PROXY or no_proxy contains the destination domain, an address range, or *, the request may bypass the proxy. Keep necessary local bypass entries and check them one by one instead of permanently clearing the entire list.

PowerShell: set proxy variables for the current session

Get-ChildItem Env: | Where-Object Name -Match '^(HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY)$'

$env:HTTP_PROXY = 'http://127.0.0.1:7890'
$env:HTTPS_PROXY = 'http://127.0.0.1:7890'
curl.exe -v --noproxy "" --max-time 20 https://example.com/ -o NUL

These assignments affect only the current PowerShell session and child processes started afterward. They do not update IDEs, terminal tabs, or background tasks that are already running. To undo the test, use the commands below if these variables were not previously set. If they had values, restore the values you recorded.

Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY -ErrorAction SilentlyContinue

If Git cannot connect, check Git's own proxy settings

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

This command displays proxy-related entries from repository, user, or system-level configuration. Settings scoped to a specific URL may also exist. If there are no matching entries, the command may exit with a nonzero status; that does not mean Git is broken. HTTPS and SSH repositories use different transport methods, so http.proxy will not fix an SSH connection. Check tools such as npm and pip separately, too—a successful curl test does not mean every development tool is using the proxy.

Check rules and DNS: reaching the core does not mean traffic uses a proxy node

When a browser or terminal request appears in the connection list, shift from checking the endpoint to checking the route. In rule mode, rules are matched in order and then passed to the corresponding policy or policy group. A DIRECT match, a direct member selected in a group, or a higher-priority process rule can all keep traffic on your local network.

Find the destination you just tested and note the matched rule, policy chain, and selected node. Do not rely on the policy group name alone.
Confirm the operating mode is not Direct. In rule mode, check the order of rules, especially domain, process, and address rules near the top.
If needed, briefly switch to Global mode and make sure the global policy selects a working proxy node. Repeat the same request, then restore the original mode. Use this test to isolate rule-related issues, not as a permanent fix.
If the core reports a DNS resolution failure after receiving the request, check DNS settings and logs. Do not change the node, DNS, and rule set all at once.

A browser's secure DNS setting can affect the resolution path, but it does not by itself prove that the browser is bypassing the HTTP proxy. With HTTP CONNECT, the browser can pass the destination hostname to the proxy; TUN routing involves DNS interception and domain mapping as well. Use connection logs to determine where the request went rather than inferring it from DNS settings alone. After changing Fake-IP settings, you may also need to reconnect; existing long-lived connections do not reflect the new configuration.

When to enable TUN: for apps that ignore proxy settings

If explicit proxy tests, the browser system proxy, and terminal variables all work, but some apps that ignore proxy settings still connect directly, consider TUN. TUN uses a virtual network adapter and routing to capture matching traffic; it is separate from the system proxy toggle. It is not a workaround for an unavailable node, a broken subscription, or rules that route traffic directly.

Check permissions, routing, and DNS

Permissions and services: Follow the client's prompts to install or start any required services, and confirm that the virtual network adapter is created successfully. Windows, macOS, and Linux use different permission models, so do not apply the same steps to all three.
Route capture: Check settings such as tun.enable and auto-route in the active runtime configuration, along with the logs. The presence of a TUN adapter does not guarantee that every destination or protocol is routed through it.
DNS and conflicts: Check whether another VPN, virtual machine network, or corporate security tool is also changing routes or DNS. Disable one source at a time and note how to restore it, so you do not disrupt your normal work network.

Desktop clients can manage some TUN settings for you. With a standalone mihomo core, you need to verify permissions and runtime settings yourself. If LAN devices become unreachable, DNS times out, or the network goes down after enabling TUN, turn TUN off first and restore the verified system proxy path, then investigate routing and DNS. Do not assume every problem can be fixed by running as administrator.

Narrow down the issue from test results instead of reinstalling repeatedly

The most useful troubleshooting notes cover four things: whether the local endpoint accepts connections, whether the request appears in the core, which policy it matches, and which app fails. Test the same destination with explicit curl, a browser, and the affected app to reduce noise from different sites, caches, and node status.

Explicit curl test also fails: Fix the port, core status, or connection to the next node first.
Explicit curl works, but the browser has no connection log: Check extensions, PAC, and the browser's proxy settings first.
Browser works, but the terminal does not: Check the current process's environment variables, bypass list, and tool-specific settings.
All requests appear in the logs, but traffic still exits directly: Check the rules and selected policy; do not keep changing the system proxy.
Only a specific app connects directly: Check whether it supports proxies, then decide whether to configure it separately or enable TUN.

When sharing troubleshooting details, include your operating system and client and core versions, the actual listening port, and redacted error logs. Remove subscription URLs, access tokens, node passwords, and private destination domains. If the issue persists, see the Troubleshooting guide. Once the proxy is working again, use the Getting Started guide to organize your everyday settings.