Claude Code With Clash Verge: Setup Guide for Stable Access

Why Claude Code needs deliberate routing

Claude Code is not simply a web page opened in a browser. It is a terminal-based coding assistant that maintains an interactive session while it authenticates, sends prompts, receives streamed responses, reads project context, and sometimes invokes tools or executes approved commands. A browser test that succeeds on an account page therefore proves only that one browser process reached one hostname. It does not prove that the terminal client can complete the entire Claude Code workflow through the same network path.

This distinction matters most during the first sign-in. Claude Code may open a browser for authorization, wait for a callback, and then continue in the terminal with credentials or session data. The browser can inherit a system proxy configuration while the terminal process uses environment variables, direct sockets, or a different DNS resolver. If those paths disagree, authentication may appear to finish successfully while the next prompt returns a timeout, an empty response, or a generic connection error.

Long coding sessions expose a second class of problems. A short HTTPS request can survive an imperfect route because it finishes before a connection is interrupted. An agent conversation may keep a stream open while Claude Code processes a large repository, waits for a model response, or asks for confirmation before running a command. A node that looks fast in a five-second latency test can still be unsuitable for sustained HTTPS streaming when it resets idle connections, changes egress unexpectedly, or suffers packet loss under load.

The practical objective is not to force every hostname through one supposedly perfect proxy. It is to make the traffic path understandable and repeatable. First establish that Clash Verge is actually controlling the terminal process. Then identify the domains visible in Mihomo logs, assign the relevant traffic to a stable policy group, and test sign-in, prompt streaming, and tool-related requests separately.

Before changing configuration, record the operating system, Clash Verge edition, core version, terminal application, and shell. Clash Verge and Clash Verge Rev can expose similar controls while shipping different core builds or UI labels. The same profile may behave differently when launched by Bash, Zsh, PowerShell, an IDE-integrated terminal, or a task runner. Reproducibility begins with knowing which process created the connection.

Install and prepare Clash Verge for Claude Code

Download Clash Verge or Clash Verge Rev from a source you can verify, and prefer a maintained build with a compatible Mihomo core. After installation, open the profile manager and import your subscription or local YAML profile. Do not begin by editing dozens of rules. Confirm that the profile parses successfully, that proxy nodes appear, and that the active core reports a running status before troubleshooting Claude Code.

In the general settings, enable the system proxy only if you want ordinary desktop applications to inherit the operating system's HTTP and SOCKS settings. This switch is useful for many terminal applications, but it is not universal. Some command-line programs honor HTTP_PROXY and HTTPS_PROXY explicitly; others use their own networking library and ignore both the system proxy and shell variables. If you use an IDE terminal, remember that the IDE may have been started before Clash Verge enabled the proxy, so restarting the IDE can be a meaningful test.

For applications that do not respect system proxy settings, consider Mihomo's TUN mode. TUN captures traffic at the network layer and can cover more processes than a conventional system proxy, including clients that never inspect proxy environment variables. It also changes the scope of troubleshooting: DNS behavior, local bypass rules, permission prompts, and conflicts with another VPN become relevant. Enable TUN only after a normal system-proxy test is understood, and disconnect other VPN products while validating it.

Choose one reliable group for development traffic instead of leaving Claude Code on an aggressively rotating automatic group during initial setup. A select group makes the selected outbound obvious in logs. A url-test group can be useful later, but frequent switching may interrupt long-lived streams or make two identical tests use different nodes. Stability is more valuable than a marginally lower synthetic latency while you are proving the setup.

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: AI-DEV
    type: select
    proxies:
      - "Preferred Node"
      - "Backup Node"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,anthropic.com,AI-DEV
  - DOMAIN-SUFFIX,claude.ai,AI-DEV
  - DOMAIN-SUFFIX,claude.com,AI-DEV
  - MATCH,DIRECT

The example is intentionally conservative. Replace node names with values that exist in your profile, and do not assume that every request used by Claude Code will remain under one documented domain forever. Start with observed hostnames and expand only when logs demonstrate a missing match. A broad rule such as DOMAIN-SUFFIX,com,AI-DEV may appear to solve a timeout, but it also sends unrelated services through the same route and makes later diagnosis much harder.

If your provider uses remote rule providers, wait for them to update before judging the profile. A YAML file can load correctly while a provider download remains stale or unavailable. Check the provider's last-update time, inspect whether its rules are enabled, and reload the profile after making changes. When a profile fails to reload, revert to the last known-good version rather than stacking untested edits on top of a parser error.

Connect the terminal to Clash Verge

For a first test, expose the local mixed port shown in Clash Verge and configure the shell that launches Claude Code. On many installations the address is 127.0.0.1:7890, but the port can differ, so copy the value from the application instead of assuming it. A mixed port commonly accepts both HTTP-style proxy requests and SOCKS5 connections, which is convenient when different tools expect different schemes.

# Bash or Zsh: use the local mixed port for an interactive test
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# Optional lowercase forms used by some libraries
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"

# Bypass local addresses and common development endpoints
export NO_PROXY=localhost,127.0.0.1,::1

