Claude Codeを中国で使うなら？Clashの接続設定と分流方法

Claude Code が接続不安定になる理由

Claude Code はブラウザだけで完結するサービスではなく、ターミナルから認証、設定取得、モデル API との通信、ストリーミング応答、ローカルのツール実行を順番に行う開発者向け CLI です。そのため、中国国内のネットワークから利用を試す場合、ブラウザで Claude のページが表示できるかどうかだけでは、Claude Code の接続状態を判断できません。ブラウザは macOS や Windows のシステムプロキシを自動的に使っていても、ターミナル、Node.js、Git、SSH、コンテナはそれぞれ異なる設定を参照することがあります。

典型的な症状は、ログイン用のブラウザ画面は開くのにターミナル側で認証が完了しない、最初のプロンプトだけ送信できて次の応答で止まる、モデルの返答は始まるがストリーミング中にタイムアウトする、というものです。これらは必ずしも Claude Code 本体の故障ではありません。認証ホスト、API ホスト、設定や更新用の CDN、npm のパッケージ配布先が異なる経路へ分かれ、一部だけ直接接続になっている可能性があります。

まず確認したいのは、Clash の GUI で「システムプロキシ」を有効にしただけなのか、それとも TUN モードで端末全体の通信を捕捉しているのかという違いです。システムプロキシ方式では、アプリが HTTP_PROXY や HTTPS_PROXY を読まなければ経路に乗りません。一方、TUN はより広い通信を捕捉できますが、DNS、仮想アダプター、別 VPN、企業のセキュリティソフトとの競合が増えます。最初から複雑な構成にせず、どの層で失敗しているかを分けて調べることが重要です。

認証・API・npmを別々の通信層として見る

Claude Code の通信を分流する前に、すべてを「Claude のドメイン」として一つにまとめない方が安全です。第一の層は認証とアカウント連携です。ここではログイン画面、OAuth のリダイレクト、トークン交換、セッション確認などが発生します。ブラウザが開いても、コールバックを受け取る CLI 側や、トークンを検証する API への接続が失敗すれば、認証済みに見えたままコマンドが進まないことがあります。

第二の層は推論 API とストリーミング通信です。Claude Code の実行中は、短い HTTPS リクエストだけでなく、長時間にわたる応答ストリームが使われる場合があります。接続先のホスト名は契約形態や公式クライアントの変更により変わり得るため、古いブログに掲載されたドメイン一覧を無条件でコピーするのではなく、Clash の接続ログと公式ドキュメントを基準に確認してください。TLS エラー、EOF、504、接続リセットが出た場合は、ノードの品質だけでなく、ルールと DNS の結果も照合します。

第三の層はCLI のインストールと更新です。npm 経由で導入する構成では、パッケージ名の解決、registry のメタデータ、tarball、依存パッケージ、GitHub などの配布先が別々に登場します。Claude Code の API 自体が正常でも、npm の取得だけが失敗することがあります。逆に、インストールは成功したのにログイン後の API 通信だけが止まるなら、パッケージ配布の問題と認証・推論の問題を混同しないようにします。

分流の基本は、観測したホストを役割ごとのポリシーへまとめ、最後に広い MATCH へ落とすことです。名称は環境に合わせて変更できますが、最初から過剰なサフィックスを追加するのはおすすめしません。未知のホストまで一括してプロキシへ送ると、不要な通信や社内サービスまで経路が変わり、別の障害を作ることがあります。

Clash で作る分流ルールの考え方

Clash のルールは通常、上から順に評価され、最初に一致したルールのポリシーが選ばれます。そのため、広いルールを先頭に置くと、個別に指定したい API や認証ホストへ到達する前に別の出口が決まります。購読設定に既存のルールがある場合は、直接編集すると更新で消えることがあるため、Clash Verge、Clash Verge Rev、Mihomo などが提供するローカルオーバーライド、Merge、または Rule Providers の仕組みを優先してください。

次の断片は特定のサービスを無条件に許可する完成設定ではなく、ログを見ながら自分の環境へ置き換えるための概念例です。実際の接続先は、利用している Claude の公式案内、アカウント種別、クライアントのバージョンに合わせて確認します。存在しないホスト名を大量に登録しても、接続は改善しません。

Conceptual rule fragment — replace hosts with those observed in your logs

proxy-groups:
  - name: CLAUDE_CODE
    type: select
    proxies:
      - Preferred-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,anthropic.com,CLAUDE_CODE
  - DOMAIN-SUFFIX,registry.npmjs.org,CLAUDE_CODE
  - DOMAIN-SUFFIX,npmjs.com,CLAUDE_CODE
  - MATCH,MAIN_POLICY

