System Proxy Not Working? Troubleshoot Your Browser and Terminal

First, determine whether traffic reached the core or a rule routed it directly

A system proxy setting registers a proxy address and port with the operating system. It does not route all device traffic through Clash. Whether an app uses this setting depends on its networking stack. Browser extensions, app-specific proxy settings, and terminal environment variables can also change the route traffic takes.

Another common misdiagnosis: the request reached the mihomo core, but a rule routed it to DIRECT. If your public IP hasn't changed, that may be the expected result of the rule—not a system proxy failure. Open the client's Connections page, filter by the target domain, and check the matched rule, policy group, and final outbound connection.

Step 1: Verify the local listening port with an explicit proxy

Don't change rules, subscriptions, or DNS yet. First, send an explicit proxy request to the same destination to check whether the core can accept requests. In Windows PowerShell, use curl.exe to avoid PowerShell 5.1's curl alias interfering with argument parsing. On macOS and Linux, use curl.

# 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

Use --noproxy "" to clear the bypass list for this test and prevent an existing NO_PROXY setting from affecting the result. In the verbose output, check whether the connection reaches 127.0.0.1:7890 and whether the HTTPS CONNECT tunnel is established. Also look for the corresponding entry in the client's Connections or Logs view.

• Connection refused immediately: Check that the core is running, the port is correct, and the listener includes the IPv4 loopback address.
• Local port connects, but the request fails after CONNECT: Check the node, rules, TLS, and destination availability. Don't keep toggling the system proxy setting.
• HTTP 407 received: Check local proxy authentication. Never paste a full command containing a password into public logs.
• Received an HTTP response from the destination: The request reached the local proxy. Check the client's outbound connection log to confirm whether it was forwarded through a remote node.

On Windows, run Get-NetTCPConnection -State Listen -LocalPort 7890 to check for a listener. On macOS, run lsof -nP -iTCP:7890 -sTCP:LISTEN. If another program is using the port, identify the process before closing it or changing the client port.

Browser troubleshooting: system settings, extensions, and custom proxy settings

Chrome and Edge: rule out extensions first

1. Turn on System Proxy in the client, make sure the subscription is enabled, and select a working node in the current policy group.
2. In Chrome, go to Settings → System → Open your computer's proxy settings. In Edge, go to Settings → System and performance and find the computer proxy settings. Wording may vary by version.
3. On Windows 11, go to Settings → Network & internet → Proxy. Windows 10 uses the same path. Check that the manual proxy address and port match the client.
4. Open chrome://extensions/ or edge://extensions/ and temporarily disable extensions that control proxy settings, including those that automatically switch proxy profiles.
5. Fully quit and reopen the browser, then visit the same test URL and check the client's connection log.

Incognito mode isn't a reliable isolation test: extensions may be allowed to run in incognito, and system-level settings still apply. For a better comparison, create a new browser profile without proxy extensions. If the browser says “Managed by your organization,” also check chrome://policy/ or edge://policy/. On managed devices, ask your administrator to adjust the policy.

Firefox: choose the proxy source explicitly

In Firefox, go to Settings → General → Network Settings → Settings. Choose Use system proxy settings to match the system proxy configured by the client. If you choose Manual proxy configuration, configure the HTTP proxy address and port, along with the HTTPS proxy option. Existing SOCKS settings aren't automatically disabled when you turn on the system proxy.

On macOS, go to System Settings → Network → your current connection → Details → Proxies and check Web Proxy and Secure Web Proxy. On Linux, whether desktop proxy settings are used depends on the desktop environment and app. A desktop toggle alone doesn't guarantee that every browser is using the proxy.

Terminal troubleshooting: set HTTP_PROXY and HTTPS_PROXY

Terminal apps usually don't inherit the desktop system proxy. curl, Git, and package managers may also read their own configuration files. If the browser works but the terminal doesn't, set environment variables for the current terminal session first, rather than changing system-wide settings.

Windows PowerShell: current session only

$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 -v --connect-timeout 10 --max-time 20 https://example.com/ -o NUL

# Remove these settings after testing
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY -ErrorAction SilentlyContinue

HTTPS_PROXY specifies which proxy to use for HTTPS requests. It doesn't mean the local proxy URL must start with https://. A common HTTP or mixed listener uses http://127.0.0.1:7890 and forwards HTTPS connections through CONNECT.

macOS and Linux: mind the variable case

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 -v --connect-timeout 10 --max-time 20 https://example.com/ -o /dev/null

