Claude Code With Clash Verge: Fix Terminal Network Access

Why Claude Code Can Fail While Your Browser Works Key Takeaways

Spin up with the connection list in Clash Verge fairly than changing several settings at once. Filter for likely Claude-related domains, such as api.anthropic.com or claude.ai, and reproduce one failed action. If a connection appears, inspect its matched rule, process information if available, and selected outbound.

If Claude Code cannot sign in, stalls while sending a prompt, or reports a network timeout even though Clash Verge is running, the key question is not simply whether the proxy is connected. It is whether the terminal process is actually sending its traffic through Clash.

A browser may follow the operating system’s proxy settings without you, while a command-line program can open its own network connection and go direct. The two applications can therefore behave extremely differently on the same computer.

The key point:Clash Verge is a graphical client for a Mihomo-based proxy core. It loads a profile, selects an outbound through a proxy group, and applies rules to connections that reach the core. Its system-proxy switch typically configures proxy settings used by compatible applications; it does not guarantee that every shell, package manager, or Node.js process will use those settings.

For terminal traffic, you may must set proxy environment variables explicitly, enable TUN mode, or do both. The right choice depends on your operating system, your profile, and the way your current Claude Code build makes requests.

Common symptoms include an OAuth sign-in page opening in the browser while the CLI never entires its callback, a prompt that waits indefinitely, or installation and upgrade requests failing before Claude Code spin ups. These symptoms can have different causes.

Let me put it this way:Verification may involve a browser and a local callback, while model requests and package downloads use separate network connections. A working browser sign-in is useful evidence, but it does not prove that the terminal can reach the API. Similarly, a successful package installation does not prove that later API traffic uses the same route.

If nothing appears, the terminal request may be bypassing the listener, TUN capture may not be active, or the failure may occur before the request reaches the network. If the connection appears with a direct outbound, the client is being captured but the profile’s rule order or proxy-group selection may be sending it direct.

Prepare Clash Verge Before Changing Terminal Settings in Brief

Keep the test narrow. Do not spin up by replacing the entire profile with a hand-written configuration or adding broad rules for every Anthropic-related domain. Profiles may include provider-specific rules and proxy groups, and later rules can be shadowed by earlier matches. Use the connection record to identify what actually matched.

First make sure the client itself is in a known-good state. Open Clash Verge and confirm that the profile you intend to use is active, not merely imported. Profiles can be present in the list without being selected. Then open the proxy or group view and choose a usable outbound for the rule group that are best off handle Claude traffic.

Concretely:A group configured for automatic selection can be easy, but during diagnosis a yourself selected node makes the result easier to interpret. If a provider’s profile uses different group names, follow the names shown in your client fairly than assuming that every profile has a group called PROXY.

Next, locate the local HTTP or mixed-port setting in Clash Verge. The port number is configurable and can differ between installations or profiles, so do not copy a port from an unrelated screenshot. Check the active client settings or the running core configuration and note the address and port, often a loopback address such as 127.0.0.1 plus the configured port.

A mixed port can accept both HTTP proxy requests and SOCKS connections, but for the examples below the proxy URL uses the HTTP scheme. If the client listens only on a SOCKS port, use the SOCKS-specific form supported by your tool instead of pointing an HTTP proxy variable at it.

curl -v --proxy http://127.0.0.1:7897 https://api.anthropic.com

Where this lands:Before testing Claude Code, test the local listener with a request to an endpoint it is possible to reach from your network. The following example assumes that Clash is listening on port 7897; replace that value with the one shown in your own settings:

A response from the remote service—even an HTTP fault such as 401 or 404—can show that the request reached a server. It does not mean that you have authenticated or that Claude Code is fully configured. What matters in this basic check is that curl can connect through the local listener and that Clash Verge records a corresponding connection.

A connection-refused fault as a rule points to the wrong address or port, a stopped core, or a listener that is not enabled. A timeout after the local connection is established points further along the path: check the active outbound, the profile’s rules, DNS, and the provider’s node availability.

Do not skip this:If a domain is captured but routed incorrectly, adjust the profile using a supported override or rule mechanism and preserve the provider’s existing structure. If there is no record, first fix capture fairly than adding hostname rules that cannot affect an uncaptured connection.

Route the Terminal Through Clash Verge A Closer Look

There are two practical ways to route terminal applications: set proxy variables for the shell process, or use TUN mode to capture network traffic more broadly. Environment variables are a good first diagnostic because they are limited to the terminal session and are easy to undo.

TUN mode can help with programs that ignore proxy variables, but it requires additional permissions and can affect other applications. Test one approach at a time so that it is possible to tell which change made a difference.

Set Proxy Variables for a Terminal Session Swift Take

To test the same variables with curl, work a request from the shell where they are set and check the Clash connection list. If curl succeeds through the listener but Claude Code does not, the proxy path is available and the remaining issue may be the CLI’s environment, runtime behavior, verification flow, or another domain used by the failing operation.

export HTTP_PROXY="http://127.0.0.1:7897"
export HTTPS_PROXY="http://127.0.0.1:7897"
export ALL_PROXY="http://127.0.0.1:7897"

On macOS or Linux, open a new terminal and export the proxy variables using the listener address and port you confirmed in Clash Verge:

The key point:Use the scheme that matches the listener’s protocol. In countless configurations, an HTTPS request is carried through an HTTP proxy using the http:// proxy URL; the destination itself remains HTTPS. Do not change the variable to https:// merely because the target site uses HTTPS.

