Fix Claude Code Connection Failures and Timeouts With Clash

Why Claude Code Can Fail While Your Browser Works Demystified

If you are able to see a request associated with Claude Code, inspect its destination, matched rule, and selected outbound. This gives you evidence to work with instead of relying on guesses about which node or rule “ought to” be responsible.

When Claude Code cannot connect with Clash running, it is tempting to blame the selected proxy node. That is one possibility, but it is not the only one. The command-line tool, the browser used during sign-in, and other developer tools on your computer may all follow different network paths.

A browser that loads Claude successfully does not prove that Claude Code is using the same proxy, and a Clash dashboard showing an active node does not prove that the CLI’s requests are reaching it.

One more angle:Claude Code needs to contact Anthropic services for auth and model requests. Depending on the version and the action you are performing, it may also make supporting requests for configuration, refreshs, or related features.

Those connections can fail in different ways: a sign-in callback may not full, an API request may time out, or a long response stream may stop after it begins. Treating every one of these symptoms as “the proxy is down” often leads to unnecessary profile changes and makes the original cause harder to find.

Clash clients commonly offer a number of combination of system proxy mode, a local HTTP or mixed port, and TUN mode. A graphical browser typically follows system proxy settings, while a terminal program may need an explicit proxy environment variable or system-level traffic capture.

A detail worth adding:If the CLI opens a direct connection, its request can bypass the proxy even as browser traffic works normally. Conversely, if the CLI is captured by Clash but a rule sends Anthropic traffic to DIRECT, the connection can still fail.

The useful starting point is therefore to identify the failing request and the route it took. Record the exact failure, note whether it appears during login or during a prompt, and check Clash’s connection list at the same time.

Identify the Failure Before Changing Rules at a Glance

If Claude Code works without Clash but fails as soon as Clash is enabled, that is valuable evidence of an interaction between the route and the CLI; it does not on its own mean the entire Clash profile is invalid.

Launch by distinguishing an auth failure from a transport failure. If Claude Code opens a browser to sign in, the browser may finish its part while the CLI waits for a callback or token exchange. If auth succeeds but the first prompt hangs, the problem is more likely to involve an API connection, proxy selection, DNS, or an unstable route.

Said differently:A message such as “connection refused” points toward a listener or port problem; repeated timeouts are more consistent with a route that does not full; and an HTTP failure response means a number of server was reached, even if the request was rejected.

Note the time of a single reproducible attempt. Open Clash’s live connections or logs, launch Claude Code, and then look for new connections around that timestamp. Search for relevant Anthropic hostnames somewhat than assuming that one hostname will represent every phase of the workflow.

The visible hostname can vary by request, and a number of clients may show an IP address instead if DNS handling or sniffing is configured differently. If nothing related appears, the issue is probably before the Clash rule stage: the CLI may not be using the proxy, or the traffic may not be captured.

In practice that means:If a connection does appear, read the matched rule and outbound together. A domain rule can match correctly but select an unavailable proxy group; a group can point to a node that is connected but unable to reach the destination; or a broad rule earlier in the list can capture the request before your intended domain rule is evaluated.

• Browser works, CLI does not: compare system proxy behavior with the CLI’s environment variables or TUN capture.
• CLI appears in Clash but uses DIRECT: inspect rule order, rule providers, and the selected policy group.
• CLI uses the intended proxy but times out: test a different available node and check for packet loss or stalled streams.
• Login fails but prompts previously worked: investigate the browser sign-in and callback path separately from model requests.
• No connection appears in Clash: verify the local listener, proxy variables, and whether TUN is enabled and permitted.

The live connection record is particularly useful here because it answers a practical question: did the request go through the route you expected, or only through a route that looked plausible in the configuration?

Repeat a test only after noting what changed. For example, keep the same prompt and profile, change only the selected outbound, and compare the result. This avoids mistaking a transient service or network issue for a configuration fix.

Check Whether the CLI Uses the Clash Proxy Broken Down

Enable it using the client’s normal controls, approve required permissions, and confirm that the virtual UI is active. Keep system proxy mode or environment variables consistent with your test plan; enabling multiple overlapping capture methods at once can complicate diagnosis.

Worth noting:In system proxy mode, a Clash client writes proxy settings for applications that honor the operating system’s proxy configuration. Numerous graphical applications do, but terminal programs are not guaranteed to.

A shell process may inherit no proxy information at all, or it may have variables left over from an older client, a development container, or a shell startup file. In that case, a browser can use Clash while Claude Code attempts a direct connection.

