Claude Codeの接続を安定化するClash Verge設定ガイド

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

Claude Code をインストールしてログインまで進めたのに、認証画面が開かない、確認コードを入力してもターミナルが待ち続ける、プロンプトを送信した後に ETIMEDOUT や ECONNRESET が表示される——このような症状は、モデルやアカウントの問題だけでなく、端末から見た通信経路が整理されていないことでも起こります。ブラウザはプロキシを使えているのに、ターミナルで動く Claude Code だけが接続できない場合は、まずアプリケーションごとのプロキシ継承を疑うべきです。

Claude Code は、ブラウザで開く Web サービスとは違い、Node.js ベースの CLI として動作します。初回認証ではブラウザへのリダイレクト、認証サーバーとのトークン交換、API エンドポイントへの接続が順番に発生します。ログイン後も、長めの応答をストリーミングで受け取るため、単にトップページが表示できるだけでは十分ではありません。Clash Verge で通信を捕捉し、関連ホストが同じ安定したプロキシグループへ送られているかを確認する必要があります。

本稿では、Clash Verge と Claude Code の接続設定を、サブスクリプションの追加、プロキシモード、分流ルール、ターミナルへの反映、ログ確認という順番で整理します。ホスト名や認証フローは Claude 側の更新で変わる可能性があるため、固定リストを盲目的に貼り付けるのではなく、実際に Clash Verge の接続画面へ現れた通信先を基準に調整してください。

利用上の注意：プロキシの利用可否、Claude のアカウント規約、勤務先や学校のネットワークポリシーは環境ごとに異なります。業務コードや API キーを扱う場合は、組織のセキュリティ方針とデータ取り扱い規則を先に確認してください。

事前準備：Clash Verge と購読を整える

最初に、Clash Verge が正常に起動し、Mihomo コアがエラーなく読み込まれていることを確認します。クライアントの画面はバージョンによって少し異なりますが、基本的には「Profiles」「設定」「プロキシ」に相当する項目を使います。古い設定ファイルを何度も上書きすると、廃止されたキーや古い DNS 設定が残り、Claude Code の問題に見える別の障害が発生することがあります。新しいプロファイルを作る場合は、元の YAML をバックアップしてから編集してください。

購読 URL を用意する：契約しているサービスの管理画面から HTTPS の購読 URL をコピーします。URL には認証トークンが含まれることがあるため、チャットやスクリーンショットで他人に共有しないでください。
Clash Verge に追加する：Profiles または購読管理画面を開き、購読 URL を貼り付けて取得します。取得に失敗する場合は、URL の期限、アクセス回数制限、現在の DNS、サービス側の障害を確認します。
プロファイルを有効化する：読み込んだプロファイルを選択し、構文エラーや未対応フィールドがないことを確認します。画面に赤いエラーが出る場合は、そのままプロキシをオンにせず、まずエラー行を解消します。
通信モードを選ぶ：ブラウザとターミナルだけを対象にするならシステムプロキシから始め、Claude Code がプロキシを継がない場合は TUN モードを検討します。

購読を追加した直後は、いきなり自動選択グループへ任せるより、応答が安定しているノードを一つ手動で選ぶ方が切り分けやすくなります。自動選択は普段の閲覧には便利ですが、接続中にノードが入れ替わると、Claude Code のストリーミング応答が途中で切れることがあります。まず固定ノードで認証と短いリクエストを試し、安定してから url-test などへ戻すのが安全です。

Clash Verge のモードと Claude 向け分流

Clash Verge のモードは、問題の切り分けに大きく影響します。Rule モードではルールに従って通信先ごとに DIRECT またはプロキシを選びます。Global モードではほぼすべての通信を選択中のプロキシへ送るため、ルール漏れの確認には便利ですが、国内サービスや社内システムまで迂回させる可能性があります。初回の検証では一時的に Global で動作を確認し、その後 Rule に戻して必要なルールだけを残す方法が分かりやすいでしょう。

Rule モードで Claude Code を使う場合は、Claude の Web 認証画面、API 通信、関連する静的リソースが別々のホストへ分かれている可能性を考えます。具体的なホストはリリースや地域によって変わるため、次のような広いルールを出発点にし、Clash Verge の接続ログで実ホストを確認します。

rules:
  - DOMAIN-SUFFIX,anthropic.com,CLAUDE
  - DOMAIN-SUFFIX,claude.ai,CLAUDE
  - MATCH,DIRECT

上の例で重要なのは、ルールを追加すること自体ではなく、ルールの順番です。上位に広い GEOIP、地域別ルール、別の DOMAIN-SUFFIX があると、Claude 向けの行へ到達する前に DIRECT や別グループへ振り分けられます。ルールプロバイダを使っている場合も、同じドメインが複数のリストに含まれていないか確認してください。認証と API が異なるグループへ送られると、ログインは成功しても実行時だけタイムアウトすることがあります。

