Claude Code Proxy Setup With Clash Verge for Terminal Access

Why Claude Code can fail when your browser still works

If you searched for Claude Code proxy setup, Claude Code connection timeout, or Clash Verge terminal proxy, you may already have a working Clash Verge profile and a browser that can reach the sites you need. The failure appears only after you launch Claude Code: a sign-in flow stalls, a request times out, or the terminal reports a network error before it can complete a task. That difference matters. A browser may use the operating system’s proxy setting, while a command-line process may rely on proxy environment variables—or may not use a proxy at all.

This guide gives you a repeatable way to connect Claude Code through Clash Verge on a machine you control. You will check the client’s listener, set proxy variables in the shell that launches Claude Code, verify the route in Mihomo’s connection list, and narrow down failures without changing several settings at once. Interface labels differ across Clash Verge and Clash Verge Rev releases, so use the described functions rather than expecting every menu to match word for word.

A proxy setup can help with ordinary connectivity problems, but it does not change Claude account eligibility, usage limits, payment status, or the service’s regional terms. If a response clearly identifies an authentication, billing, policy, or account-access issue, resolve that with the appropriate account or service support. Do not treat routing changes as a way to evade restrictions.

Check Clash Verge before changing your shell

First make sure the proxy client itself is in a known-good state. Open Clash Verge and confirm that Mihomo is running, the intended configuration is active, and a usable proxy node or group is selected. A profile can appear in the application while still containing unavailable nodes, expired subscription data, or rules that send the traffic you care about directly. Establish a working baseline before debugging a terminal process.

Find the local HTTP or mixed-port listener in the client’s settings or configuration. A mixed port accepts HTTP proxy requests as well as other supported proxy traffic; an HTTP listener is also suitable for the environment variables shown below. The port is configurable, so do not assume that an example such as 7897 matches your installation. Use the actual port displayed by your client. The examples assume the listener is on the same computer and therefore use 127.0.0.1.

Next, open the client’s Connections or equivalent live-traffic view. Keep it visible while making a test request later. If the connection list is empty during a Claude Code attempt, the process may not be using the listener, it may be failing before it makes a network request, or the relevant traffic may be outside the view you are checking. If entries appear, inspect their destination, rule, and selected proxy. A connection marked DIRECT is useful evidence when you expected it to use a proxy; it is not, by itself, proof that the application is malfunctioning.

System proxy and TUN are separate ways of capturing traffic. Turning on the system proxy typically changes settings used by applications that honor the operating system’s proxy configuration; it does not guarantee that every terminal tool will follow those settings. TUN can capture a broader range of traffic, but it introduces another layer to diagnose, including routing, DNS, and permissions. For the first test, use explicit shell variables and a known local HTTP or mixed port. Add TUN only if you have a specific reason and understand how it changes traffic capture.

Set proxy variables in the terminal that launches Claude Code

Many command-line tools read environment variables rather than the desktop proxy setting. Set both uppercase and lowercase forms to improve compatibility with programs and libraries that recognize different conventions. Use the URL scheme that describes the local listener: an HTTP proxy commonly uses an http:// URL even when it forwards HTTPS destinations through the HTTP CONNECT method. Do not change it to https:// unless the local listener itself is configured for TLS.

For macOS or Linux, open the terminal you normally use, substitute your actual listener port, and export the variables in that same shell:

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"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"

Then launch Claude Code from that terminal so the new process inherits the variables. If you use a different port, replace 7897 in every assignment. Setting variables in one terminal does not automatically update an already-running terminal, an editor launched earlier, a background service, or a separate shell window. If you start Claude Code from an integrated terminal inside an editor, configure or restart the editor as needed, then check the variables in that integrated terminal too.

On Windows, the exact command depends on the shell. In PowerShell, set process-scoped values for the current session:

$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"
$env:http_proxy = $env:HTTP_PROXY
$env:https_proxy = $env:HTTPS_PROXY
$env:all_proxy = $env:ALL_PROXY

