First, identify where the connection fails
Claude Code runs in a terminal, so a working browser connection does not prove that the CLI can reach its services. A browser may use the operating system’s system proxy, while a terminal process may use different settings—or no proxy at all. The useful first question is not “Which node has the lowest delay?” but “Does Claude Code’s request reach the Clash core, and what happens next?”
A typical request follows this path: Claude Code reads its proxy environment variables, connects to a local Clash HTTP-compatible proxy port, and the core applies the active mode and rules. The core then connects directly or through a selected outbound proxy. A failure can therefore occur before the core sees a request, while matching a rule, during the outbound connection, or after the remote service receives it.
- The browser and Claude Code both fail: Check general connectivity, the active profile, the selected proxy group, and whether the chosen node can make outbound connections.
- The browser works but Claude Code fails: Check the terminal’s proxy environment and the local port first. Do not assume that the system proxy setting is inherited by command-line programs.
- Clash shows no matching connection: Claude Code may not be using the local proxy, may not have made a request yet, or may be blocked before reaching the listener. Confirm the environment variables and port.
- Clash shows a request that fails: Inspect the matched rule, final outbound, and connection error. This points to routing, DNS, or the remote path rather than a missing terminal proxy setting.
- Sign-in works but a request fails, or the reverse: Authentication and API requests can use different hostnames and occur at different times. Inspect each request rather than treating the CLI as one permanent connection.
Before changing settings, note the operating system, shell, Clash client and core versions, active profile, and the exact error text. Also record whether the failure occurs at startup, during sign-in, or while sending a prompt. These details help separate a proxy problem from an account, service, or regional-availability issue.
Configure an HTTP-compatible proxy for the terminal
Claude Code can use proxy environment variables such as HTTPS_PROXY and HTTP_PROXY. In Clash, use a local HTTP or mixed port shown in the client’s settings. A mixed port accepts both HTTP proxy requests and SOCKS connections, but for these environment variables use an HTTP proxy URL, commonly http://127.0.0.1:7890. The address and port here are examples; use the actual listener configured on your computer.
The http:// prefix describes the connection from the terminal to the local HTTP proxy. It does not mean that the destination must use unencrypted HTTP. For an HTTPS destination, the client typically asks the proxy to establish a CONNECT tunnel, then performs TLS with the destination through that tunnel.
macOS and Linux shells
In the same terminal session where you run Claude Code, set the variables and start the CLI:
export HTTP_PROXY="http://127.0.0.1:7890"
export HTTPS_PROXY="http://127.0.0.1:7890"
claude
These commands affect the current shell and processes launched from it. To make them available in future sessions, add the exports to the startup file for the shell you actually use, such as ~/.zshrc for zsh or ~/.bashrc for bash, then open a new terminal or reload that file. Avoid placing proxy credentials in a shared shell profile, command history, or a file readable by other users.
Windows PowerShell
Set the variables in the PowerShell window from which you launch Claude Code:
$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"
claude
PowerShell environment variables are inherited by child processes. If you set them in one window, an already-running terminal or editor will not automatically receive the changes; launch a new process from the configured shell. For a persistent Windows setting, use the Windows environment-variable controls or your shell’s profile, and reopen the terminal afterward. Keep the port consistent with the Clash listener.
To remove temporary values from the current PowerShell session, run Remove-Item Env:HTTP_PROXY and Remove-Item Env:HTTPS_PROXY. In a POSIX shell, use unset HTTP_PROXY HTTPS_PROXY. This is useful when comparing a direct connection with a proxied one, but only test direct access where it is permitted and available.
| Setting | Purpose | Check |
|---|---|---|
HTTP_PROXY | Provides a proxy for HTTP requests made by programs that honor the variable | Value uses the local HTTP-compatible port and correct scheme |
HTTPS_PROXY | Provides a proxy for HTTPS requests made by programs that honor the variable | Set it in the same shell that launches Claude Code |
NO_PROXY | Lists destinations that should bypass the proxy | Remove unintended broad entries while troubleshooting |
| Clash system proxy | Sets system-level proxy details for applications that read them | Does not prove that the terminal process uses the setting |
NO_PROXY can be helpful for local services, but an overly broad value may cause a service request to bypass Clash. If you did not intentionally configure it, inspect whether it is present before adding or changing entries. Do not set a custom API base URL merely to make a connection test pass; use only endpoints provided by an authorized organization or service configuration.
Verify the local listener and the Clash route
Before retrying Claude Code repeatedly, test the local proxy port directly from the same machine. With curl, an HTTPS request can be sent through the local HTTP proxy:
curl -v --proxy http://127.0.0.1:7890 https://api.anthropic.com/
Replace the example port with the one shown in Clash. The command is a connectivity check, not an authentication test. An HTTP response such as an authorization error, not-found response, or method error can still indicate that the request reached an HTTPS service. A connection-refused message usually points to a wrong address or port, a stopped listener, or a local security control. A timeout after connecting may point further along the route.
Next, open Clash’s Connections page and make a fresh request. Look for the destination hostname, matched rule, policy or proxy group, and final outbound. The exact labels depend on the client, but the important distinction is whether the request is absent, matched to an unexpected policy, or captured and then fails while dialing. Check Logs at the same time for profile parsing errors, DNS failures, TLS errors, and outbound timeouts.
- Confirm the profile is active. Open Profiles and check that the intended configuration is selected, not merely imported. Confirm that the expected proxy groups and nodes appear.
- Confirm a usable outbound is selected. In Proxies or Proxy Groups, inspect the group used by the matching rule and select a currently available member. A latency result is not a guarantee that every destination or protocol will work.
- Check the rule result. In rule mode, a request may match
DIRECT,REJECT, or a different proxy group than expected. Follow the displayed rule and policy rather than switching to global mode as a permanent workaround. - Check the local port. Verify that the configured HTTP or mixed listener is enabled and that no other process is using the address. A port number in an example or an old profile may not match the current client setting.
Claude Code and related sign-in flows may contact more than one service hostname, and the required set can change. A rule that handles one visible API hostname does not prove that every authentication or supporting request follows the same route. Use the current service documentation for any managed network allowlist, and validate the destinations actually shown in Connections. Avoid copying an old, supposedly complete hostname list into a ruleset without checking it.
Troubleshoot DNS, TLS, and common errors
DNS behavior depends on the Clash profile, core settings, proxy protocol, and whether the destination is resolved locally or remotely. If the log reports a name-resolution error, check the DNS configuration and the resolver path used by the active profile. Compare a failing hostname with another known reachable destination, but do not infer that all Claude Code traffic shares one DNS lookup or one connection.
If Connections shows the request but the outbound times out, check whether the selected node is available and whether the network permits the transport it uses. If the connection reaches the remote side but the CLI reports an HTTP status or authentication error, the proxy path may be functioning; check account state, credentials, service status, and the precise response instead of changing DNS at random.
TLS errors need particular care. Check the computer’s date and time, the local certificate store, and whether an organization’s network is intercepting TLS. If an authorized corporate proxy requires a private certificate authority, follow the organization’s instructions for trusting that certificate. Do not disable certificate verification or use insecure TLS settings as a workaround: that weakens protection and can expose credentials or prompts.
A 407 Proxy Authentication Required response usually means the proxy expects authentication that the request did not provide. A local Clash listener is often configured without authentication, but not every deployment is. A refusal before any connection appears in Clash suggests a local port or process issue. A request visible in Clash with a connection timeout suggests that the traffic entered the core and the failure is later in the route.
For a controlled comparison, make one change at a time: verify the local proxy with curl, confirm the rule and outbound, then retry the CLI. Do not simultaneously change the profile, DNS mode, proxy group, environment variables, and TUN settings. Changing many variables at once makes a successful or failed result difficult to interpret.
Keep regional availability and service terms in mind
Network reachability is not the same as eligibility to use a service. Claude availability, account requirements, and access conditions can vary by region and may change over time. A successful connection through Clash does not establish that the service is available to an account or location, nor does it override the service’s terms, applicable law, or an organization’s access policies.
Use Claude Code only where the service is available to you and in accordance with the current terms. If a request is denied because of account, region, or policy restrictions, do not treat proxy routing as authorization to bypass them. For employer-managed devices or networks, ask the administrator which endpoints and proxy configuration are approved. For a service-side outage or account error, check the provider’s current status and account guidance rather than repeatedly rotating nodes.
A reliable setup is one that is understandable and reproducible: the terminal uses the intended local proxy, Clash captures the request, the rule selects the expected outbound, and DNS and TLS checks pass without weakening security. Keep a note of the working shell variables and local port, remove temporary settings when no longer needed, and re-check them after changing terminals, profiles, or network environments.