Claude CodeをClash Vergeで使う前に知っておきたいこと

Claude Code は、ターミナルから自然言語で指示を出し、リポジトリの読み取り、コードの作成・修正、テスト実行、ファイル整理などを支援する開発者向けAIツールです。ブラウザで質問するだけのサービスとは異なり、ローカルのシェル、Git、Node.jsやPythonなどの開発環境と連携しながら動作するため、通信経路の安定性がそのまま作業効率に影響します。

特に、ターミナルから認証を行う場面では、ログインページを開くためのHTTPS接続、APIへリクエストを送る接続、ストリーミング形式で応答を受け取る長時間接続が順番に発生します。ブラウザは問題なく使えるのに、claude コマンドだけがタイムアウトする場合は、Claude Codeそのものではなく、シェルがClash Vergeを経由していない、プロファイルのルールが適用されていない、または出口ノードが長い接続に向いていない可能性があります。

Clash Verge は、購読プロファイルの読み込み、ポリシーグループの選択、接続ログの確認、システムプロキシやTUNモードの切り替えをGUIから操作できるクライアントです。環境によって搭載コアや設定項目の名称は異なりますが、基本的な考え方は Mihomo 系クライアントに共通しています。本稿では、特定のプロバイダーや非公式な接続先を推奨するのではなく、正規に利用できるプロファイルを持っている前提で、Claude Codeの通信を安定させるための確認順序を整理します。

最初は最小構成で確認複雑なルールや複数のVPN、ターミナル固有の環境変数を同時に変更せず、Clash Vergeのプロファイル、選択中のノード、シェルのプロキシ設定を一つずつ確認してください。原因の層が混ざると、設定を直してもどこが効いたのか分からなくなります。

ステップ1：Clash Vergeのプロファイルとポリシーを準備する

まずClash Vergeを起動し、普段使っているプロファイルが正常に読み込まれているか確認します。購読URLの更新に成功していても、実際にアクティブになっているプロファイルが別のファイルであることがあります。プロファイル一覧で対象を選択し、設定画面に表示されるプロキシグループ、ルール、DNSの内容が期待したものと一致するかを見てください。

次に、Claude Code用の通信を受けるポリシーグループを決めます。最初の検証では、複数ノードを自動で切り替える url-test より、利用者が明示的に選ぶ select グループの方が原因を追跡しやすくなります。Claude Codeは短いリクエストだけでなく、生成結果を段階的に受信するストリーミング接続を使うため、レイテンシーが少し低いだけのノードより、接続が長時間維持されるノードを優先する方が安定する場合があります。

グループ名はプロファイルごとに異なりますが、画面上で「Proxy」「海外」「AI」「自動」などの候補を確認できます。まず一つのノードを選択し、簡単なHTTPSサイトとClaude Codeの実行を同じ状態で試します。ノードを頻繁に変えながらテストすると、認証情報の有効期限やサーバー側の一時的な変動まで原因に見えてしまうため、比較時は一つのノードを数回連続して使うことが重要です。

確認項目	見る場所	判断の目安
プロファイル	Profiles / プロファイル一覧	更新済みで、実際に選択されている
ポリシーグループ	Proxies / プロキシ	Claude Codeの通信を受けるグループが決まっている
接続ログ	Connections / Logs	認証やAPI通信が意図した経路へ入っている
コア状態	Settings / Core	プロファイルの構文エラーがない

設定ファイルを編集できる場合でも、最初から広い DOMAIN-SUFFIX を大量に追加するのは避けます。サービス側のホスト名は変更されることがあり、推測で作ったルールが別の通信まで巻き込むためです。まずは接続ログに表示される実際のホスト名と、命中したルールを記録し、その後に必要な範囲だけを調整します。

ステップ2：ターミナルとClash Vergeの経路を一致させる

Clash Vergeでシステムプロキシを有効にしても、すべてのターミナル通信が自動的に同じ経路を通るとは限りません。GUIアプリはOSのプロキシ設定を利用していても、CLIツールやシェルスクリプトは環境変数を参照するだけの場合があります。Claude Codeを起動するシェルがどの設定を引き継いでいるかを、別の層として確認してください。

HTTPプロキシ方式を使う場合は、Clash Vergeの画面に表示される混合ポートまたはHTTPポートを確認し、シェル側の変数をそのポートへ合わせます。たとえばローカルポートが 7890 である環境では、次のような設定を一時的に試せます。ポート番号は必ず自分のClash Vergeに表示された値へ置き換えてください。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890

確認後、env | grep -i proxy で値を表示し、不要な古いプロキシが残っていないか確認します。会社のVPN、開発用コンテナ、WSL、SSH経由のシェルでは、ホストOSの 127.0.0.1 が別の環境を指すことがあります。WindowsのWSLやDockerコンテナから接続する場合、ホスト側のClash Vergeポートへ到達できるネットワークアドレスが異なるため、ホストのルーティングやファイアウォールも確認が必要です。

一方、TUNモードを利用すると、アプリがプロキシ環境変数を理解していなくても、OSの仮想ネットワークインターフェースを通じて通信を捕捉できます。CLIツールとの相性を改善しやすい反面、DNS処理、管理者権限、他のVPNとの競合、ローカル開発サーバーへのアクセスに影響することがあります。最初からTUNを常時有効にするのではなく、システムプロキシ方式で経路を確認し、それで拾えない通信だけをTUNで検証する順番が安全です。