In Command Prompt, use set for the current window rather than assuming a setting made in another shell will carry over. If you choose to create persistent user-level environment variables through Windows settings or a profile script, be deliberate: they can affect unrelated tools, and already-open applications usually need to be restarted before they inherit updated values.

Check what the current process can see before starting Claude Code. On macOS or Linux, run env | grep -i proxy; in PowerShell, run Get-ChildItem Env:*proxy*. Confirm that the values point to the local address and the port shown in Clash Verge. Avoid posting the full environment output publicly: it may include unrelated secrets or internal service details. If your organization requires a particular proxy or sets its own environment variables, follow that policy rather than overwriting it blindly.

Use NO_PROXY only for hosts that should bypass the proxy, such as services intentionally restricted to your own machine or local network. A broad value can quietly route a destination directly and make the setup appear inconsistent. For example, a short local-only list may be appropriate in some environments:

export NO_PROXY="localhost,127.0.0.1"
export no_proxy="$NO_PROXY"

Do not add a vendor hostname to NO_PROXY as a generic troubleshooting trick. If you are unsure whether an inherited value is affecting the request, inspect it and temporarily test with a narrowly scoped, reversible change in the current shell.

Verify the request path with observable evidence

Use a layered check instead of repeatedly restarting Claude Code and guessing. First confirm that the local listener responds. A simple HTTP client request can tell you whether a process can reach the configured proxy endpoint, but a generic test URL does not prove that Claude Code uses the same code path or that every required service hostname is routed correctly. It is a first check, not a complete diagnosis.

curl -I --proxy http://127.0.0.1:7897 https://example.com

Replace the port with the one shown in Clash Verge. If the command reports that it cannot connect to the proxy, check the listener address, port, core status, and any local firewall rule before investigating Claude Code. If it connects but the destination request fails, look at the client’s live connection record and test whether the selected node can reach that destination. A successful generic request demonstrates basic proxy connectivity only; it does not validate account access or all of Claude Code’s network dependencies.

Now launch Claude Code from the shell where you set the variables and reproduce one small operation. At the same time, watch the Clash Verge connection list. Look for destinations associated with the request and note whether the rule selected a proxy group, a direct route, or a different policy. Hostnames and supporting services can change over time, and a sign-in flow may contact different destinations from a later model request. Use the live records from your own session as the source of evidence rather than relying on a copied list of supposedly permanent endpoints.

If you need to test a particular hostname, use a command-line request that explicitly names the proxy and the destination, where appropriate. Avoid putting API keys, session tokens, or authorization headers in shell history, screenshots, shared logs, or public issue reports. A basic connectivity check can show whether a TLS connection is possible, but it cannot certify that Claude Code is authenticated correctly or that an account is allowed to use a particular feature.

Compare three observations: whether the shell has the expected proxy variables, whether the local client records the process’s traffic, and whether the client’s policy sends the relevant connection through the expected route. These observations narrow the problem more reliably than the tray icon alone. For example, correct variables with no matching connection suggest a process-level or application-level issue; visible connections marked DIRECT suggest a policy or rule issue; a proxied connection that repeatedly resets suggests a node, network, or TLS-path issue.

As a temporary diagnostic—not a permanent recommendation—you can compare rule-based routing with Global mode if your organization’s rules and local requirements permit it. If the same request works only in Global mode, examine rule order, matching behavior, and the chosen policy group. Return to the intended mode after the comparison. Global routing may send unrelated destinations through the proxy, consume more traffic, or conflict with local network requirements, so it should not replace a correctly scoped rule set.

Troubleshoot timeouts, login problems, and unexpected routes

Start by classifying the symptom. A timeout or connection reset is different from an explicit authentication error, and neither is the same as a request rejected because of an account limit. Record the approximate time, the command or action that failed, the shell in use, and any relevant Mihomo connection entry. Keep tokens and private profile URLs out of that record. A short, sanitized timeline makes it easier to see whether a change actually improved the route.