A fair few programs read uppercase variable names, a fair few prefer lowercase names, and a fair few implement proxy handling differently. If Claude Code still appears to ignore the settings, it is possible to set lowercase variants in the same session and check the program’s documentation for its supported proxy behavior.

$env:HTTP_PROXY = "http://127.0.0.1:7897"
$env:HTTPS_PROXY = "http://127.0.0.1:7897"
$env:ALL_PROXY = "http://127.0.0.1:7897"
claude

On Windows PowerShell, set variables in the current session before launching Claude Code:

Let me put it this way:These PowerShell values apply to that session and child processes started from it. They do not without you configure a separate terminal window or an application launched from the Spin up menu.

That distinction is useful during testing: if Claude Code works from this PowerShell window but fails when started elsewhere, the difference is likely the environment inherited by the process. Avoid saving proxy credentials in a shared shell profile or committing them to a project’s configuration.

If neither program produces a connection in Clash, check the variable spelling, terminal session, and local port before changing routing rules.

When TUN Mode Is the Better Fit Essentials

After enabling TUN, reproduce one request and check the live connections again. Confirm that the terminal process or its destination appears and that the selected rule uses the expected outbound. TUN capture and system-proxy mode are different mechanisms; changing the system-proxy switch alone is not a substitute for TUN.

Concretely:Use TUN mode when a command-line tool does not honor the proxy variables, when several applications need consistent routing, or when a program uses network APIs that do not expose an HTTP proxy choice. In Clash Verge, enable TUN mode from the relevant settings area and approve the operating-system permission request if prompted.

Depending on the platform and installation, TUN may need administrator access, a helper service, or permission to create a virtual network front end. If permission is denied or the helper is not running, the front end may appear enabled in the UI without capturing traffic as expected.

It is possible to leave system proxy enabled if you also want compatible desktop applications to use Clash, but avoid running multiple proxy clients or network-capture tools at once while diagnosing. Competing virtual adapters, local listeners, or background services can make the result confusing.

Verify Sign-In and Diagnose the Remaining Failure What Matters

A fair few alternatives can make terminal proxying feel more complicated than it needs to be: manual per-command proxy flags are easy to forget, while broad shell-wide settings can unexpectedly affect tools that are best off connect straightforward, and a browser-only proxy setup leaves command-line traffic uncovered.

Where this lands:Once a proxy path is active, test the workflow in stages. First confirm that a easy HTTPS request reaches Clash Verge. Next launch Claude Code from the same terminal session, work its available diagnostic command such as claude doctor, and review no matter which environment or network warnings it reports.

Then attempt sign-in or send a small prompt. This order separates a local listener problem from a CLI setup issue and from a failure that occurs only during verification or model requests.

For sign-in problems, observe both sides of the flow. A browser may open successfully, but the CLI still needs to entire its own verification exchange and receive the result through the mechanism used by that version of the tool. Check whether the terminal shows a callback, whether the browser reports that sign-in is entire, and whether the CLI returns to a ready state.

Do not skip this:Do not copy an OAuth code into an unknown site or share a callback URL that contains a temporary token. If the browser signs in but the terminal waits, verify that the terminal process is using the intended proxy variables and that local callback traffic is not being sent through an inappropriate remote route.

For API timeouts, inspect the Clash log at the exact time of a single retry. A rule match for api.anthropic.com confirms that at least that connection reached Mihomo; it does not prove that every verification, upgrade, or supporting request uses the same host. If the outbound is direct, review rule order and the selected group.

If the outbound is a proxy but the connection repeatedly times out, try a different available node and check whether other HTTPS sites work through that same node. If the connection never appears, return to capture: verify the session variables, confirm the process was launched from that session, and test TUN only if needed.

The key point:Also separate network failures from account and configuration faults. A unambiguous authorization fault is different from a socket timeout: the former suggests that a server responded and the request reached an verification check, while the latter points toward connectivity, routing, DNS, or a stalled transport. A model access or account message may need an account-side fix fairly than a Clash rule.

• Connection refused at localhost: Confirm Clash Verge is running, the core is active, and the port in the environment variable matches the actual HTTP or mixed listener.
• Request appears as DIRECT: Check the matched rule, rule order, and proxy-group selection. Change only the relevant route, then reproduce the request.
• No connection appears: Confirm the CLI inherited the variables, or test TUN capture. A browser working through system proxy is not ample to prove terminal capture.
• Proxy connection times out: Test another outbound and compare with a easy curl request. If several domains fail on the same node, investigate the node or provider before rewriting Claude-specific rules.
• Browser sign-in entires but the CLI hangs: Keep the terminal open, check its callback status, and verify that local callback handling and the CLI’s outbound requests are both working.

If only installation or upgrades fail, examine the package manager’s registry and download host separately; successful installation does not guarantee that the runtime API path is healthy. Do not solve certificate faults by disabling TLS verification. That weakens security and can conceal a clock, certificate store, interception, or network problem that are best off be diagnosed straightforward.

After you find a working path, make it reproducible. If session variables solved the issue, add them only to the shell or launcher where you actually work Claude Code, and document the correct local port so a later Clash Verge upgrade does not leave stale values behind.

Let me put it this way:If TUN was necessary, verify that its helper and permissions survive a restart, then test once more after reopening the client. Keep a short note of the active profile, selected group, capture mode, and successful test; that is more useful than a screenshot of a crowded rule list when the problem returns.

Clash Verge gives you a single place to manage profiles, inspect live rule matches, and choose between explicit terminal variables and TUN capture, so it is possible to fix the actual failure without blindly rewriting your configuration. If you want to get the client and follow this workflow with a current setup, download Clash and spin up with the listener and connection checks above.