Check the proxy variables in the same terminal session from which you launch Claude Code. On macOS or Linux, inspect the values of HTTP_PROXY, HTTPS_PROXY, and their lowercase equivalents. In PowerShell, inspect the corresponding environment variables for the current process.

One more angle:Confirm that the address and port match the HTTP-capable listener shown in your Clash client. The port displayed for a SOCKS listener is not interchangeable with an HTTP listener unless the client explicitly provides a compatible mixed port.

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890

For a short diagnostic, you are able to set the variables only in the terminal session used for the test. Replace the example port with the actual HTTP or mixed port configured in your client:

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

On Windows PowerShell, the equivalent temporary setup for the current session is:

A detail worth adding:These examples are diagnostic, not universal configuration instructions. Use the port your client actually displays, and follow the proxy format supported by your installed Claude Code version and runtime.

If the variables were already set, verify that they do not point to an old port or an inactive client. A stale value can produce a refusal on the local machine even when the current Clash dashboard shows a healthy connection.

Also check NO_PROXY and no_proxy. These variables tell a number of applications to skip the proxy for matching hosts. A broad entry can unintentionally exclude a destination you expected to proxy.

Said differently:Do not remove every exception blindly: local development services often have to remain direct. Instead, inspect the entries, remove or narrow only a conflicting exclusion, then launch a fresh CLI process so it inherits the corrected environment.

If explicit proxy variables have no effect, try TUN mode as a controlled alternative, provided your client and operating system support it. TUN captures traffic at the network layer somewhat than depending on each CLI’s proxy support.

Fix Rule Order and the Selected Outbound From the Ground Up

If a prompt begins streaming and then stalls, examine whether the connection remained on the same outbound, whether the node dropped the session, and whether the client logged a reconnect or timeout. A short delay test is not a substitute for observing a sustained connection.

Once a Claude Code connection is visible in Clash, inspect how the profile routes it. Rules are evaluated in order, so a broad match near the top can take effect before a later rule that appears more specific.

In practice that means:For example, a broad geographic, domain-suffix, or catch-all rule may send a request to DIRECT or to a different group before an Anthropic-related rule is reached. The exact rule syntax and provider format depend on your configuration, but the troubleshooting principle is steady: a specific route must appear before a broader rule that would otherwise match first.

Use the connection log to identify the destination and the rule that actually matched. If your profile supports a temporary domain rule, place the relevant destination above conflicting broad rules and direct it to a proxy group that you are able to select by hand.

Avoid adding a long list of guessed domains from an unrelated guide. A rule that does not match the request changes nothing, while an overly broad rule can route unrelated traffic in ways you did not intend.

Worth noting:After adjusting a rule, reload the profile if required by your client. Then verify the result in the live connection list somewhat than assuming the YAML was accepted. Confirm that the request matches the intended rule and that the rule points to the intended policy group.

If the group is a fallback or automatic selection group, inspect its current choice. Health checks may establish that a node responds to a test URL without proving that it can maintain a connection to the service Claude Code needs.

For diagnosis, by hand select a known working node in the group if the client allows it. Keep that selection fixed for the test. Automatic groups can switch nodes between requests, and a long response stream may be interrupted if the selected outbound changes mid-session.

One more angle:Once the CLI works consistently with a fixed node, you are able to restore automatic selection and evaluate whether the group’s health-check behavior is suitable for sustained API traffic.

Do not treat a successful browser test as a full rule check. The browser and terminal may use different DNS behavior, different proxy settings, or different captured connections. Test from Claude Code itself, and inspect the request generated by that test.

Check DNS, TUN, and Platform-Specific Capture Demystified

If you also use a VPN, container network, corporate endpoint agent, or local firewall, test those components separately where permitted. Multiple layers can each appear healthy while their combined routes create a loop, bypass, or blocked connection.

DNS can make a routing problem look like a node problem. The operating system may resolve a hostname before the request reaches Clash, while Mihomo may use its own DNS settings or fake-IP mode. Depending on the profile and the application, the connection log may show a hostname, a resolved address, or a synthetic address.

A detail worth adding:If domain-based rules are not matching as expected, check whether the connection is being associated with the original domain and whether DNS requests are being handled through the path your profile expects.

For a first pass, avoid changing several DNS settings at once. Confirm that the system clock is correct, the active profile has valid DNS settings, and the client is not reporting DNS failures. Then reproduce one CLI request and inspect its connection record.

