The symptom: claude hangs in the terminal while the browser works fine

The failure mode is specific enough to be memorable. You have Clash running, your browser routes correctly, and perhaps you can even open claude.ai in Chrome without trouble. Then you drop into a terminal, run claude “explain this function”, and watch the cursor blink for an uncomfortably long time before the process gives up with a connection error, a TLS handshake timeout, or a cryptic ECONNREFUSED. Restarting Clash does not help. Switching nodes does not help. Searching for the error string leads to GitHub Issues where the top comment says “check your proxy settings” without explaining what that actually means for a CLI tool.

The reason this is confusing is that the browser and the terminal live in different network contexts. A browser inherits the operating system’s proxy configuration or reads it from the environment, and most Clash GUI clients set that OS-level proxy automatically when you enable “system proxy.” A terminal process, on the other hand, only picks up a proxy if the relevant environment variables are explicitly set in its shell environment—or if you run a TUN-mode stack that intercepts traffic at the network layer, below the application entirely. If neither condition is met, claude connects directly, bypasses your Clash exit, and either fails outright or gets an unhelpful response from a geographically restricted endpoint.

This guide handles both paths: making sure the Clash rules are correct so that Anthropic’s domains land on the right policy group, and making sure the CLI process actually sees a proxy in the first place. They are independent problems, and solving only one will leave you stuck.

Why Claude Code is not the same problem as “AI sites in the browser”

Browser-based AI workflows reward you when a handful of hostnames share a coherent exit: you pin claude.ai, api.anthropic.com, and perhaps a token refresh endpoint to one policy group, and the web interface becomes reliable. The Claude Code CLI adds dimensions the browser problem does not have.

First, the CLI is a Node.js process that your shell spawns directly. It reads proxy configuration from HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables, not from the macOS or Windows system proxy store. On macOS, even if “System Preferences → Network → Proxies” is set, a terminal that was opened before Clash set those values—or a terminal that does not inherit them—will route directly. On Windows, PowerShell and WSL behave differently from each other and from the system proxy setting that controls WinInet-aware applications like Edge and Chrome.

Second, Claude Code contacts more than just the chat endpoint. Model invocations go to api.anthropic.com. Feature flags and telemetry may contact other Anthropic infrastructure. Depending on the version and configuration, there may also be traffic to CDN-adjacent hostnames for prompt caching or large-context artifact delivery. A rule that only covers the web product can miss some of these legs entirely.

Third, if you already run a policy group for AI websites following a guide like split routing for ChatGPT and other AI sites, that group may not include the specific Anthropic subdomains the CLI uses—or it may include them under a catch-all that routes through an unsuitable node. A dedicated ANTHROPIC group lets you tune exits, failover logic, and health check intervals for API traffic specifically, without disturbing your browser AI rules.

Anthropic domains worth pinning in your rules

Accurate routing starts from knowing which hostnames actually carry traffic. Anthropic’s public documentation, network setup guidance, and Claude Code’s own source point to a consistent set of domain patterns.

The primary API endpoint is api.anthropic.com. All model inference requests from Claude Code—every messages.create call—go here. This is the most critical hostname to get right: if it takes a poor node or goes DIRECT in a restricted environment, every prompt will either time out or return an error.

The web product at claude.ai is less relevant for pure CLI use, but worth including if you also use the browser interface and want a unified policy group. Related authentication and account management subdomains may include patterns like *.claude.ai.

Anthropic operates CDN infrastructure for assets and potentially for prompt caching and large context payloads. Traffic to these endpoints may appear as *.anthropic.com subdomains beyond api itself. Covering the anthropic.com suffix with a DOMAIN-SUFFIX rule is the most robust single-line approach: it catches the API host, any future subdomains Anthropic adds, and the main site in one entry.

Some Claude Code versions have shipped telemetry or feature-flag traffic to statsig.anthropic.com or similar internal analytics hosts. These do not carry user content, but routing them inconsistently can produce confusing log noise that looks like API failures. Including them in the same policy group keeps your connection log clean and your troubleshooting surface small.

If you use Claude Code with Bedrock or Vertex AI backends, the relevant API hosts shift to AWS or Google Cloud endpoints, and the analysis in this article applies to those hosts in their own right. The principles do not change; only the domain list does.

Designing the ANTHROPIC policy group

The goal is a named proxy group that acts as a single dial for all Anthropic-related traffic. Start simple: one select or url-test group called ANTHROPIC that contains your preferred exit nodes. Reference it from every Anthropic-related DOMAIN-SUFFIX rule. That separation means that when something misbehaves—a slow reply, a connection drop, a region lock that blocks the API—you switch exits inside ANTHROPIC without touching your Netflix rules, your domestic direct path, or your Cursor IDE group.

For teams or individuals who care about latency, a url-test group running periodic health checks against api.anthropic.com itself is more useful than a manually maintained select list. Set the test interval to something reasonable—two to five minutes is common—and point the url parameter at a lightweight endpoint. If health check calls count against your API quota, use an HTTPS connection check to the host rather than an authenticated endpoint.