# Remove these settings after testing
unset http_proxy https_proxy no_proxy

In case-sensitive environments, curl accepts only lowercase http_proxy for HTTP proxies. Other programs may follow different rules. Start with the minimal setup above, then set uppercase variables if the tool's documentation calls for them. If proxy variables are already set, note their original values and restore them after testing instead of deleting existing working settings.

Environment variables affect only the current process and any child processes started afterward. Already-open IDE terminals, background tasks, and system services won't update automatically. To make the settings persistent, add them to the relevant shell startup file and check them in a new terminal. Don't leave a hard-coded proxy address behind when the proxy is off.

App-specific settings: Git, SOCKS, and isolated environments

Git: check for stale proxy settings before changing global config

Git's HTTP transport can be affected by both environment variables and Git configuration. Check where the settings come from, and look for an old port, a remote proxy address, or URL-specific configuration. Output may contain credentials, so redact it before sharing.

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

# Use a proxy for this Git command only
git -c http.proxy=http://127.0.0.1:7890 ls-remote https://github.com/git/git.git HEAD

The second command tests Git's HTTPS connection without writing to the global config. SSH repository URLs beginning with git@ use a different transport and won't automatically use an HTTP proxy set with http.proxy.

SOCKS: distinguish local DNS from proxy-side DNS

If the client only exposes a SOCKS listener, don't use it as an HTTP port. If you've confirmed that the SOCKS port is 7891, run the command below. If you're using a mixed port, replace it with the actual mixed-port value.

curl --proxy socks5h://127.0.0.1:7891 --noproxy "" --connect-timeout 10 --max-time 20 https://example.com/

In curl, socks5h:// sends the destination hostname to the SOCKS proxy for DNS resolution; socks5:// usually resolves it locally first. This can help isolate local DNS issues, but it doesn't mean every app's DNS traffic is being proxied.

WSL, containers, and virtual machines add another complication: 127.0.0.1 inside them may not point to the host. WSL behaves differently in NAT and mirrored networking modes, so check the host address for your setup. If you need to reach a listening port across networks, review Allow LAN, the bind address, and firewall scope. Don't expose the proxy port directly to the public internet.

TUN mode: handle apps that ignore proxy settings

If an app ignores the system proxy and has no explicit proxy option, consider using TUN mode in a mihomo client. TUN routes IP traffic through a virtual network interface and routing rules, which works at a different layer from the HTTP system proxy. It doesn't make a browser “read system settings more forcefully.”

1. First, use an explicit proxy to confirm that the node, subscription, and rules work. Then export the current configuration and keep a backup for rollback.
2. In the client's Settings, find Service Mode and follow the prompts to install or enable it. Some clients use a different method for elevated privileges; follow the instructions in your version's interface.
3. Turn on TUN mode and check the logs to confirm that the virtual interface and routes were created successfully. Settings such as auto-route, DNS interception, and interface detection should match the configuration generated by the client.
4. First disable other VPNs and similar virtual network adapters to avoid competing default routes. Then test the browser, terminal, LAN devices, and internal sites.
5. If the network goes down, turn off TUN first, then restore the original system proxy settings. Don't rewrite DNS, routes, and rules all at once while troubleshooting.

Whether TUN captures an app depends on routing, exclusions, network interfaces, and permissions. UDP and QUIC traffic also depend on the core configuration and node capabilities. Rules can still select DIRECT when TUN is on. “Traffic entered TUN” and “traffic went through a remote node” are separate checks.

Retest in order: change one variable at a time

When troubleshooting is complete, compare results using the same destination, node, and rule mode. Don't draw conclusions from whether one web page loads or from a single public IP check: caches, bypass lists, and domain-specific routing rules can all affect the result.

• Local proxy: After explicitly specifying 127.0.0.1:7890, does the client log the request?
• Browser: After disabling proxy extensions and confirming the proxy source, does the request appear in the connection log?
• Terminal: After setting environment variables for the current session, can the same request succeed from the target tool?
• Outbound route: Which rule matched the request, and which node did the policy group select?
• Restore settings: After closing the client, do you need to remove terminal proxy variables? After turning off TUN, are LAN access and DNS working again?

When reporting an issue, include the OS version, client and core versions, actual listening port, failed command, time of failure, and relevant log excerpts. Remove subscription URLs, credentials, and sensitive domain names. For more help with rules and DNS, see the Troubleshooting Guide. For a comparison of system proxies, policy groups, and TUN, see the Quick Reference.