Start with the failure symptom, not a new configuration
When Claude will not open through Clash, the visible error can be misleading. A browser may show a blank page, stop at a sign-in screen, or load the interface but fail when you send a message. A desktop client or script may instead report a connection reset, a timeout, or an authentication error. These symptoms do not all point to the same cause. The useful first question is whether the request is reaching the proxy node, whether Clash is sending it to that node, and whether Claude is accepting the resulting connection.
Begin with a small comparison. With Clash enabled, open an unrelated site that you know is reachable through your current connection. Then try Claude in a private browser window, if appropriate, without changing several settings at once. If ordinary sites fail too, look first at the active profile, selected proxy, node availability, or local proxy listener. If ordinary sites work but Claude does not, investigate the route and DNS behavior for the failing Claude request. If Claude loads but sign-in or message submission fails, check whether the browser session, account, or service is the problem before rebuilding your Clash configuration.
Also note exactly where the failure occurs. A browser using the operating system proxy can behave differently from a command-line tool, an app with its own networking stack, or a second device on the same Wi-Fi. A successful browser test proves only that the browser’s traffic has a working route; it does not prove that every app is using Clash. Likewise, a failed command-line request does not establish that the system proxy is broken if that program ignores system proxy settings.
- Everything fails: check the profile, node, local port, and whether Clash is running.
- Only Claude fails: inspect the matched rule and the connection entry for the actual hostname.
- The page opens but actions fail: look for additional requests, session problems, DNS inconsistency, or an unstable long-lived connection.
- Only one app fails: confirm that app uses the operating system proxy or is captured by TUN mode.
This distinction prevents a common troubleshooting loop: switching nodes, changing DNS, enabling TUN, and editing rules all at once. When the next test works, you would not know which change mattered; when it still fails, you would have more variables to undo. Keep a short record of the time, application, error, selected mode, selected node, and any connection-log entry. That is enough context to make each following test useful.
Check the selected node and the proxy path first
A rule can be perfectly written and still send Claude through a node that is offline, overloaded, or unsuitable for a long HTTPS session. In your Clash client, confirm that the intended profile is active, that its proxy group has a selected node, and that the node has not been left on an unavailable or stale choice. If the client offers a latency test, use it as a basic reachability signal—not as proof that Claude itself will work. A node can respond to a quick test and still drop sustained traffic or fail to reach a particular service.
Next, check the system proxy control in the client. On desktop clients such as Clash Verge or Clash Verge Rev, starting the core and enabling the system proxy are separate states. The dashboard may show a running core even though the operating system is not directing browser traffic to it. Confirm the system proxy is enabled in the client and that no other proxy or VPN application has replaced the operating system’s proxy address or port. If you temporarily disable another network tool for testing, restore it after the test and avoid running overlapping proxy controls during diagnosis.
Open the client’s connection or log view while loading Claude again. Look for a new entry that corresponds to the browser action, and check its destination hostname, selected rule, outbound group, and result. The exact labels vary by client, but the key evidence is whether the request appears at all and where it goes. A request absent from the log suggests the app may bypass the local proxy, the relevant traffic may not be captured, or the test did not trigger the expected request. A visible request marked DIRECT when you expected a proxy points toward rule matching or rule order. A request assigned to a proxy group but failing at the node points toward the outbound path rather than the browser’s system-proxy toggle.
Do not assume that one hostname represents every part of the experience. Loading a web page can involve the main site, authentication redirects, static resources, and API calls. The names can change as the service evolves, so use the hostnames shown by your own connection log during a failed attempt instead of copying an old, exhaustive domain list from a forum post. If a login page loads but a later request fails, examine that later connection as well.
For an initial isolation test, select a known-working node and use the client’s Global mode briefly, if you are permitted to route that traffic this way. If Claude begins working in Global mode but fails in Rule mode, the node is less likely to be the immediate cause; investigate which rule matched the Claude request and whether a preceding rule sent it somewhere else. Return to Rule mode after the test. Global mode is a diagnostic comparison, not necessarily the best permanent setup, because it can route unrelated traffic through the proxy.
Review rule order, DNS, and TUN only when evidence points there
In Rule mode, Clash evaluates rules in order and applies the first matching rule. A broad rule near the top can therefore capture a request before a more specific rule lower in the list. Inspect the actual matched rule in the connection view before editing a profile. If the request is going to DIRECT, compare the matching hostname and rule type with the policy you intended. If it reaches the expected proxy group, adding another broad domain rule may not address the real fault.
When you manage the configuration, make a minimal, reversible change rather than replacing the whole ruleset. Use the client’s supported override or profile-editing mechanism where available, and preserve the provider’s original profile so you can roll back. A provider may update groups and rules when its subscription refreshes; a manual edit to a generated file can be overwritten or can make future updates confusing. After a change, repeat the same Claude action and check the new connection entry. The evidence should show that the intended request now matches the intended policy.
DNS becomes a stronger suspect when hostname requests behave inconsistently, a page loads only after repeated attempts, or the connection log shows unexpected addresses or failed resolution. Clash clients may offer different DNS and fake-IP behaviors, and the exact settings depend on the client, profile, operating system, and network. Avoid changing several resolver options merely because the word “DNS” appears in an error. First compare the destination hostname, resolution result, and connection outcome in the client’s logs. If the profile is provider-managed, check its DNS guidance before overriding it; conflicting local and profile DNS settings can create a new failure rather than fix the old one.
Use TUN mode when the evidence indicates that an application is bypassing the system proxy or cannot be made to use it. TUN can capture traffic from programs that do not honor ordinary proxy settings, but it may require system permissions and can interact with other VPNs, endpoint security software, or network extensions. Enable it only through the client’s controls, approve the requested permission through the operating system, and test one application at a time. If turning TUN on makes the problem worse, turn it off and restore the previous state before continuing.
For browser-only failures, clear site data only after recording the network evidence and considering whether you need to preserve an active session. A private window can help distinguish a stale cookie or extension issue from a routing issue without immediately deleting saved data. Temporarily test with browser extensions that alter requests disabled, then restore them. Do not enter account credentials into a page reached through an unfamiliar warning, and do not disable certificate checks to make a connection appear successful.
Run a controlled troubleshooting test
Use the following sequence to identify whether the problem is the proxy path, a rule, or an application-specific setting. Keep the same device, network, browser, and Claude action throughout the comparison. If you change node, mode, DNS, and TUN together, the result will not identify which layer was responsible.
- Record the baseline. Note the active Clash profile, mode, selected group and node, whether the system proxy is enabled, and the exact Claude error. Keep private subscription URLs, tokens, and account details out of screenshots or support posts.
- Verify general connectivity. With Clash running, open a site unrelated to Claude. If it also fails, test the selected node and local proxy state before changing Claude-specific rules.
- Watch one Claude request. Load the page or repeat the action that fails while the connection log is visible. Record whether a matching connection appears, which hostname it uses, which rule matched, and whether the connection succeeds or times out.
- Compare Rule and Global mode briefly. If policy and local requirements allow it, use Global mode for one controlled test. If the same action works there, switch back to Rule mode and investigate the matched rule or rule order rather than keeping all traffic global by default.
- Compare a second node. Keep the mode and browser unchanged, change only the selected node, and repeat the action. If one node works and another does not, the evidence points to node reachability, quality, or route differences.
- Check the application path. If the browser works but a desktop app or script fails, verify whether that program uses the system proxy. Test TUN only if the client is not captured through the ordinary proxy path and you can enable it safely.
- Change one setting and retest. Make a single rule or DNS adjustment only when logs support it. Repeat the same action and compare the connection entry with your baseline; revert the change if it does not improve the result.
For a command-line check, use the proxy address and port shown in your own Clash client rather than assuming a default. Some clients expose an HTTP or mixed port; others may use different ports or bindings. A request such as curl with an explicit proxy can help test that listener, but a successful command-line check does not prove that your browser or Claude desktop application uses the same path. Avoid publishing commands containing access tokens, authorization headers, or private URLs.
Once the connection is stable, restore the mode and node you normally use and verify Claude again. If the issue persists across nodes and applications while other proxied services work, check the service’s current status, account access, and any error details shown by Claude. An authentication, account, or service-side rejection is not repaired by rewriting Clash rules. If only one network or device is affected, retain the comparison notes; they make it much easier to isolate a local policy, DNS, or application setting.
Keep the fix narrow and maintainable
A durable fix should explain what changed: for example, the browser was not using the system proxy, the Claude connection matched an unintended DIRECT rule, or one node could not sustain the request. Write down the working mode, node group, and rule adjustment in a private note, but never include credentials or a raw subscription link. After a profile update, verify the connection again because provider rules and client behavior can change. If you use multiple devices, test each one separately; a working desktop proxy setting does not automatically configure a phone, tablet, or another computer.
It is tempting to leave every connection in Global mode or turn on TUN permanently after a single successful test. That may conceal the original cause, route traffic you intended to keep local, increase proxy usage, or conflict with another network tool. Prefer the smallest setting that consistently captures the relevant Claude requests. Keep an eye on the connection log after client updates and profile refreshes, especially if the service changes its hostnames or your provider changes its routing groups.
Some one-click VPN apps make a quick connection test convenient, but may offer little visibility into which request was routed where or why a particular app was bypassed. A Clash client takes more initial attention, yet its selectable groups, rule-based routing, and connection logs let you distinguish a bad node from a misrouted request instead of treating every failure as a generic disconnect. If you want to check the available clients for your device and compare the supported setup options, you can continue from the download page.