Claude Code With Clash: Fix Terminal Access and Routing Issues

Why Claude Code Can Fail While Your Browser Works Explained

When Claude Code hangs on sign-in, reports a network error, or times out while sending a prompt, it is tempting to blame the selected Clash node. But a working browser session does not prove that a terminal process is using the same route. Browsers often follow the operating system’s proxy settings, while command-line tools and runtimes may open their own connections. If Claude Code does not inherit a usable proxy setting—and Clash is not capturing its traffic through TUN mode—the request can leave your computer directly even while other apps appear to be proxied.

That difference explains a common pattern: Claude loads in a browser, but Claude Code cannot authenticate or reach the API. The CLI may need to reach Anthropic’s API, and an authentication flow can involve additional endpoints. DNS lookup, TLS negotiation, login, and a long-running response stream are separate stages; success at one does not guarantee success at the next. A short request may also succeed where a sustained response fails because of an unstable node, an idle timeout, or a connection that changes route mid-session.

Clash only applies the route selected by its active mode and rules to traffic it can see. In Rule mode, a request needs to match the intended proxy rule before a broad direct rule catches it. In Global mode, traffic that reaches Clash uses the selected global proxy group, which is useful as a short diagnostic but may route more than Claude Code. In Direct mode, Clash does not send the request through a proxy node. System Proxy mode alone is not a guarantee that terminal applications will follow the proxy; TUN mode can capture more applications, but it still depends on correct permissions, routing, DNS, and client configuration.

Start by identifying where the failure occurs rather than changing several settings at once. Does the CLI fail before the browser opens, after the browser login completes, or only when it starts generating a response? Does a small request work but a longer one stall? Record the exact error text and approximate time. Then look at Clash’s live connection list or logs around that time. The destination, matched rule, connection type, and selected outbound can reveal whether the request reached Clash and where it went. If no corresponding connection appears, investigate the terminal’s proxy environment or traffic capture before replacing nodes.

Set a Proxy for the Claude Code Terminal in Detail

First, check which local port your Clash client exposes for HTTP and HTTPS proxy traffic. Depending on the client and profile, this may be called the mixed port, HTTP port, or port. Do not assume a familiar default such as 7890 is active: open the client’s settings or configuration and confirm the listener and port. The examples below use 127.0.0.1:7890; replace it with the address and port shown in your own client. If the listener binds to a different address, use that address instead.

For many command-line applications, HTTP_PROXY and HTTPS_PROXY tell the process to use a local HTTP proxy. The proxy URL commonly begins with http:// even when the destination is an HTTPS website: the client asks the proxy to establish a secure connection using the HTTP CONNECT method. This is different from choosing an HTTPS proxy endpoint. Setting ALL_PROXY can be useful for tools that support a SOCKS listener, but do not guess the protocol or port—match the value to a listener that Clash actually provides.

macOS and Linux shells Explained

In a Terminal session, set the variables before starting Claude Code. These values affect only the current shell and programs launched from it, which makes them convenient for testing without changing the proxy environment for every application.

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
claude

If Claude Code was already running, close that process and launch it again from the shell where the variables are set. A running process does not normally acquire environment changes made later in a different terminal. On systems or tools that expect lowercase variable names, you can also set http_proxy and https_proxy to the same values. Avoid setting conflicting uppercase and lowercase values: different libraries may select different variants, making a test difficult to interpret.

To check whether the values are present, print them in the same shell from which you will run the CLI. Do not paste screenshots or terminal output containing proxy credentials into a public support thread. If your proxy listener does not require authentication, the local URL should not contain a username or password. If credentials are required, use a method appropriate to your shell and avoid storing secrets in a shared dotfile or shell history.

Windows PowerShell in Brief

In PowerShell, set the variables in the current session, then start Claude Code from that same window:

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
claude

This session-only approach is preferable for an initial test. Windows applications inherit environment variables from the process that starts them, so opening Claude Code from a separate shortcut, IDE, or already-running terminal may not inherit the values you just set. If the test works, decide whether you need a persistent setting or simply a small launch script that sets the values when required. Persistent user-level variables can affect other developer tools and may be forgotten after you turn Clash off.

For either operating system, test the proxy listener independently from Claude Code. If curl is available, try a request through the local HTTP proxy:

curl -I --proxy http://127.0.0.1:7890 https://api.anthropic.com/

A response from the service, including an HTTP error such as a method or path response, can still show that DNS, proxy negotiation, and TLS reached a server. This is not a complete Claude Code test and does not prove that authentication or every required endpoint works. If the command reports that it cannot connect to the proxy, recheck the Clash listener and port. If it connects through the proxy but Claude Code still fails, compare the CLI’s connection destinations with Clash’s logs and check for a tool-specific proxy setting or an excluded destination.