Windows PowerShell uses a different syntax, although the idea is identical:

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
$env:ALL_PROXY = "socks5://127.0.0.1:7890"
$env:NO_PROXY = "localhost,127.0.0.1,::1"

These variables apply to processes launched from that shell after the variables are set. They do not retroactively modify an already running terminal, IDE, daemon, or background task. Close and reopen the terminal, then verify the environment with the shell's variable inspection command. If Claude Code is launched through an IDE, set the variables in the IDE's integrated terminal or launch configuration as appropriate; setting them in a separate system terminal does not automatically affect the IDE process.

Do not assume that every proxy variable is safe to combine. A program may prefer ALL_PROXY, while another gives precedence to HTTPS_PROXY. An invalid SOCKS URL, a missing scheme, or a typo in the port can create misleading errors. For diagnosis, use one clear configuration first—typically HTTP and HTTPS through the mixed port—then add SOCKS support only when a particular tool requires it.

Once the shell is configured, launch Claude Code from that same shell and watch Clash Verge's connection panel. Filter by recent activity and note the hostname, process if available, rule matched, outbound group, and final node. If no connection appears while Claude Code reports a network failure, the client may not be using the configured proxy at all, or the connection may be handled by a child process with a separate environment.

When logs show a hostname matched DIRECT unexpectedly, inspect rule order. Mihomo evaluates rules from top to bottom, so an earlier GEOIP, IP-CIDR, or provider rule can win before your domain suffix rule is reached. When the hostname looks correct but the IP path is wrong, test with a domain-based rule before adding broad IP ranges. CDN addresses change frequently, and manually maintained address lists tend to age badly.

Validate sign-in, prompts, and long sessions

Validation should proceed from the smallest observable action to the most realistic coding task. First choose a fixed node in the AI-DEV group and open Mihomo's log view. Then start Claude Code without asking it to inspect a large repository. Complete the sign-in flow and record every relevant connection created during that period. The purpose is to separate browser authorization from terminal API traffic rather than to declare success when only the browser page loaded.

Next send a short prompt that produces a compact answer, such as asking Claude Code to explain one function in the current directory. Observe whether the request leaves through the expected group and whether the response arrives as a stream. A successful result confirms more than a browser ping, but it still does not test sustained traffic. Avoid changing nodes between sign-in and this prompt; otherwise you cannot tell whether the route or the credential state caused a difference.

For the third test, ask for a harmless repository summary or a small, reversible edit, and allow enough time for the assistant to read context and return a response. If command execution is involved, review the proposed command before approval. This verifies that the client can maintain its session while waiting for user interaction. It also helps distinguish a model or permission issue from a network issue: a clear permission prompt is not a routing failure, while a stream that dies immediately after approval deserves log inspection.

Interpret status codes carefully. A 401 or 403 means the remote service answered, so DNS resolution, TCP connection, TLS negotiation, and at least part of the proxy path succeeded. Investigate account state, authorization scope, subscription limits, or expired sessions before rebuilding rules. A 429 indicates rate limiting rather than a missing route. By contrast, connection resets, TLS timeouts, failed name resolution, and repeated dial timeouts point toward transport, DNS, node quality, or proxy inheritance.

Long-session failures often come from choosing a group designed for rapid automatic optimization. A url-test group may select a new member after a probe interval, while an existing HTTP/2 or streaming connection remains tied to the old member. That is not automatically a bug, but it can expose nodes with inconsistent behavior. Pin a known-good node for an hour of ordinary work. If reliability improves, reintroduce automation with a longer interval, a sensible tolerance, and a backup group rather than concluding that Claude Code itself is unstable.

DNS deserves attention when the rule log shows unexpected IP-based matches. In fake-IP or redirection-based modes, the displayed destination may differ from the hostname you expected. Do not mix several DNS architectures while testing. Change one variable at a time: first proxy mode, then TUN, then DNS strategy, then rule providers. After each change, reload the profile and repeat the same controlled prompt. This slow method creates evidence; random edits create anecdotes.

Security is part of a stable setup. Keep proxy credentials, API keys, session tokens, and shell history private. Do not paste full logs into public forums without removing usernames, local paths, subscription URLs, node names, authorization headers, and repository content. If you use a shared computer, unset temporary proxy variables when finished or place them in a dedicated shell profile instead of exporting secrets globally. A reliable route is not useful if it exposes the project or account it was meant to protect.

Compared with a browser-only VPN extension, Clash Verge gives you explicit rule evaluation, selectable outbounds, Mihomo logs, system-proxy controls, and optional TUN coverage for terminal processes that browsers cannot represent. A generic desktop VPN can be easier to start, but it often hides whether authentication, model traffic, Git operations, and package downloads took the same path; when Claude Code fails, that lack of visibility slows diagnosis. A command-line proxy wrapper may offer precise environment control, yet it usually lacks Clash Verge's profile management and visual rule verdicts. Clash Verge is not magically faster than every competitor, and it cannot repair an overloaded node, but its combination of observable routing, manual stability, and process coverage makes it a practical fit for terminal-based AI development. Once the three validation stages pass consistently, downloading the client and keeping one known-good development profile is a more sensible next step than repeatedly guessing at proxy variables.