Start Here: Identify Where the Failure Occurs
When Claude will not open while Clash is running, the cause is not always a single broken setting. The browser or desktop app may be using a different network path from the one you expect; a rule may send Claude traffic to DIRECT; the selected proxy node may be unavailable; or a DNS, TUN, or system-proxy issue may prevent the connection from reaching the proxy at all. A service-side incident or an account availability restriction can also look like a Clash problem.
Start by recording the exact symptom. A page that never finishes loading usually points to a connection or routing problem. A message such as “connection timed out” suggests that the request did not receive a timely response. A sign-in loop, verification challenge, or access-denied message can instead indicate a browser session, IP reputation, account, or service-side issue. If Claude opens but messages fail to send, the initial page request may work while a later API or streaming connection is failing.
Use the same device, browser, account, and network while testing. Change only one setting at a time, then reload Claude in a private window or a fresh browser session. This makes it easier to tell which change helped and prevents cached pages, old DNS answers, or a different account from confusing the result.
Diagnostic Goal
Determine whether the failure comes from Clash mode, a routing rule, the proxy node, DNS or TUN handling, or Claude’s own availability before making broader configuration changes.
1Check Clash Mode, System Proxy, and Node Connectivity
First confirm that Clash is actually handling the traffic from the browser or Claude app. In a desktop client such as Clash Verge Rev, check that the core is running and that the system proxy is enabled if you are testing with a standard desktop browser. A profile can be selected without being active, and a running dashboard does not by itself prove that the operating system has directed application traffic through Clash.
In Rule mode, the selected rule determines whether a request uses a proxy group, goes directly to the internet, or is rejected. In Global mode, traffic is sent through the selected proxy policy, which can help as a short diagnostic test. Global mode is not necessarily the best permanent setup: it can proxy unrelated traffic, and it will not fix an offline node, a DNS failure, or a service-side restriction. Return to your normal mode after testing.
Open the client’s connection or traffic page while loading Claude. Look for new requests and inspect their matched rule and policy. If no Claude-related connections appear, verify the system proxy, browser proxy settings, and whether the application uses a proxy-aware network stack. If requests appear but are marked DIRECT, or are assigned to an unexpected group, the problem is likely in routing rather than in the Claude website itself.
Test One Known-Good Node
Select a node that has recently worked for ordinary HTTPS browsing. Then open a few unrelated websites and test Claude again. If every site fails, investigate the node, subscription, local network, or client core before editing Claude-specific rules. If other websites work but Claude alone fails, continue to inspect the matched route, DNS behavior, and whether the selected node can reach the service reliably.
Avoid Changing Everything at Once
Do not switch modes, replace DNS servers, change the core, and edit routing rules in one go. A one-change-at-a-time test preserves a clear cause-and-effect trail and makes rollback much safer.
2Inspect Rules for Claude and Anthropic Domains
Rule-based configurations may treat Claude domains differently from the rest of your web traffic. A broad rule placed near the top of the rules list can match a request before a more specific rule below it. For example, a domain rule that sends a large set of services to DIRECT, a catch-all policy group, or a reject rule can override the route you intended. Use the connection log to identify the actual matched rule rather than guessing from the profile name.
Claude’s web experience and supporting resources may use more than one hostname, and service endpoints can change. Avoid copying an unverified list of IP addresses from an old post: provider addresses can rotate, and IP-based rules may affect unrelated services. If the connection log shows that a Claude or Anthropic hostname is being sent to the wrong policy, a domain-suffix rule can be a focused test. Put it before conflicting broad rules and use the name of a proxy group that really exists in your profile.
This example is not a complete configuration and does not create a proxy group. If your profile uses a different group name, substitute that exact name. Some configurations use a group for automatic selection, while others use a specific node. Do not paste the example into a profile without checking its existing policies and rule order.
After editing, save the profile and confirm that the client has reloaded it. Open Claude, then check the connection page again: the relevant requests should now match the intended policy. If the log shows a different hostname, decide whether it belongs to Claude before adding a rule. Avoid broad keyword rules such as DOMAIN-KEYWORD,claude unless you understand their scope; they can match unintended domains and make later debugging harder.
Rule Order Matters
A correct-looking rule can have no effect if an earlier rule already matches the request. Verify the matched rule in Clash’s connection view after every edit, and keep a backup of the original profile.
3Run a Controlled Troubleshooting Test
Use this sequence to separate a routing error from a node, DNS, or application problem. Keep notes about the mode, node, result, and any error message. If a step changes the result, repeat it once to make sure the improvement was not a temporary service fluctuation.
- Confirm the baseline. Check whether Claude works with Clash stopped, if that test is permitted and appropriate for your network. Record the exact error and avoid changing your account or browser settings at the same time.
- Confirm Clash is forwarding traffic. Start the core, enable the relevant system proxy or application proxy setting, and load an unrelated HTTPS site. If it fails too, troubleshoot the client, node, or local network first.
- Try one known-good node. Choose a node that passes the client’s connectivity check and can load other sites. Do not assume that a successful latency test guarantees that every destination is reachable.
- Compare Rule and Global modes briefly. If Claude works only in Global mode, inspect the rule that was selected in Rule mode and correct that route. Restore Rule mode after the comparison unless you specifically need a temporary diagnostic configuration.
- Inspect live connections. Reload Claude and note whether requests appear, which policy handles them, and whether connections repeatedly time out or close. Use this evidence to decide whether to adjust routing or investigate DNS and the node.
- Test a clean browser session. Use a private window or clear site data for Claude, then sign in again if necessary. Do not share session cookies, authentication tokens, or private connection logs when seeking support.
- Change one setting and retest. If evidence points to a wrong route, adjust that route; if name resolution fails, investigate DNS; if only one node fails, test another node. Revert a change that does not improve the result.
Interpret the result rather than simply counting successful page loads. If turning on the system proxy makes other sites work but Claude still fails, the proxy is active and the next checks are the Claude route, node reachability, DNS, and service status. If Claude works in Global mode but not Rule mode, that is strong evidence of a rule or policy-group issue. If all nodes fail for Claude while unrelated sites work, a different node may help, but the issue could also be an IP reputation or availability problem outside your device.
4Check DNS, TUN Mode, and Application Traffic
DNS problems can prevent a browser from resolving a hostname or can send it to an unexpected address. In Clash, verify that DNS is enabled if your profile is intended to use Clash DNS, and check the client’s DNS log for failed lookups. Avoid changing several resolver options based on a generic template: the correct setup depends on your core, profile, network, and whether DNS requests are meant to be proxied. If you recently changed DNS settings, restart or reload the profile and clear the browser’s DNS or site cache before retesting.
When the DNS log shows successful answers but the connection still times out, DNS may not be the main cause. Check whether the connection is assigned to the expected policy, whether the chosen node can reach the destination, and whether the timeout occurs during the initial connection or after the page starts loading. A partially loaded page can indicate that some resources succeed while another hostname or a long-lived connection is blocked.
When to Test TUN
TUN mode captures traffic at the network interface level and can help when an application ignores the operating system’s conventional proxy setting. It may be relevant if a browser works through the system proxy but a separate Claude desktop app does not. TUN is not a general fix for every timeout: it may require administrator permission, a supported core, and correct DNS and routing settings. It can also change how other applications access the network.
Before enabling TUN, confirm that the client and core support it, and close other VPN or network-tunneling software that could compete for traffic. Enable TUN only for a focused comparison, then check whether the application’s requests appear in Clash’s connection view. If the test does not help, turn TUN off and restore the previous network setup. On mobile clients, use the platform’s VPN permission prompt and verify that another VPN profile is not already active.
Keep a Reversible Setup
Export or copy the profile before editing DNS, routing, or TUN settings. Record the original values so you can return to a known-good configuration if the test introduces a new problem.
5Separate Local Problems from Service Availability
Clash can route a connection, but it cannot guarantee that Claude is available for every account, location, or moment. Check Claude’s official service-status information and any notices shown when signing in. Availability, account eligibility, verification requirements, and temporary service incidents can affect access independently of your proxy configuration. Do not treat repeated proxy changes as a remedy for a service-side outage or an account restriction.
IP reputation can also affect a service response. A shared node may be heavily used, blocked, or subject to additional verification even though it passes a speed test. If the same profile works with one node but consistently fails with another, choose a stable node permitted by your provider and review the service’s requirements. Avoid cycling rapidly through many nodes or repeatedly retrying a failed login, which can trigger additional verification or security checks.
If the initial page opens but sending a message fails, test a fresh session and check whether the connection log shows repeated resets or long-running requests. Browser extensions, content blockers, stale cookies, and restrictive network filters can interfere with scripts or streaming responses. Temporarily disable one extension at a time for testing, and restore any protections that are not responsible for the issue.
Before asking for help, collect useful but non-sensitive details: operating system, Clash client and core version, proxy mode, whether other websites work, the matched rule and policy, the type of error, and whether the issue affects one or multiple nodes. Redact subscription URLs, server credentials, account identifiers, cookies, tokens, and private IP information from screenshots or logs. This makes it easier to identify whether the next step belongs in the client, profile, proxy service, or Claude support channel.
In most cases, a short sequence is enough: verify that Clash is active, test one reliable node, inspect the actual matched rule, compare modes briefly, and then investigate DNS or TUN only when the evidence points there. Keep each change reversible and confirm the result in the connection log. That approach is more reliable than replacing an entire profile or copying a large set of unverified rules.