If the destination appears as an IP address and a domain rule does not match, review the client’s DNS and sniffing behavior using its documentation. A broad DNS rewrite or a second DNS proxy layered on top can introduce more variables than it removes.

Said differently:TUN mode is useful when command-line traffic ignores system proxy settings, but it brings its own checks. The client may need administrator approval, a network extension, a service helper, or permission to create a virtual adapter.

Confirm that the operating system shows the adapter as active and that Clash reports TUN as running. If enabling TUN produces no visible CLI connections, check the client’s capture settings and exclusions before changing domain rules.

On Windows, verify that only one client is trying to manage a TUN adapter or system service during the test. An old client’s service, firewall rule, or virtual adapter can conflict with the active instance. On macOS, approve the requested network extension or VPN configuration through the system dialog, and check that the client’s helper has not been blocked.

In practice that means:On Linux, confirm that the process has the permissions and routing setup required by the selected TUN backend. The exact menus vary, so use the names shown by your client somewhat than following screenshots from a different version.

When testing TUN, temporarily keep the routing policy straightforward: capture the CLI traffic, direct the relevant destination to a known proxy group, and verify the connection record. Once the path works, restore other policy rules one at a time.

A Dependable Test Workflow at a Glance

If you refresh the client or change profiles later, repeat the same basic test. A successful one-time request proves that one route worked at that moment; it does not guarantee that a changed profile or node group will preserve the same behavior.

The goal is not to rebuild your entire profile. Use a small, repeatable sequence that isolates capture, routing, and node behavior. Launch with a harmless connection attempt or a short prompt, avoid running multiple sign-in attempts at once, and keep a note of the time and whichever settings you changed.

1. Record the symptom: note whether failure occurs at sign-in, before the first response, or during streaming, and copy the exact failure text.
2. Check the local listener: confirm Clash is running, the configured HTTP or mixed port is active, and your terminal is not using a stale port.
3. Verify capture: launch one Claude Code request and check whether a corresponding connection appears in Clash.
4. Read the rule and outbound: confirm the matched rule, selected group, and actual node shown for that connection.
5. Change one variable: test a fixed node, a corrected rule, explicit proxy variables, or TUN mode—one at a time.
6. Repeat the same test: compare the result, then remove temporary settings that did not help and document the working path.

Worth noting:If the service returns an auth or account failure, do not try to “fix” it by broadening network access; first confirm that the request reached the service and then handle the account issue separately.

If you have to share logs with support, redact subscription URLs, API keys, auth tokens, account identifiers, and whichever sensitive query strings.

A connection record can expose hostnames and local network details, so share only the minimum necessary. Do not paste credentials into a public issue or place them in a shell command that will be saved in terminal history.

One more angle:After you find a working configuration, make it maintainable. Keep a short note of the listener port, the relevant rule, whether Claude Code relies on environment variables or TUN, and which policy group is used.

Frequently Asked Questions Broken Down

Why does Claude work in my browser but Claude Code times out? at a Glance

Browsers commonly follow the operating system’s proxy settings, while a CLI may not.

Claude Code may need proxy environment variables or TUN capture, and its requests may match different Clash rules than browser traffic. Check whether the CLI connection appears in Clash before changing nodes.

Which proxy port ought to I use for Claude Code? in Short

Use the HTTP or mixed port shown by your active Clash client when configuring an HTTP proxy URL.

Do not assume the commonly seen example port is the one configured on your machine, and do not substitute a SOCKS port unless the application and variable format explicitly support it.

Ought to I enable TUN mode? Decoded

Use TUN when the CLI does not honor the system proxy or explicit proxy settings, and when your client and operating system support it.

A detail worth adding:First confirm that the required permissions are granted and the adapter is active. If environment variables already route the CLI reliably, TUN may not be necessary.

Why does adding an Anthropic rule not fix the timeout? in Practice

For this Claude Code scenario, Clash brings practical client guidance and troubleshooting steps together so you are able to verify the listener, rule match, and outbound without changing everything at once. If you want a clearer starting point for choosing and setting up a Clash client, download Clash and follow the setting that fits your platform.

The rule may be below a broader rule, may not match the destination shown in the connection log, or may point to a group whose selected node cannot full the request.

Check the actual matched rule and outbound for a Claude Code request somewhat than relying on the rule’s presence in the profile.

Said differently:A number of lean proxy setups make terminal routing depend on undocumented shell behavior, while older desktop clients may lack plain visibility into whether a CLI connection was captured or which rule handled it.