Why Claude Code can fail when your browser still works

Claude Code brings Claude into the terminal, where it can inspect a project, suggest changes, and help with development tasks. But a working browser session does not prove that a command-line process can reach Anthropic reliably. The browser may use Clash Verge’s system proxy, while a terminal started from another shell, an IDE, or a background task may use a different network path. The result can be a sign-in page that never finishes, requests that hang, or a generation that stops partway through.

This guide shows how to route Claude Code through Clash Verge without assuming that one toggle affects every application. You will identify the local proxy listener, set proxy variables in the environment that launches the CLI, choose a suitable Clash routing policy, and confirm the result in both the terminal and Clash’s connection view. The same diagnostic approach is useful on macOS, Windows, and Linux, although menu names and shell commands differ.

Before changing settings, separate network errors from account errors. A connection reset, DNS failure, or repeated timeout can point to routing, name resolution, or an unreliable node. A clear authentication rejection, expired login, or account-limit message is different: changing the proxy cannot renew an account session or remove a service-side limit. Note the exact message and time of a failure so you can compare it with Clash logs rather than changing several settings at once.

Also decide which Claude Code installation you are troubleshooting. A command started in Terminal inherits that terminal’s environment. A command started from an IDE’s integrated terminal inherits the IDE’s environment, which may have been created before you changed proxy variables. A GUI launcher or background process may inherit neither. Testing in the same launch context you use every day is essential; otherwise, a successful test may only prove that a different process is configured correctly.

Prepare Clash Verge for command-line traffic

Open Clash Verge and confirm that a valid profile is loaded and selected. Select a working proxy group and check that the client’s core is running. A profile can appear in the application while no usable node is selected, and a healthy browser connection through another network path can conceal that problem. If the profile is provided by a service, keep its subscription URL private; it may contain a credential that grants access to your account.

Next, find the local HTTP or mixed port in Clash Verge’s settings. The precise port depends on your configuration, so do not copy a number from a tutorial without checking your own client. A mixed port can generally accept HTTP proxy requests and SOCKS connections; an HTTP listener is sufficient for the common HTTPS_PROXY setup below. The proxy address is usually loopback, such as 127.0.0.1, because the CLI and Clash Verge run on the same computer. Use the port displayed in your own settings.

For an initial test, select Rule mode and inspect the profile’s policy for Anthropic traffic. A rule-based profile might send relevant traffic through a proxy group while allowing ordinary local services to connect directly. Check Clash’s Connections or Logs view while Claude Code attempts a request: the observed hostname and selected policy are more useful than a list of domains copied from an old forum post. Service endpoints can change, and sign-in and inference traffic do not always follow the same path.

If the connection is clearly classified as DIRECT when you expected a proxy, inspect the active rules and the order in which they are evaluated. A broad direct rule placed before a more specific rule can capture traffic prematurely. For diagnosis only, you can briefly compare the result in Global mode. If the request succeeds there but fails in Rule mode, that is evidence to examine routing policy; it does not mean Global mode should automatically be your permanent configuration.

Do not enable several tunnelling tools at once while testing. Another VPN, system proxy manager, or TUN-based client may compete for the same traffic or overwrite settings. Close or disable overlapping tools temporarily, record the original state, and test Clash Verge by itself. This helps make the result interpretable and avoids confusing a proxy-listener problem with a conflict between network extensions.

Set proxy variables in the shell that launches Claude Code

For most terminal workflows, the direct approach is to export standard proxy environment variables before starting Claude Code. Replace the example port with the HTTP or mixed port shown in Clash Verge. The URL scheme here is http because the local listener speaks HTTP proxy protocol; HTTPS destinations can still be carried through that proxy connection.

export HTTP_PROXY="http://127.0.0.1:PORT"
export HTTPS_PROXY="http://127.0.0.1:PORT"
export ALL_PROXY="http://127.0.0.1:PORT"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
claude

On macOS or Linux, these exports apply to the current shell and to processes started from it. That makes them a useful, reversible first test: open a new terminal, set the variables, and launch Claude Code from that same window. If the test works, you can decide whether to place the exports in the appropriate shell startup file. Add them only to the file used by your shell, and remember that a startup file may be read differently for interactive, login, and non-interactive sessions.

On Windows PowerShell, set the variables in the current session before starting the CLI:

$env:HTTP_PROXY = "http://127.0.0.1:PORT"
$env:HTTPS_PROXY = "http://127.0.0.1:PORT"
$env:ALL_PROXY = "http://127.0.0.1:PORT"
$env:http_proxy = $env:HTTP_PROXY
$env:https_proxy = $env:HTTPS_PROXY
$env:all_proxy = $env:ALL_PROXY
claude

These session-level values disappear when that PowerShell window closes. If you choose to make them persistent, remember that applications already running will not necessarily see the updated environment. Restart the terminal or IDE that launches Claude Code, and verify its environment there. In an IDE, an integrated terminal may inherit variables from the IDE process rather than from a newly opened standalone shell.