• No connection appears in Clash Verge: confirm that you launched Claude Code from the shell where the variables are set, check the variable values there, and verify that no wrapper, editor, task runner, or service is starting a separate process with a different environment.
• Connections appear as DIRECT: inspect the active profile, rule order, mode, and matched policy. Test with a controlled comparison and then correct the narrowest relevant rule rather than changing unrelated routing.
• The proxy refuses a local connection: recheck the listener port and whether the core is running. A port copied from another device or profile may not match the current client.
• The request connects but stalls or resets: compare another available node, check whether the issue is limited to long-lived requests, and review the client’s logs for repeated failures. A quick page load does not establish that a node is stable for every interactive session.
• Login fails while ordinary browsing works: determine whether the login-related request reaches the proxy and whether the service returns a network error or an account/authentication message. Browser success does not prove that a terminal process has the same proxy settings or credentials.
• Only one shell or editor fails: check its startup files, environment inheritance, and launch method. Do not assume that a variable exported in PowerShell, a Unix shell, and an editor’s integrated terminal is shared across all three.

When the error looks like TLS or certificate validation, do not disable certificate checks as a shortcut. First determine whether the failure occurs only through a particular network, node, or inspection layer. If your workplace uses approved TLS inspection, follow its documented trust-store setup; otherwise, do not install unfamiliar root certificates simply because a forum post recommends it. The correct fix depends on who manages the network and what certificate chain the application is expected to trust.

Change one thing at a time and repeat the same small test. If you change the listener port, shell variables, profile rules, node, and TUN mode in one pass, you lose the ability to identify what mattered. After a successful test, restart the normal terminal or editor in the way you actually use it and confirm the behavior again. Then document the working port, shell configuration, and relevant rule so that an application update or profile refresh does not turn the fix into guesswork.

Keep the setup maintainable across sessions

For daily use, decide whether you want a temporary per-session setup or a persistent shell configuration. Per-session exports are easy to audit and limit their effect to the process tree you launch from that terminal. A profile file or persistent operating-system setting is more convenient, but it can affect other command-line programs and may become stale if you change Clash Verge’s listening port. Whichever approach you choose, keep the configured port in one place where you can update it and avoid duplicating conflicting assignments across multiple startup files.

On macOS and Linux, shell startup behavior depends on whether the shell is interactive, a login shell, or launched by an application. Put persistent settings in the appropriate file for the shell you actually use, then open a fresh session and verify the values. On Windows, remember that PowerShell, Command Prompt, and an editor’s integrated terminal have distinct startup and inheritance behavior. A setting that works in one does not prove that another process received it.

Keep Clash Verge’s configuration and shell settings aligned. If you change from an HTTP listener to a different port, update the relevant environment variables and restart the affected process. After a profile update, confirm that the intended proxy group still exists and that the applicable rules still select it. Keep a known-good node available for comparison, but do not assume a node’s performance will remain constant under different network conditions or over time.

Finally, separate the layers when reporting a problem: the application error, the shell and proxy variables, the local listener status, and the Mihomo route decision. Share only sanitized details. A helpful report might say that Claude Code was launched from a fresh PowerShell session, the local listener accepted a test request, and a related connection was classified as DIRECT; it should not include subscription links, credentials, or personal account data.

Some one-click VPN clients make it easy to toggle a tunnel but provide little visibility into which terminal process used it or why a request took a particular route. Conversely, a manually maintained proxy command can be transparent but cumbersome when ports, rules, and nodes change. Clash Verge offers a practical middle ground for this workflow: a local listener for command-line tools, rule-based routing, and live connection evidence that helps distinguish an environment problem from a policy or node problem. If that combination fits your setup, you can compare the available clients and choose one for your platform.

Download Clash →