System Proxy Not Working: Browser Uses the Proxy, but Why Doesn't the Terminal?

First, distinguish system proxies, app proxies, and TUN

When you enable Clash Nyanpasu's “System Proxy,” the client writes the local proxy address to the operating system settings. In a typical setup, the proxy server is 127.0.0.1 and the mixed port is 7890. After reading these settings, the browser sends HTTP requests and HTTPS connections established through CONNECT to Clash. Clash then processes the traffic according to the rules, proxy groups, and nodes in the active configuration.

The key point is that a system proxy is a setting for applications to read, not a forced redirect applied by the operating system to every network packet. Desktop browsers such as Chrome, Edge, and Safari usually follow the system proxy, while many command-line programs, game launchers, development tools, and apps with their own networking stacks decide for themselves whether to use it. So “the browser works, but the terminal still connects directly” is not contradictory. It usually means the proxy core and node are working, while the issue lies in how the terminal program obtains proxy settings.

Interception method	Coverage	Common configuration location	Best for
System proxy	Apps that read the operating system's proxy settings	Clash Nyanpasu “Settings” → “System Proxy”	Browsers and standard desktop apps
App proxy	The specified app itself	The app's network settings or launch arguments	Git, browser extensions, and development tools
Environment variables	The current terminal session and processes it starts	HTTP_PROXY、HTTPS_PROXY、ALL_PROXY	curl, package managers, and command-line tools
TUN mode	More traffic routed through a virtual network interface	Clash Nyanpasu “Settings” → “TUN Mode”	Apps that ignore proxy settings and UDP traffic

Step 1: Confirm that the Clash core and local port are working

Do not start by changing system network settings. First confirm in Clash Nyanpasu that the configuration is enabled, the proxy core is running, and the current mode is “Rule,” “Global,” or “Direct.” In Rule mode, some destinations connecting directly is expected. If the test domain matches DIRECT, the request may have entered Clash without using a proxy node for its exit.

Verify the mixed port and listening address

Open “Settings” → “Clash Settings,” or the port settings page for your version, and check mixed-port. A common value is 7890, but imported configurations, port conflicts, or manual changes may set it to 7891, 7897, or another value. Every port used in subsequent commands must match the value shown in the interface.

The default listening address is usually the loopback address 127.0.0.1. If the command runs on this computer, you do not need to enable LAN access, and you should not enter the computer's Wi-Fi IP as the proxy address. Only containers, virtual machines, or other devices on the same LAN require further configuration involving allow-lan, the firewall, and the listening address.

Test the local proxy directly with curl

First bypass the system proxy settings and explicitly send a request through Clash's HTTP proxy:

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

If the response is HTTP/2 200, HTTP/1.1 200 OK, or a normal redirect status from the target site, the local port is reachable and the HTTPS tunnel has been established. If you see Failed to connect or Connection refused, check the port, core status, and local firewall first. If the connection is established but times out, inspect Clash logs for rule matches, node errors, and DNS results.

You can also test the SOCKS5 entry point. A mixed port usually accepts both HTTP and SOCKS5; follow the active configuration:

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

The h in socks5h means the proxy resolves the destination hostname. This is useful for distinguishing local DNS issues from proxy path issues. If the HTTP proxy test succeeds but a direct request fails, you can usually narrow the problem to system settings or the application's configuration.

When the browser works, check extensions and proxy overrides

A working browser only proves that one proxy path currently used by the browser is available; it does not prove that the system proxy is configured correctly. Chrome and Edge generally read the system proxy, but proxy extensions, enterprise policies, launch arguments, and the browser's built-in secure DNS can change the actual path. Firefox also has independent connection settings, with options for the system proxy, a manual proxy, or a direct connection.

Rule out independent browser proxy settings

Temporarily disable the browser extension that switches proxies.
Fully quit the browser and restart it so that background processes do not keep using old connections.
Enable only Clash Nyanpasu's system proxy, then revisit the test page.
Check Clash's connection log for the corresponding domain and review the matched rule.

If the connection stops working immediately after disabling the extension, the extension was connecting directly to 127.0.0.1:7890 rather than relying on the system proxy. Check whether the operating system's proxy address still points to an old port, or whether another proxy app has overridden the system proxy switch.

Check Firefox connection settings