When should you split further? Consider a second group—call it ANTHROPIC-CDN—if you observe that bulk asset or caching traffic benefits from a different congestion profile than interactive API calls. Some setups route artifact-heavy traffic through a high-bandwidth relay while keeping the chat API on a low-latency exit. The tradeoff is YAML complexity: more groups mean more things to maintain and more ways to misconfigure failover. Start with one group and split only when logs prove the workloads have meaningfully different requirements.

A minimal skeleton in mihomo YAML looks like this:

proxy-groups:
  - name: ANTHROPIC
    type: select
    proxies:
      - <your preferred exit node>
      - DIRECT

rules:
  - DOMAIN-SUFFIX,anthropic.com,ANTHROPIC
  - DOMAIN-SUFFIX,claude.ai,ANTHROPIC
  # ... other rules below

Keep these lines as high in your rules section as practical. The exact placement relative to other application-specific rules is a matter of preference; what matters is that they come before any broad GEOIP or community rule-set entries that could swallow the hostnames first.

Rule order: Anthropic lines must precede GEOIP and catch-alls

Clash and mihomo evaluate rules from top to bottom, stopping at the first match. Profiles tuned for domestic browsing performance frequently include a large GEOIP,CN,DIRECT block or a bundled rule-set that classifies a wide swath of IP ranges as onshore. Anthropic’s infrastructure sits on major cloud providers whose CDN and compute addresses span global anycast networks—addresses that aggressive domestic rule-sets sometimes classify in ways that do not match your intent.

The safest approach is to treat DOMAIN-SUFFIX,anthropic.com as an early, explicit exception. Place it before any imported rule-set block, and before the line that dispatches unknown traffic to a default international group. A comment in your config—“Claude Code API and CDN: pin above GEOIP”—takes five seconds to write and saves significant debugging time six months from now when you inherit the config from your past self.

If you already use a community RULE-SET for AI services, check whether anthropic.com is already included. If it is, verify which group that rule-set points to—it may send Anthropic traffic somewhere you did not intend. A DOMAIN-SUFFIX,anthropic.com,ANTHROPIC line placed above the rule-set reference will shadow the set’s entry cleanly, without requiring you to fork the upstream file.

For a deeper tour of how Clash evaluates its rule list, refer to Clash YAML: routing rules, proxy groups, and Fake-IP. The short version: domain rules beat IP rules beat geography rules, and explicit beats implicit. Write your Anthropic rules to exploit that hierarchy.

Getting the CLI process to use your proxy: environment variables

Correct Clash rules are necessary but not sufficient if the terminal process never reaches the proxy listener in the first place. This section is specifically for users who are not running TUN mode, or who want explicit proxy configuration for shell sessions regardless of TUN state.

Node.js—which underpins Claude Code—respects the standard lowercase and uppercase variants of the proxy environment variables. The most portable approach exports both:

export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
export NO_PROXY="localhost,127.0.0.1,::1"

Replace 7890 with the actual mixed-port number shown in your Clash GUI. The value of HTTPS_PROXY uses an http:// scheme intentionally: Node.js uses an HTTP CONNECT tunnel over that proxy connection for TLS traffic; the scheme in the variable describes the proxy protocol, not the final destination protocol.

Add these lines to your shell’s startup file—~/.zshrc, ~/.bashrc, or ~/.profile depending on your shell and login type—so new terminal windows automatically inherit them. If you want the proxy to apply only when Clash is running, wrap the exports in a function or alias that you call manually rather than unconditionally sourcing them at shell start. That way, opening a terminal when Clash is off does not result in every CLI tool hanging on connection attempts to a listener that is not there.

On Windows, the equivalent for PowerShell is:

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

Add these to your PowerShell profile ($PROFILE) if you want them persistent. For WSL2 users, the host IP is not 127.0.0.1—consult Route WSL2 Ubuntu Traffic Through Windows Clash Mixed Port for the correct address resolution approach in that environment.

One common gotcha: if you set the mixed port to only listen on 127.0.0.1, the variable value must match exactly. If Clash binds to 0.0.0.0, both 127.0.0.1 and ::1 should work. Check the “Allow LAN” and listen-address settings in your Clash configuration if the proxy refuses connections from the loopback address.

TUN mode: when you want process-transparent routing

If you prefer not to manage environment variables per shell, running Clash in TUN mode intercepts traffic at the network interface level—below any application’s proxy awareness. In this configuration, claude does not need HTTP_PROXY set because its TCP connections pass through the virtual interface and get matched against your rules the same way browser traffic does.

TUN mode simplifies the per-process configuration problem significantly: once the interface is up and your rules are correct, every application routes through Clash regardless of whether it respects proxy environment variables. The tradeoff is that TUN requires elevated privileges (service mode on Windows, net.ipv4.ip_forward on Linux), and its interaction with VPN clients, corporate split tunnels, and certain hypervisors can produce conflicts that are harder to debug than a misconfigured environment variable.

