Claude Not Working With Clash? Fix Timeouts and Access

Why Claude Fails Through Clash

When Claude does not open while Clash is running, the proxy itself may not be completely broken. A browser can reach ordinary websites while one service still reports a timeout, a blank page, an endless loading spinner, or an error during sign-in. Claude uses several separate connections during one visit: the initial web request, authentication redirects, static assets, API requests, streaming responses, and sometimes telemetry or security checks. If even one required hostname is sent direct, matched by the wrong rule, or routed through an unstable node, the page can appear unavailable.

The first task is to separate a Clash problem from a service, browser, or account problem. Test the same Claude account in a private browser window, then test another browser with extensions disabled. If the service works when Clash is completely stopped but fails as soon as the system proxy or TUN mode is enabled, the routing path deserves attention. If it fails both with and without Clash, changing rules will not solve the actual cause.

There are four especially common causes:

• Incorrect proxy mode. Rule mode may send Claude traffic to DIRECT, while Global mode may work immediately. TUN mode can also be enabled without a valid route or DNS hijack configuration.
• Incomplete domain coverage. The visible page and the API may use different hostnames. A rule that covers only one hostname can leave authentication, static files, or streaming traffic outside the intended proxy group.
• DNS interference. Local DNS may return an unusable address, be hijacked by the network, or resolve a domain differently from the proxy exit region. Fake-IP and redir-host behavior can also expose configuration mistakes.
• An unsuitable node. A node may pass a simple latency test but fail during TLS negotiation, long-lived streaming, or larger HTTPS responses. Geographic availability and exit-IP reputation can also affect access.

The Fastest Checks Before Editing Rules

Start with the least invasive checks. Confirm that the Clash profile is actually active, that a proxy group has a selected node, and that the client is listening on the ports shown in its settings. A downloaded profile can contain proxy groups with no usable members, or a subscription update can replace a previously selected node with an unavailable one.

1. Open the Clash client and verify that the intended profile is enabled. Check the profile's last update time and make sure it does not show a parsing or validation error.
2. Open the Proxies page, select a known working node or the intended URL-test group, and wait for the group to show a concrete member rather than an empty selection.
3. Set the client to Rule mode and enable the system proxy. If you use TUN, test it separately rather than enabling both modes while diagnosing the problem.
4. Open the Clash connections or requests view, reload the Claude page, and watch which policy group receives the requests. The connection list is more useful than guessing from the browser error page.
5. Try an ordinary HTTPS site and one service that you know should use the proxy. This confirms whether the selected node can establish basic TLS connections before you investigate Claude-specific behavior.

On Windows, check the system proxy page and confirm that the address and port match the Clash client. Common HTTP mixed-port values are 7890 or a client-defined alternative, but the displayed value in your installation is authoritative. On macOS, inspect the active network service under System Settings › Network › Wi-Fi or Ethernet › Details › Proxies. On Android, confirm that the VPN permission was granted and that another VPN application is not competing for the same tunnel. A browser extension proxy can override the operating system setting, so disable it during testing.

Also check the client log immediately after one refresh. Messages such as connection refused, timeout during TLS handshake, DNS lookup failure, or reset by peer point to different layers. A generic browser message like ERR_CONNECTION_RESET is not specific enough to identify the cause by itself.

Fix the Mode and Rule Match First

Rule mode is normally the most practical starting point because domestic traffic can remain direct while selected services use a proxy group. The important detail is not simply choosing Rule mode; it is confirming the actual rule that matched the connection. A broad MATCH,DIRECT placed before service-specific rules will bypass the proxy every time. Conversely, a broad proxy rule placed too early can route local resources and unrelated traffic through a slow node.

In the request or connection panel, reload the page and inspect the destination domain, process, rule type, and selected policy. If the visible request is sent to DIRECT, select it and read the matching rule. Fix the profile rather than manually forcing one temporary connection, because a page reload may create several additional connections that follow the same incorrect order.

A narrowly scoped configuration can look like this:

rules:
  - DOMAIN-SUFFIX,example-service.invalid,Claude
  - DOMAIN-SUFFIX,example-auth.invalid,Claude
  - DOMAIN-SUFFIX,example-assets.invalid,Claude
  - MATCH,PROXY

The domains above are placeholders for documentation only. Replace them with the hostnames shown in your own Clash connection log or the service's current technical documentation. Do not copy a random community list without checking it: hostname sets change, and an outdated rule can create both false matches and missing matches. Use DOMAIN-SUFFIX when the root domain and its subdomains should share one policy. Use DOMAIN for one exact hostname, and avoid an overly broad DOMAIN-KEYWORD entry unless you understand its full scope.

Use Global Mode as a Diagnostic Test

Switch to Global mode for one controlled test. If Claude works in Global mode but not in Rule mode, the node is probably capable of reaching the service and the rule set is the primary suspect. Return to Rule mode immediately after the test, then add or correct the missing rules. Global mode is a useful diagnostic because it removes rule selection from the experiment, but it is not automatically the best permanent configuration.

Treat TUN as a Separate Path

TUN mode captures traffic that ignores ordinary system proxy settings, which is helpful for desktop applications and command-line tools. It also introduces more variables: virtual interface permissions, route takeover, DNS hijack, the selected stack, and conflicts with other VPN software. If the browser works with system proxy enabled but fails with TUN enabled, disable TUN and compare the result. On mihomo-based clients, verify that auto-route, auto-detect-interface, and the relevant dns-hijack setting are consistent with your operating system.

Hands-On Procedure: Isolate the Failing Layer

Use this sequence when changing the mode alone does not produce a clear answer. Keep a short note of the selected node, mode, DNS mode, matched rule, and result for each attempt. The process works in Clash Verge, Clash Verge Rev, and other clients built around mihomo, although menu names can vary slightly.