In Firefox, open “Settings” → “General” → “Network Settings” → “Settings.” Choose “Use system proxy settings” to follow the operating system. With “Manual proxy configuration,” set the HTTP and HTTPS proxies to 127.0.0.1 and the actual mixed port. For SOCKS, choose SOCKS v5 and enable DNS over SOCKS if needed.

Identify differences caused by secure DNS

A browser's DNS over HTTPS can use a different resolution path from the terminal. Terminals usually call the system DNS, while browsers may query their own encrypted DNS service. If the browser works but the terminal reports “Could not resolve host,” run nslookup or dig to check system resolution, then use the earlier socks5h request to test proxy-side resolution. The problem may not be the proxy port; it could be system DNS, leftover VPN settings, or network interface priority.

Why doesn't the terminal automatically follow the system proxy?

Because command-line tools run across platforms, they often do not use the desktop operating system's proxy interface. Support for proxy variables also varies across curl, Git, Python, Node.js, and package managers. The most reliable approach is to set environment variables for the current terminal session before launching the target command. Clear them after testing so future port changes do not leave the terminal connected to an old address.

Temporary setup in Windows PowerShell

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

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

Using http:// as the value of HTTPS_PROXY is common and correct: it means the client establishes a CONNECT tunnel through an HTTP proxy, then sends HTTPS traffic through that tunnel. Do not change the scheme to https:// simply because the variable name contains HTTPS, unless the local proxy port explicitly provides a TLS proxy service.

These PowerShell variables affect only the current window and child processes launched from it. They disappear when the window closes. Clear them with:

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

Temporary setup in Windows CMD

set HTTP_PROXY=http://127.0.0.1:7890
set HTTPS_PROXY=http://127.0.0.1:7890
set ALL_PROXY=socks5://127.0.0.1:7890
set NO_PROXY=localhost,127.0.0.1,::1

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

Windows has two proxy mechanisms: WinINET and WinHTTP. Browsers and many desktop programs read the proxy settings in the system interface, while some system services use WinHTTP. Run netsh winhttp show proxy to view the WinHTTP status, but do not import global settings just to fix an ordinary terminal request. First determine which configuration the target program actually reads.

Current-session settings on macOS and Linux

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1"

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

Set the lowercase variables as well to support tools that read only lowercase names:

export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"

Clear the variables from the current session with:

unset HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY
unset http_proxy https_proxy all_proxy no_proxy

If you need to write settings to ~/.zshrc, ~/.bashrc, or another shell configuration file, define functions to enable and disable the proxy instead of hard-coding one port indefinitely. This prevents the terminal from repeatedly waiting for a local proxy that is not running. After editing the file, reopen the terminal or run the appropriate source command.

Check Git, package managers, and development tools separately

Even with correct environment variables, some tools may override them with their own settings. Check all three layers during troubleshooting: system settings, environment variables, and application configuration, while keeping their priority order in mind. Common examples include an old port saved in Git or an npm setting that still points to a disabled proxy address.

Git proxy configuration

View the proxy sources currently read by Git:

git config --show-origin --get-regexp "http\..*proxy|https\..*proxy"

To set a proxy for the current user, run:

git config --global http.proxy http://127.0.0.1:7890
git config --global https.proxy http://127.0.0.1:7890

When switching to environment variables or TUN mode, remove these two entries to prevent a fixed configuration from overriding the new path:

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

npm and pnpm proxy settings

npm config get proxy
npm config get https-proxy
pnpm config get proxy
pnpm config get https-proxy

If the output shows an old address, update it to the current port or remove the setting. Package managers are also affected by registries, certificate chains, DNS, and repository service status, so a “download failed” error cannot be attributed to the proxy switch alone. First use curl against the same repository domain, then inspect verbose command logs to distinguish TCP connection failures, DNS resolution failures, TLS errors, and server-side rate limiting.

127.0.0.1 inside containers and virtual machines

In Docker containers, WSL, and virtual machines, 127.0.0.1 usually refers to their own network environment, not necessarily the host. Copying the host's Clash address unchanged commonly results in a refused connection. Use the host address reachable from that virtual network, enable LAN access in Clash if needed, and configure the operating system firewall. Restrict exposure to trusted networks; never expose it directly to the public internet.

When should you switch to TUN mode?