For Windows-specific TUN troubleshooting, see Fix Clash TUN on Windows: routing, firewall, and stack conflicts. The Anthropic rule configuration is identical whether you use TUN or explicit proxy variables; the difference is only in whether the CLI process needs to be told about the proxy at the shell level.

DNS and Fake-IP: keeping name resolution coherent

A routing config that works for TCP connections can still fail if DNS resolution is inconsistent. Fake-IP mode—where Clash returns synthetic IP addresses for domain lookups and resolves the real addresses internally when matching traffic—requires that the same core handling the DNS response is the one routing the connection. If your shell’s DNS resolver bypasses the Clash listener, the Fake-IP address for api.anthropic.com may be unknown to the OS routing table, and connections to that synthetic address will fail silently.

The practical guidance is to verify two things: first, that api.anthropic.com is not in your fake-ip-filter list (being excluded from Fake-IP means it resolves to a real IP, which might then miss your domain rules if you rely on Fake-IP for rule matching); second, that your nameserver-policy or upstream resolver list does not send Anthropic hostnames to a domestic DNS that returns different results than an international resolver would.

If you run clash-verge-rev or a similar GUI shell, the DNS settings dialog usually makes the Fake-IP filter visible. A quick sanity check: dig api.anthropic.com @198.18.0.2 (or whichever address your Fake-IP pool starts from) should not return a real IP—if it does, the query bypassed the Clash DNS listener entirely and Fake-IP is not in effect for that host.

Verification: logs first, curl second, node swapping last

Speed tests and browser checks do not predict whether a CLI process can maintain a stable TLS session to the Anthropic API. Use your Clash GUI’s connection log or real-time traffic panel to watch which policy group the claude process selects when you run a prompt. If you see api.anthropic.com matched by GEOIP or MATCH instead of your ANTHROPIC group, scroll your rule list upward from that position until you find which line should have matched earlier—then fix the order.

For a targeted connectivity check from the terminal itself, curl is the right tool:

# Check HTTPS reachability and TLS chain with proxy
curl -v --proxy http://127.0.0.1:7890 https://api.anthropic.com/ 2>&1 | head -40

A successful connection shows the TLS handshake completing and an HTTP response (likely a 404 or a JSON error from Anthropic, since the root path is not a real endpoint—that is expected and fine). A failure at the TLS step suggests certificate interception by a corporate proxy or firewall. A connection refused means the proxy port is not listening; check that Clash is running and that the mixed port matches the address you used.

If curl works but claude still fails, the issue is likely the missing environment variable. Confirm with:

env | grep -i proxy

If nothing appears, the exports are not in the current shell session. Source your startup file or set them inline before running the CLI. Once the variables are present and the curl test passes through the proxy, claude will follow the same path.

Quick symptom map

Placing Claude Code in a broader developer routing strategy

Claude Code is one tool in a chain that typically includes a code editor, package managers, container registries, and version control. Each of those has its own network requirements, and a well-organized Clash profile names groups for each concern rather than routing everything through one overloaded bucket.

If you run the Cursor IDE, consider a separate CURSOR group as described in Cursor IDE Stuck on Connecting? Split Routing for the Editor and Extension Marketplace. If Docker pulls are slow, Docker registry split routing covers that workload separately. For Git and npm over Windows PowerShell, Route Git and npm Through Clash Mixed Port on Windows addresses the environment variable story for those tools in detail.

The pattern in each case is the same: name the group, pin the vendor’s domain suffixes above broad geography shortcuts, verify with logs rather than guessing, and maintain a comment trail so the config is legible after the next update. Claude Code simply adds one more named lane to a profile you are probably already building out for developer tooling.

Intended use

Proxy routing tools configure transparent, intentional network paths. They do not confer permission to violate Anthropic’s terms of service, circumvent access controls that apply to your account or organization, or bypass workplace policies. The use case described here—ensuring a CLI tool can reach a vendor’s API through your own proxy infrastructure—is routine developer network configuration. Use the capability accordingly.

Closing: one named group closes the CLI gap

The mismatch between “Clash is running and the browser works” and “the terminal hangs on every claude call” has a short fix once you understand the two independent variables: the CLI process needs to see a proxy address in its environment, and the proxy rules need to send Anthropic hostnames to a dedicated exit group rather than a catch-all. Get those two things right and Claude Code becomes as reliable as any other part of your proxied developer environment.

Compared with opaque proxy tools that hide their routing decisions, Clash-family cores show you exactly which rule matched, which group handled it, and which node made the connection—exactly the kind of transparency that turns a confusing API timeout into a five-minute config fix. When you want a client that pairs a readable connection view with modern mihomo routing, the download page is the right starting point to keep your client and configuration aligned. → Download Clash for free and experience the difference.