Verify Clash Mode, Rules, and the Actual Outbound Made Clear

Once the terminal has a proxy setting—or you have enabled TUN capture—confirm what Clash does with a real Claude Code request. Open the client’s connection view, start a fresh CLI command, and filter the live list by a destination shown in the connection details. api.anthropic.com is a useful place to look for API traffic, but an authentication flow may contact other hosts as well. Let the logs tell you which destinations this version of the tool actually uses instead of relying on a hostname list copied from an unrelated setup.

Read the matched-rule and outbound fields together. A destination may appear in the connection list but still use DIRECT; that means Clash saw the connection, but the active rule selected a direct route. A proxy rule may match a group whose current selection is unavailable or has high latency. Conversely, if no connection appears, a rule edit cannot fix the route until the traffic reaches Clash. Check whether the terminal proxy variables point at the running listener, whether the CLI inherited them, and—if you are relying on capture—whether TUN is enabled and permitted by the operating system.

In Rule mode, place a narrowly scoped rule for an observed service hostname above broad fallback rules that could otherwise win first. Rule order matters: a matching catch-all or broad direct rule placed earlier may prevent a later specific rule from taking effect. For example, a profile might use a rule like the following if its proxy group is actually named Claude-Proxy:

rules:
  - DOMAIN,api.anthropic.com,Claude-Proxy

This is an example, not a complete subscription configuration. The group name must exist in the active profile, and additional destinations should only be added when your logs or the product’s current documentation show that they are needed. Do not blindly route every hostname containing a broad vendor keyword: that can send unrelated services through the same node, conceal a rule-order problem, or make later troubleshooting harder. If the profile is provider-managed, use the client’s supported override or rule provider feature rather than editing a downloaded profile that will be overwritten on update.

Use Global mode only as a temporary comparison. If Claude Code works in Global mode but fails in Rule mode, the result points toward a rule, group, or rule-order issue; it does not prove that every service should permanently use the same node. If it fails in both modes while the connection reaches the selected outbound, inspect the node’s availability, latency, TLS errors, and connection stability. A node that passes a quick check may still reset long responses. If the request never appears in the Clash log, revisit process proxy inheritance or TUN capture instead of cycling through every node.

Changing DNS settings should be a deliberate diagnostic, not the first response to every timeout. With some profiles, the resolver path, fake-IP behavior, or system DNS can affect which destination Clash sees and which rule matches. If logs show an unexpected address or a DNS failure, compare the active DNS mode and TUN DNS handling with the profile documentation. Avoid changing DNS, rules, and node selection all at once; otherwise, a successful retry will not tell you which change mattered.

Isolate Failures Without Losing a Working Setup Under the Hood

After checking the route, separate local configuration problems from service availability. Confirm that the device has a stable connection without a captive portal, the operating system clock is correct, the active Clash profile has loaded, and the selected node is currently usable. Check Claude Code’s own output for whether the failure occurs during authentication, request submission, or response streaming. If the same command works through the same node from another machine but not this terminal, focus on local environment inheritance, shell startup files, endpoint exclusions, or conflicting proxy tools. If multiple applications fail through one node, investigate that node or the upstream path rather than assuming Claude Code is the cause.

Direct routing is not automatically better or worse than proxy routing. Some networks can reach a service directly with lower latency; others cannot, or may have policies and service availability constraints that make a direct connection unsuitable. If you want to test DIRECT, do so only where direct access is available and permitted, and change a narrow rule rather than disabling your whole proxy configuration. Likewise, do not interpret a successful proxy connection as a guarantee that an account, region, or service is supported. Follow the service’s current terms and availability guidance, and treat network routing as a connectivity setting—not a way to evade access controls.

When the CLI starts working, keep the setup easy to reverse. Note the mixed or HTTP port you verified, which environment variables you set, the Clash mode, and any rule you added. Remove temporary variables when you no longer need them, especially on shared machines. If you keep a custom rule, document why it exists and check that it remains above the profile’s broad fallback rules after subscription updates. Retest both authentication and a longer generation after updating the client, kernel, profile, or operating system; any of those can change how traffic is captured or routed.

Compared with browser-only proxy extensions or ad hoc shell wrappers, a GUI-less terminal setup can be harder to inspect: one solution may configure environment variables but leave Clash rules opaque, while another may capture traffic without making it clear which node handled a request. Clash brings the practical pieces together with clear client guidance, routing explanations, and troubleshooting steps that help you verify the actual path instead of guessing. If you want a client workflow that makes checking profiles, modes, and connections more straightforward, browse the download options and choose the one that fits your system.