Set NO_PROXY only for destinations that genuinely should bypass the local proxy, such as loopback services used by your own development environment. An overly broad bypass list can quietly send a required service DIRECT. Conversely, proxying every internal hostname can break local tools. Keep the list small, review it alongside your project’s existing environment, and avoid overwriting unrelated variables when using a shared development shell.

Some command-line clients support only particular proxy protocols or environment-variable conventions. If the variables appear to have no effect, confirm the installed Claude Code version and its current networking behavior using its documentation, then test with a simple HTTP client against the same local listener. Do not assume that adding an application-specific setting such as a custom API base URL is a generic proxy fix. Such settings can change the destination service and are unnecessary for ordinary routing through Clash Verge.

Verify the route and troubleshoot one layer at a time

Start with a basic local-listener check, then test a real CLI action. A response from the local port confirms that something is listening, but it does not prove that the selected node can reach Anthropic or that Claude Code is using that listener. Treat the checks as separate steps: local proxy availability, external connectivity, CLI environment inheritance, and successful sign-in or request completion.

curl -I --proxy "$HTTPS_PROXY" https://api.anthropic.com

This is a transport check, not a login test. A response from the remote service—even an HTTP status that indicates an unauthenticated request—can show that DNS, TLS, and the proxy path completed. A timeout or connection refusal suggests a different layer needs attention. On Windows, use a shell where the variable is defined, or specify the proxy address directly in the equivalent curl command. Avoid placing API keys, session tokens, or subscription URLs in command history or screenshots.

While running the check, open Clash Verge’s connection list and look for the corresponding outbound connection. Confirm that it uses the expected proxy group rather than DIRECT, and note whether the connection completes or repeatedly reconnects. If no matching connection appears, the CLI may not have inherited the variables, the listener address or port may be wrong, or the request may be using a different transport path. If the row appears but fails, investigate node health, DNS behavior, and profile rules before changing Claude Code credentials.

Use the symptom to choose the next test instead of changing everything together:

  • Immediate connection refusal: confirm that Clash Verge is running, the selected listener is enabled, and the port matches the current settings.
  • Long timeout with no connection entry: check shell inheritance, proxy-variable spelling, and whether the command is launched from the expected terminal or IDE.
  • Connection entry routed DIRECT: inspect the active rule set, rule order, and the actual hostname shown in the connection details.
  • Connection routed through a node but still unstable: compare another appropriate node, watch for repeated resets, and consider whether the route is saturated or unsuitable for sustained HTTPS traffic.
  • Authentication or account-limit response: resolve the sign-in, session, or account issue separately; routing changes cannot correct a rejected credential.

For long coding sessions, a node that passes a quick check may still perform poorly under sustained streaming. Compare nodes using the same request and launch context, and look for consistency rather than choosing solely by a single latency number. Latency measurements do not capture packet loss, intermittent resets, or how well a route sustains a longer response. If one node fails while another succeeds, keep the client configuration unchanged during the comparison so the result points to the route rather than to several simultaneous edits.

When you change a rule, proxy port, or environment variable, restart the process that needs to use it. Existing processes retain the environment they received at launch, and an already-open network connection may continue using its previous route. Make one change, repeat the same test, and record the outcome. This small discipline avoids a common loop in which several edits are made together and nobody can identify which one actually fixed the issue.

Frequently asked questions

Is enabling the system proxy in Clash Verge enough?

Not always. It may cover applications that follow the operating system’s proxy settings, but a command-line process can use its own networking library or inherit a different environment. Set proxy variables in the shell that launches Claude Code, then confirm the route in Clash Verge. If your version or execution environment does not honor those variables, check the current client documentation and consider whether a suitable TUN configuration is appropriate.

Which Clash Verge port should I put in HTTPS_PROXY?

Use the local HTTP or mixed port displayed in your Clash Verge settings. There is no universal port that applies to every installation. If you use a SOCKS-only listener, do not label it as an HTTP proxy; use a compatible scheme and verify that the CLI supports it. A wrong port or protocol commonly produces a local connection error before any request reaches a remote service.

Should I leave Clash Verge in Global mode?

Global mode can be a useful short diagnostic comparison when you suspect that Rule mode sends a required request DIRECT. It may also route traffic that does not need a proxy, so it is not automatically the best everyday setting. Once the comparison identifies a routing issue, inspect the actual connection details and adjust the appropriate rule or group. Follow your organization’s network and service policies.

Will a proxy fix a Claude Code login error?

It can help if the login flow fails because a required network request cannot complete, but it will not fix an expired session, invalid credentials, an account restriction, or a service-side limit. Use the exact error message to distinguish a transport failure from an authentication response. Check the relevant account or service status before repeatedly changing nodes or editing unrelated configuration.

Some general-purpose VPN clients make it easy to turn on a full-device tunnel, but offer little visibility into which command-line connection was routed or why; conversely, a shell-only proxy export is easy to forget when an IDE starts its own process. Clash Verge gives you a practical middle ground: local proxy controls, selectable routing groups, and connection evidence that can be compared with the environment Claude Code actually received. If that combination fits your workflow, start with the client download and then apply the checks above to your own profile and network.

Download Clash →