DIRECT を候補に残すかどうかは、サービスの規約、ネットワークポリシー、接続結果を見て判断します。社内レジストリや許可された国内ミラーを使う場合は、公式 registry と同じグループへ機械的にまとめず、組織の DNS と認証要件に合わせます。また、DOMAIN-SUFFIX を使うとサブドメイン全体に影響するため、必要な範囲が狭いときは DOMAIN で個別に指定した方が変更の影響を抑えられます。

ターミナルで HTTPS プロキシを設定する手順

ここでは TUN を使わず、Clash の mixed-port をターミナルへ明示する方法から試します。まず Clash の Settings や General で、HTTP と SOCKS を兼ねる mixed-port の番号を確認します。代表的な番号が常に正しいとは限らないため、画面に表示された値を使ってください。次に、新しいターミナルを開き、現在のシェルだけへプロキシ環境変数を設定します。

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:7891
export NO_PROXY=localhost,127.0.0.1

実際のポートが 7890 や 7891 と異なる場合は、Clash の値へ置き換えます。HTTP プロキシのポートへ https:// を指定する、SOCKS ポートへ http:// を指定する、といったプロトコルの取り違えはよくある原因です。まずは curl や npm の設定を確認し、プロキシの有無で結果が変わるかを見ます。

env | grep -E 'HTTP_PROXY|HTTPS_PROXY|ALL_PROXY|NO_PROXY'
npm config get proxy
npm config get https-proxy

npm に古いプロキシが保存されている場合は、環境変数と競合することがあります。現在の設定を確認してから、組織で指定された値だけを残します。Claude Code を IDE の統合ターミナル、SSH セッション、Dev Container、WSL から起動する場合は、ホスト側で設定した変数が自動的に引き継がれるとは限りません。それぞれの実行環境で環境変数、DNS、Clash への到達性を確認してください。

その後、Claude Code のログイン操作、簡単な読み取り専用のプロンプト、短いコード説明の順に試します。いきなり大きなリポジトリで編集や外部ツール実行を行うのではなく、認証、単発応答、長めの応答という三段階に分けると、どこで通信が途切れるかを把握しやすくなります。接続ログでは、同じ操作で毎回同じポリシーとノードが選ばれているか、DNS エラーや TLS エラーがないかを記録します。

TUNを使うべき場面と避けるべき場面

TUN は環境変数を読まないアプリや、複数の子プロセスを起動する開発ツールをまとめて扱える点が便利です。ただし、Docker、WSL、VM、別の VPN、会社のエンドポイント保護が同時に動いていると、ルーティングや DNS が複雑になります。まずシステムプロキシと環境変数で再現性を確認し、それでも対象プロセスだけが漏れる場合に TUN を検討する順序が安全です。

ログイン後に止まるときの確認リスト

最初に、Clash のログレベルを一時的に上げ、失敗した時刻を記録します。次に同じ操作を一度だけ繰り返し、接続先のホスト、ルール名、ポリシー、ノード、エラー種別を表にします。ログにはアクセストークン、購読 URL、プロンプト本文、個人情報が含まれることがあるため、公開やサポート依頼の前に必ず伏せてください。

• 認証画面が開かない：ブラウザのシステムプロキシ、DNS、認証用ホストのルール、既定ブラウザのコールバックを確認します。
• 認証は完了するが CLI が待ち続ける：ターミナルの環境変数、子プロセスへの継承、ローカルのコールバックポートを確認します。
• 単発応答は成功するが長文で切れる：ノードの安定性、TLS、ストリーミングのタイムアウト、接続が途中で別経路へ変わっていないかを確認します。
• npm だけ失敗する：registry、npm の保存済み proxy、証明書、社内ミラー、依存パッケージの配布先を分けて調べます。
• 設定変更後に全通信が遅い：広すぎるルール、TUN と別 VPN の競合、DNS モード、MTU、ノードの混雑を元の設定と比較します。

ノードを何度も切り替えるだけでは原因が隠れることがあります。まず一つの安定した出口を選び、同じ操作を同じ時刻帯に複数回行って再現性を測ります。続いて別ノードで比較し、Clash を停止した場合、システムプロキシだけの場合、TUN を有効にした場合の三つを分けます。この差分があれば、サービス側の一時障害と自分のルールや端末設定をかなり正確に切り分けられます。

Claude Code のような CLI では、単に「Clash をオンにする」だけでは不十分で、認証、API、npm、子プロセス、DNS を同じ設計図で見る必要があります。ブラウザだけで確認する古い VPN クライアントはターミナルやコンテナへの適用範囲が分かりにくく、ルール編集の自由度が低い製品では、サービスごとの分流やログの比較にも手間がかかります。その点、Clash V.CORE は mixed-port、TUN、接続ログ、ポリシーグループを一つの運用画面で確認しやすく、Claude Code の認証と API を段階的に検証できます。自分の端末とネットワークで許可された利用範囲を確認したうえで、環境に合う Clash V.CORE をダウンロードして設定を始めてください。