TUNと環境変数を重ねすぎない全通信をTUNへ流しながら、シェルにも別のHTTPプロキシを設定すると、二重プロキシやループが起きることがあります。Claude Codeの動作確認では、まず一方の方式だけを有効にし、接続ログに同じリクエストが重複して現れていないか確認してください。

ステップ3：認証・API・長接続を意識してルールを調整する

Claude Codeの接続トラブルは、すべてを一つの「AI向け」グループへ入れれば解決するとは限りません。認証画面、APIリクエスト、ストリーミング応答、アップデート確認などは、要求の長さと失敗時の見え方が異なります。認証だけ成功してAPIが失敗する場合は、ログイン経路と推論経路が別ホストである可能性を考えます。

ルールは上から順番に評価されるため、特定のホストへ向けた狭いルールを広いルールより上に置きます。実際のホスト名はサービスの更新や地域によって変わるため、下記は構造を示す例として扱い、実環境のログで置き換えてください。

rules:
  - DOMAIN,api.example-claude.invalid,CLAUDE-CODE
  - DOMAIN-SUFFIX,example-claude.invalid,CLAUDE-CODE
  - DOMAIN-SUFFIX,github.com,DIRECT
  - MATCH,PROXY

存在しないドメインをそのまま設定へ追加するのではなく、接続ログに出た実際のServer Nameを使うことが大切です。ログには宛先、使用されたポリシー、接続状態が表示されるため、Claude Codeを実行した直後に新しい接続だけを確認します。DIRECT に入っている通信が失敗しているのか、プロキシグループへ入った後に切断されているのかで、次に見るべき場所が変わります。

ストリーミング応答が途中で止まる場合は、ノードの自動切り替えだけでなく、アイドルタイムアウトや接続数制限も疑います。短時間の速度測定が良好でも、長いコード生成や大きなリポジトリの解析では別の性質が現れます。安定性を比べるときは、同じプロジェクト、同じ指示、同じノードを使い、認証成功率、応答開始までの時間、途中切断の有無、再試行回数を記録すると判断しやすくなります。

認証に失敗する：シェルの経路、ブラウザ連携、時刻、環境変数を確認する。
API到達時にタイムアウトする：命中ルール、選択ノード、DNS解決結果を確認する。
生成途中で止まる：ノードの切り替え、長接続、アイドルタイムアウトを確認する。
毎回別の症状が出る：複数VPN、TUN、HTTP_PROXY、シェルの起動設定を一度整理する。

接続エラーが出たときの切り分け手順

まずClaude Codeを何度も再実行する前に、Clash Vergeのログを開いた状態で一回だけ再現します。ログに新しい接続が出なければ、ターミナルの通信がClash Vergeへ届いていません。接続が出ているのに timeout になるなら、命中ルールとノードを調べます。HTTPステータスが表示される場合は、ネットワーク到達性ではなく認証、権限、レート制限、アカウント状態の問題である可能性があります。

DNSエラーでは、ホスト名を解決できているか、DNSモードが現在のネットワークと相性を持つかを確認します。TLSエラーでは、端末の日時、証明書検証、企業ネットワークの検査プロキシを確認します。ECONNRESET や接続リセットが出る場合は、ノード側の切断、上流の制限、長接続を扱う中間機器の挙動が候補になります。エラー文字列だけで「Claude側の障害」と断定せず、同じ時刻のClashログと照合してください。

設定を変更した後は、古いシェルの環境変数や常駐プロセスが残っていないかにも注意します。ターミナルを再起動し、必要ならClash Vergeのプロファイルを再読み込みします。TUNを停止してシステムプロキシだけで試す、逆に環境変数を解除してTUNだけで試すというように、検証条件を一つずつ変えると、複合的な設定ミスを分離できます。

また、APIキーや認証トークンをログ、シェル履歴、設定ファイル、スクリーンショットへ貼り付けないでください。接続診断ではホスト名、ルール名、エラー種別、発生時刻だけを共有し、秘密情報は必ず伏せます。不要になった環境変数はシェルの設定ファイルから削除し、共有端末では認証状態も確認しておくと安全です。

まとめ：Claude Codeの用途に合わせてClash Vergeを選ぶ

Clash for Windowsや単純なシステムプロキシ設定は、ブラウザ閲覧だけなら分かりやすい一方、CLI、WSL、コンテナ、長時間ストリームが混在する開発環境では、どのプロセスがどの経路を使っているかを追いにくいことがあります。ノードを自動選択するだけの構成も、短い通信の速度比較には便利ですが、Claude Codeのように認証と長い生成接続を連続して扱う用途では、途中切り替えやタイムアウトの原因を見えにくくする場合があります。

その点、Clash Verge はプロファイル、ポリシーグループ、接続ログ、システムプロキシ、TUNモードを一つの画面で確認しやすく、初心者でも「ターミナルがClashを通っているか」「どのルールに命中したか」「どのノードで切断されたか」を段階的に調べられます。複雑な設定を最初から作り込むのではなく、明示的なノード選択、必要最小限のルール、ログによる実測という順番で進めれば、Claude Codeの接続安定化と日常の開発通信を両立しやすくなります。

まずは自分のプロファイルを読み込み、システムプロキシまたは環境変数のどちらか一方でClaude Codeを実行し、接続ログを確認してください。その結果をもとにTUNや個別ルールを追加すれば、原因不明の再試行を減らしながら、自分の開発環境に合った構成へ近づけます。

→ 無料でClashをダウンロードして、対応クライアントと最新の導入情報を確認し、Claude Codeを安定して使えるプロキシ環境を整えましょう。