確認のコツ：Claude Code の操作を再現しながら Clash Verge の接続一覧を開き、認証時とプロンプト送信時に増えたホスト名、選択されたグループ、接続状態を記録します。推測でドメインを大量追加するより、実際のログを一つずつルール化する方が保守しやすくなります。

ターミナルへプロキシを反映する

システムプロキシをオンにしても、すべての CLI が自動的にその設定を使うとは限りません。Node.js の HTTP クライアント、パッケージマネージャー、独自の TLS 実装は、OS のプロキシ設定を参照しないことがあります。その場合は、Clash Verge に表示されている混合ポートを使って、ターミナル用の環境変数を明示します。ポート番号は設定画面に表示された値を優先し、例の番号をそのまま使わないでください。

# macOS / Linux
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

# Windows PowerShell
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="http://127.0.0.1:7890"

環境変数を設定した後は、同じターミナルから Claude Code を起動します。別のターミナル、IDE 内蔵ターミナル、サービスマネージャーから起動したプロセスには設定が引き継がれない場合があります。特に VS Code や JetBrains 系 IDE から実行する場合は、IDE をいったん再起動し、内蔵ターミナルで変数が見えているかを確認してください。認証用ブラウザと CLI の経路を揃えるには、まず通常のシェルで成功させ、その後 IDE に移すのが確実です。

システムプロキシと環境変数を同時に設定する場合、異なるポートを指定しないよう注意します。HTTP ポートと SOCKS ポートを取り違えると、接続は開始しても TLS 交渉で失敗することがあります。また、プロキシ URL に余計な引用符や空白を含めないこと、会社の証明書検査環境で独自 CA が必要な場合は無理に検証を無効化しないことも重要です。

認証エラーとタイムアウトの切り分け

設定を変更したら、症状を段階ごとに再現します。ログイン画面が開かない場合はブラウザ側の通信と DNS を確認し、ブラウザは開くのにターミナルが待ち続ける場合は環境変数または TUN の不足を疑います。ログイン後の API 呼び出しだけ失敗する場合は、認証ホストと API ホストが同じグループへ送られているかを接続一覧で比較します。

認証画面が開かない：Clash Verge のシステムプロキシ状態、ブラウザの拡張機能、DNS 解決を確認します。ブラウザだけを別の VPN や企業プロキシへ接続していないかも見直します。
ブラウザは成功するが CLI が失敗する：HTTPS_PROXY と HTTP_PROXY を同じシェルへ設定し、Clash の接続一覧に Claude 関連の通信が現れるかを確認します。
送信後に長時間待つ：自動選択グループを固定ノードへ変更し、Rule モードのルール順、DNS のリーク、長時間接続を切るノード側の制限を確認します。
応答途中で切断される：ノードを変更して比較し、TUN とシステムプロキシを同時に有効にして経路が二重になっていないか確認します。長い処理では安定性を速度より優先します。

TUN モードは、プロセスが環境変数を無視する場合に有効な選択肢です。ただし、DNS やルーティングまで変わるため、最初から有効にすると原因が見えにくくなります。システムプロキシと環境変数で解決できないアプリだけを対象に TUN を使い、ローカルネットワーク、プリンター、社内ドメインを DIRECT にする除外設定を確認してください。TUN をオンにした後に全体の通信が止まった場合は、Clash Verge のログ、仮想インターフェース、管理者権限、DNS 設定を順番に戻して調べます。

なお、認証エラーが常にネットワーク由来とは限りません。アカウントの地域、利用権限、環境変数に残った古いトークン、システム時刻のずれ、Node.js や Claude Code のバージョンも確認対象です。Clash を無効にしても同じエラーが出るなら、プロキシ設定を増やす前に公式の認証状態とクライアントログを確認しましょう。逆に Clash を有効にしたときだけ成功するなら、接続グループとルールを固定し、変更前後のログを保存しておくと再発時に比較できます。

一般的な VPN アプリだけで Claude Code を動かそうとすると、ブラウザは通ってもターミナルや IDE が経路から外れたり、分流ルールを細かく確認できなかったりします。一方で、設定ファイルを手作業だけで管理する方法は、購読更新やノード切り替えのたびに負担が増え、初心者には認証失敗の原因が見えにくくなります。Clash 公式サイトなら、Clash Verge の導入から購読、Rule と TUN の使い分け、CLI の接続確認までを同じ流れで見直せるため、今回のような AI コーディング環境の調整にも取り組みやすくなります。これから Claude Code 用の通信環境を整えるなら、まずダウンロードするところから始めて、固定ノードと接続ログを使った小さな検証を進めてみてください。