Claude Code With Clash: Fix Terminal Access and Routing Issues

Why Claude Code Can Fail While Your Browser Works Demystified

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.

When Claude Code hangs on sign-in, reports a network failure, 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 straight away even while other apps appear to be proxied.

One more angle:That difference explains a common pattern: Claude loads in a browser, but Claude Code cannot authenticate or reach the API. The CLI may have to reach Anthropic’s API, and an auth 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.

A detail worth adding: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.

Launch by identifying where the failure occurs somewhat than changing several settings at once. Does the CLI fail before the browser opens, after the browser login fulls, or only when it launchs generating a response? Does a small request work but a longer one stall? Record the exact failure text and approximate time.

Keep the diagnosis narrow: Use one Claude Code process, one active Clash client, and one known-good profile while testing.

Multiple proxy clients, stale environment variables, or simultaneous TUN adapters can make a straightforward routing issue look like an upstream outage.

Set a Proxy for the Claude Code Terminal at a Glance

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.

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.

Said differently:Do not assume a familiar out of the box 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 numerous 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.

macOS and Linux shells at a Glance

If your proxy listener does not require auth, the local URL ought to 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.

In a Terminal session, set the variables before starting Claude Code.

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

In practice that means:These values affect only the current shell and programs launched from it, which makes them handy for testing without changing the proxy environment for every application.

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 are able to 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.

Worth noting:To check whether the values are present, print them in the same shell from which you will execute the CLI. Do not paste screenshots or terminal output containing proxy credentials into a public support thread.

Windows PowerShell in Short

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.

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

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

This session-only approach is preferable for an initial test. Windows applications inherit environment variables from the process that launchs them, so opening Claude Code from a separate shortcut, IDE, or already-running terminal may not inherit the values you just set.

One more angle: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.

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

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

A response from the service, including an HTTP failure such as a method or path response, can still show that DNS, proxy negotiation, and TLS reached a server. This is not a full Claude Code test and does not prove that auth or every required endpoint works.

Make one change at a time: Test the local proxy variables first, then test Clash mode and routing.

If you switch to TUN, remove or disable other capture tools while testing so you are able to tell which path handled the request.

Verify Clash Mode, Rules, and the Actual Outbound Broken Down

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.

A detail worth adding: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, launch 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 auth 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 delay.

Said differently: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.

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

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:

In practice that means:This is an example, not a full subscription configuration. The group name must exist in the active profile, and additional destinations ought to 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 somewhat than editing a downloaded profile that will be overwritten on refresh.

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 ought to permanently use the same node.

What you observe	Likely area to check	Useful next test
No related connection in Clash	Terminal proxy variables or TUN capture	Check the listener URL and launch Claude Code from the configured shell
Connection is listed as DIRECT	Rule order or active mode	Inspect the matched rule and test a narrow rule above broad fallbacks
Proxy group is selected, but the request fails	Node health, DNS, TLS, or stream stability	Try one known-good node and compare logs during a fresh request
Login works, but generation stalls	Different API route or long-lived connection	Inspect the connection list during generation, not only during sign-in

Worth noting:If it fails in both modes while the connection reaches the selected outbound, inspect the node’s availability, delay, TLS failures, and connection stability. A node that passes a fast 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 ought to be a deliberate diagnostic, not the first response to every timeout. With a number of profiles, the resolver path, fake-IP behavior, or system DNS can affect which destination Clash sees and which rule matches.

Isolate Failures Without Losing a Working Setup From the Ground Up

Clash brings the practical pieces together with plain 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 settings and choose the one that fits your system.

After checking the route, separate local configuration problems from service availability. Confirm that the device has a steady 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 auth, request submission, or response streaming.

One more angle: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 somewhat than assuming Claude Code is the cause.

Direct routing is not on its own better or worse than proxy routing. A number of networks can reach a service straight away with lower delay; 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 somewhat than disabling your entire 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.

A detail worth adding:When the CLI launchs working, keep the setup easy to reverse. Note the mixed or HTTP port you verified, which environment variables you set, the Clash mode, and whichever 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 refreshs. Retest both auth and a longer generation after updating the client, kernel, profile, or operating system; whichever 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 plain which node handled a request.