1. Start clean. Close extra VPN applications and proxy extensions. Open a private browser window, enable only the Clash profile you want to test, and clear any stale tab that may have retained a failed connection.
2. Confirm the node. In the Proxies page, choose one stable node manually. Do not begin with a load-balance group, because several nodes may be tested during one session and make the result difficult to interpret.
3. Run a Rule-mode test. Enable the system proxy, keep TUN disabled, open the service, and watch the connection list. Record whether the page request, authentication request, asset request, and streaming request all use the same intended policy.
4. Compare Global mode. Without changing the node, switch only the mode to Global and reload. A successful result here points toward rule coverage or rule ordering; an identical timeout points toward DNS, the node, or the upstream route.
5. Compare a second node. Return to Rule mode and test another node from a different region or provider route. Keep DNS and browser state unchanged so that the node is the only new variable.
6. Test DNS separately. Temporarily compare the client's configured DNS mode with its documented default. If changing DNS alters the matched address or removes lookup failures, inspect the resolver and fake-IP settings rather than adding more proxy rules.
7. Test TUN last. After system proxy mode works, enable TUN and repeat the same page load. If it fails only now, investigate virtual-interface permissions, route takeover, DNS hijack, and conflicts with another VPN.

The result matrix usually narrows the cause quickly:

Check DNS, TLS, Streaming, and Node Quality

DNS problems often look like routing problems. A hostname can resolve locally before Clash has a chance to apply the intended domain rule, or a fake-IP response can be mishandled by an application that expects a real address. In a mihomo configuration, review enable, listen, enhanced-mode, nameserver, and any dns-hijack entry used with TUN. Make sure the DNS listen address is not already occupied by another service, and avoid combining several VPN products that each try to intercept port 53.

For a temporary diagnostic, compare the result with a known reachable resolver path and inspect the Clash DNS log. If a lookup never appears in the Clash log, the application may be using its own resolver or the system DNS is bypassing the client. If the lookup appears but returns an unexpected address, examine upstream selection, fallback filtering, and the exit region. Do not assume that adding more DNS servers automatically improves access; inconsistent answers can make a connection alternate between working and failing addresses.

Next, assess the node beyond its displayed latency. A latency check may use a small request and does not measure TLS negotiation, sustained throughput, or long-lived server-sent events. Claude-style chat interfaces can keep a response open while tokens stream to the browser, so a node that frequently resets idle or long connections may show a page but fail when generating an answer. Test at least two nodes, preferably with different regions, and observe whether the error is a quick refusal or a timeout after several seconds.

• Fast connection refusal: check whether the node is expired, overloaded, blocked by the provider, or incorrectly imported.
• TLS handshake timeout: compare another node and inspect the system clock, certificate handling, and transport settings.
• Page loads but chat submission hangs: inspect the API or streaming connection separately; incomplete rules and connection resets are common causes.
• Works briefly, then disconnects: check node stability, idle timeout behavior, Wi-Fi changes, and whether a second VPN is reclaiming the route.
• Access varies by region: compare exit locations and remember that a proxy IP can be technically reachable yet unsuitable for a service's regional or risk controls.

Keep the system clock accurate as well. A clock that is several minutes wrong can interfere with TLS validation and account authentication, producing misleading access errors. Also update the Clash client and mihomo core through a trusted distribution channel when the installed build is old; newer protocol or operating-system behavior may not be handled correctly by an abandoned core.

Browser State, Authentication, and Permanent Cleanup

After correcting the network path, remove browser variables before judging the result. Private mode is a quick test, but it may block third-party cookies or extensions that the sign-in flow needs. If private mode works while the normal profile fails, disable extensions one by one, remove stale site data for the service, and retry. Browser-level secure DNS, a built-in VPN, or a manually configured proxy can also bypass the path you are observing in Clash.

Do not repeatedly submit credentials while the route is changing. Rapid node switching can create sessions with different source addresses, trigger additional verification, or leave several tabs using old connections. Close duplicate tabs, select one stable node, and begin a fresh sign-in session. If the service reports an account, region, or verification restriction, treat that as a service-side or account-side response rather than trying to solve it with increasingly broad proxy rules.

Once access works, make the configuration maintainable:

• Keep service-specific DOMAIN-SUFFIX rules above the final MATCH rule.
• Assign those rules to a clearly named proxy group instead of embedding one temporary node into every rule.
• Keep a fallback node available, but avoid automatic switching during an active chat if repeated IP changes cause session instability.
• Document whether the working setup uses system proxy or TUN, along with the DNS mode and client version.
• Remove obsolete rules after a profile update and re-check the connection panel when the service changes behavior.

The reliable verification is a complete flow, not merely a successful page load: open the site, complete authentication, submit a short message, wait for the streamed response, and then reload once. Watch the Clash connection list during each stage. If every required request uses the intended policy and the node remains stable, the issue is resolved at the routing layer. If only the service's response fails while all requests match correctly, preserve the logs and compare another node or a direct connection before making further configuration changes.

Restore Access Without Overcomplicating the Profile

Most Claude-through-Clash failures can be reduced to a small decision tree: verify that traffic enters Clash, confirm the selected policy, compare Rule and Global mode, test DNS, and then compare a second node. This order prevents a common mistake—rewriting a complete configuration when the real problem is one empty proxy group, one broad direct rule, or one unstable exit.

Keep the final profile as narrow as the use case requires. A precise service rule, a stable proxy group, a resolver path that is visible in Clash, and a separately tested TUN setup are easier to maintain than a large collection of unverified keywords. When the service or subscription changes, inspect the connection log again instead of assuming yesterday's hostname list still covers every request.