If the target app supports neither HTTP nor SOCKS proxies and does not read environment variables, a system proxy has limited reach. Typical examples include some game launchers, UDP-based programs, desktop apps that force direct connections, and work environments that need several development tools intercepted at once. In these cases, consider TUN mode: traffic first passes through a virtual network interface and is then handled by the mihomo core according to the rules.

TUN mode changes the interception scope

TUN does not improve node quality or fix incorrect server parameters in a subscription. It mainly changes how traffic enters Clash. Once enabled, TCP or UDP traffic that previously bypassed the system proxy may be intercepted centrally, while rule mode, proxy groups, and node selection continue to follow the active configuration.

In Clash Nyanpasu, open “Settings” → “TUN Mode” to enable the feature. The first activation on Windows may require administrator permission to create a virtual network interface. macOS may request approval for a network extension or system permission, while Linux generally requires the appropriate network management privileges. Menu names vary slightly between client versions; use the TUN switch, network interface status, and core logs as your primary indicators.

Checks to perform before and after enabling TUN

Close other VPNs, accelerators, and similar TUN programs to prevent multiple tools from changing the routing table at the same time.
Record the current system proxy status, mixed port, and DNS settings so you can restore them if needed.
After enabling TUN, confirm that the virtual interface was created successfully and check the core logs for permission errors.
Test the browser and curl first, then test the app that previously could not be intercepted.
Check that LAN addresses, printers, and development servers remain accessible; add direct-connection rules if necessary.

Some clients allow TUN and the system proxy to run at the same time, but during troubleshooting it is best to verify one interception method at a time. Otherwise, the same request may use different entry points, making it difficult to tell whether the issue comes from the system proxy, environment variables, or the virtual interface. After confirming that TUN works, decide whether to keep the system proxy enabled based on your workflow.

Common misdiagnoses involving DNS, rules, and loopback addresses

The terminal reports a hostname resolution failure

If the error occurs before connecting to the proxy, such as Could not resolve host, first identify whether you are using an HTTP proxy or SOCKS. An HTTP CONNECT request usually passes the target hostname to the proxy; socks5:// may resolve it locally, while socks5h:// explicitly requires proxy-side resolution. Comparing both forms quickly shows whether the failure is in system DNS or the proxy path.

The request reaches Clash but shows DIRECT

Rule mode selects a policy by domain, IP, process, or rule set. If the log shows DIRECT, the request was intercepted; the rules simply selected a direct connection. Check the active rule order, the rule set containing the destination domain, and the final fallback rule. Temporarily switching to Global mode can provide a comparison, but restore the original mode afterward so LAN addresses and services in mainland China that should connect directly are not sent through proxy nodes.

localhost behaves unexpectedly after being proxied

Development servers commonly use localhost:3000, 127.0.0.1:5173, or another local port. When setting environment variables, use NO_PROXY to exclude localhost, 127.0.0.1, and ::1; otherwise some tools may send local requests to the proxy. For internal services, you can also add company domains or network ranges in the format supported by the tool, but wildcard and CIDR support varies.

Complete checklist organized by symptom

Browser works, direct curl fails: explicitly specify the proxy with -x. If it succeeds, set environment variables for the terminal or configure the proxy in the tool.
Browser works, but curl with an explicit proxy fails: the browser may be using a different port from an extension. Check the extension settings and Clash's current mixed port.
curl with an explicit proxy succeeds, but environment variables fail: check variable spelling, letter case, the current shell scope, and whether the tool supports those variables.
No target request appears in the connection log: the request has not reached Clash. Check the app configuration, local address, container network, and port usage.
The connection log shows DIRECT: check the rule match result; do not mistake a direct connection for a failed system proxy.
The connection log shows a proxy node error: test other nodes in the proxy group and check subscription updates, node availability, and network connectivity.
Only hostname requests fail while the IP connects: focus on system DNS, Clash DNS settings, and the SOCKS hostname-resolution method.
The app does not support proxy parameters at all: evaluate TUN mode and address virtual-interface permissions, route conflicts, and direct-connection rules for the LAN.

The most effective troubleshooting order is: confirm the local port, test with an explicitly specified proxy, check the system proxy or environment variables, and only then consider TUN. If the browser already works, repeatedly changing nodes or subscriptions is usually unnecessary. Focus on whether the terminal reads the proxy, whether the port matches, where DNS is resolved, and whether the request actually reaches the Clash core.