Claude Code×Clash Verge接続設定ガイド

Claude CodeをClash Vergeで使う前に確認したいこと

Claude Code は、ターミナルからリポジトリを読み込み、ファイル編集、コマンド実行、テスト、差分確認までを対話的に進める開発者向けツールです。ブラウザでClaudeを開ける環境でも、Claude Codeの認証や推論リクエストが同じように成功するとは限りません。ブラウザはOSのシステムプロキシを利用していても、ターミナルのCLIは環境変数やシェルの設定を別に参照するためです。

よくある症状は、ログイン用URLを開いた後に認証が戻ってこない、初回のモデル一覧取得だけが長時間止まる、入力は送れるのに返答の途中でタイムアウトする、または command not found と通信エラーが同時に表示される、といったものです。これらをすべて「ノードが遅い」と考えて設定を増やすと、原因が隠れてしまいます。まずClaude Code本体、認証、API通信、ターミナルのプロキシ継承を別々の層として確認することが重要です。

Clash Verge は、プロファイルの切り替え、接続ログの確認、システムプロキシやTUNの有効化を一つの画面で行いやすいクライアントです。背後のMihomo系コアでルールを適用するため、Claude Codeの通信だけを専用グループへ送る設計もできます。ただし、使用しているClash Vergeのバージョンやコアによって項目名が異なる場合があります。画面の表示が異なるときは、名称ではなく「システムプロキシ」「TUN」「接続ログ」「ルール」の役割を対応させてください。

最初は最小構成で試す複雑なルールセットをいきなり追加せず、安定したプロキシグループを一つ選び、ターミナルからのHTTPS通信が成功することを確認してからClaude Code専用の分流を作ると、原因を追いやすくなります。

認証停止・遅延・タイムアウトを層ごとに切り分ける

認証画面が開くかどうかは、Claude Codeの通信全体が正常であることを意味しません。ログインURLをブラウザで開く部分はブラウザのプロキシ設定に左右されますが、認証後にCLIへ戻る処理、トークンの交換、モデルAPIへの接続は別のリクエストとして発生します。ブラウザだけで確認を終えず、Clash Vergeの接続ログを開いた状態でClaude Codeを起動し、どのホストへの接続が発生したかを見てください。

エラーの読み方は、次のように分けると整理しやすくなります。名前解決に失敗する場合はDNS層、証明書やTLSハンドシェイクで止まる場合はTLS層、401や403が返る場合は認証・権限層です。ETIMEDOUT、ECONNRESET、socket hang up、接続待ちのまま進まない症状は、ノードの到達性、ルールの誤判定、長時間接続の切断などを疑います。CLI自体が起動しない場合は、ネットワークより先にNode.jsやインストール済みコマンドのパスを確認します。

通信が遅いという体感にも複数の原因があります。最初のDNS応答だけが遅いのか、TLS確立までが遅いのか、モデルの最初のトークンが返るまでが長いのか、ストリーミング中に一定時間ごとに止まるのかで、対処は変わります。Clash Vergeのログで接続開始から切断までを観察し、ターミナル側の表示と時刻を照合してください。自動選択グループが短いヘルスチェックだけでノードを切り替えている場合、通常のWeb閲覧では問題がなくても、Claude Codeの長いセッションでは不安定になることがあります。

ホスト名を推測して固定しないClaude Codeの認証・API・更新関連の接続先は、バージョンや提供形態、地域、ログイン方式によって変わる可能性があります。広いサフィックスを思い込みで追加するより、再現時のClash Vergeログに表示されたホスト名と命中ルールを一次情報として扱ってください。

Clash Vergeの基本設定：プロファイル・システムプロキシ・TUN

最初に、Clash Vergeへ有効なプロファイルを読み込みます。購読URLを登録する場合は、利用権限のあるサービスから取得したURLだけを使い、更新後にプロキシグループが表示されることを確認してください。プロファイルの読み込みが成功しても、現在選択されているグループに利用可能なノードがないことがあります。グループ画面で一つのノードを手動選択し、ブラウザとターミナルの両方で同じ出口を使う状態から始めると、比較が簡単です。

GUIアプリやブラウザを対象にするだけなら、まずシステムプロキシを有効にします。これにより、OSのプロキシ設定を参照するアプリはClash VergeのHTTPまたはSOCKSポートへ接続できます。しかし、ターミナルのコマンドやNode.jsプロセスがOS設定を自動的に読むとは限りません。Claude Codeがシェルから起動される場合は、シェルにプロキシ環境変数を渡す必要があることがあります。

一方、アプリごとの設定差を減らしたい場合はTUNモードが候補になります。TUNは仮想ネットワークインターフェースを通して、対応範囲の広い通信をClashへ渡します。ただし、権限の要求、他のVPNとの競合、DNSモード、会社のセキュリティソフトとの相性が関係します。TUNを有効にしただけで必ずCLIが同じ経路になるとは限らないため、接続ログで実際の通信を確認してください。

確認項目	向いている場面	注意点
システムプロキシ	ブラウザやGUIアプリを簡単に通したい	CLIがOS設定を継承するとは限らない
TUNモード	アプリごとのプロキシ設定を減らしたい	権限、DNS、他VPNとの競合を確認する
環境変数	ターミナルやスクリプト単位で経路を明示したい	シェル、IDE、子プロセスごとに継承を確認する

ターミナルから明示的にプロキシを指定する場合は、Clash Vergeの設定画面に表示されたHTTPプロキシポートを使います。ポート番号を固定値として覚えず、現在の設定を確認してください。例として、環境変数を一時的に設定してから疎通を試す形は次のようになります。

export HTTP_PROXY=http://127.0.0.1:PORT
export HTTPS_PROXY=http://127.0.0.1:PORT
export NO_PROXY=localhost,127.0.0.1
claude

WindowsのPowerShell、macOSやLinuxのシェルでは環境変数の書き方が異なります。また、プロキシを受け付けるポートがHTTPではなくSOCKSの場合、URLの形式も変わります。ここで重要なのは、上の例をそのままコピーすることではなく、Clash Vergeが待ち受けているポートとプロトコルを一致させることです。設定後は、プロキシ環境変数を持った同じターミナルからClaude Codeを起動します。

Claude Code向けのルール分けと長時間接続の考え方

分流では、最初から「AI関連の通信を全部プロキシ」という広いルールにするより、Clash Vergeのログで確認した認証・API・更新関連のホストを分類します。認証だけが失敗しているなら認証関連のホストを、推論ストリームだけが切れるならAPI関連のホストを対象にします。実際のドメインを確認せずに大量の DOMAIN-SUFFIX を追加すると、開発用パッケージ、テレメトリ、別サービスまで同じグループへ流れ、原因分析が難しくなります。

ルールは上から順番に評価されるため、狭い条件を上、広い条件を下へ置きます。たとえば、特定の認証ホストを専用グループへ送る DOMAIN 行を先に置き、その後に必要なサフィックス、最後に既定の MATCH を置く構成です。購読プロファイルが生成するルールを直接編集できない場合は、Clash Vergeのルールプロバイダや設定のオーバーライド機能を使います。編集後は構文エラーがないか、プロファイルを再読み込みして確認してください。

rules:
  - DOMAIN,auth.example.invalid,CLAUDE-AI
  - DOMAIN,api.example.invalid,CLAUDE-AI
  - DOMAIN-SUFFIX,example.invalid,CLAUDE-AI
  - MATCH,PROXY

上のドメインは構造を示すための例であり、実際の接続先を意味しません。自分のログに現れたホスト名へ置き換えてください。CLAUDE-AIのような専用グループには、まず安定性を優先したノードを一つ選びます。Claude Codeの作業中に自動選択が頻繁にノードを変更すると、認証トークンの取得やストリーミング接続が途中で切れる場合があります。速度だけでなく、長時間の接続維持、混雑時間帯の安定性、TLS接続の成功率を基準に選ぶのが実用的です。

ルールを追加した後は、必ず三つのテストを別々に行います。第一に認証フローを最初からやり直し、ブラウザからCLIへ正しく戻るか確認します。第二に短い質問を送り、最初の応答が返るまでの時間を測ります。第三にファイル検索やテスト実行を含む少し長いタスクを行い、途中で接続が切れないかを見ます。短いリクエストだけ成功して長いタスクで失敗するなら、ノード切り替えやアイドルタイムアウトを優先して調べます。

ターミナルで認証できないときの確認手順

まず、Claude Codeを起動しているターミナルが、Clash Vergeを起動したユーザー環境と同じか確認します。IDE内蔵ターミナル、SSHセッション、コンテナ、WSL、リモート開発環境では、ホスト側のシステムプロキシや環境変数がそのまま届かないことがあります。macOSやLinuxでは env | grep -i proxy、PowerShellでは環境変数を表示するコマンドを使い、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYの値を確認します。

次に、古いプロキシ設定や認証情報が残っていないかを見ます。以前使っていたVPN、開発用のローカルプロキシ、シェルの起動スクリプトが別のポートを指定していると、Clash Vergeのログに通信が現れません。ログに何も出ない場合は、Claude Codeが別環境で動いているか、プロキシ変数が無視されている可能性があります。反対に、ログに接続は現れるのに認証が戻らない場合は、命中ルール、TLS、認証レスポンスの順に調べます。

認証用ブラウザが別のプロファイルで開くケースもあります。会社の管理ブラウザ、広告ブロッカー、Cookie制限、ポップアップ制限が認証の戻り処理を妨げることがあるため、Clashだけを変更し続けるのは得策ではありません。ブラウザ側で認証を完了しているように見えても、CLI側のプロセスが待ち受けるローカルコールバックへ到達できなければ処理は終わりません。localhostや127.0.0.1を無条件にプロキシへ送らないよう、NO_PROXYやClashのルールを確認してください。

ログは「接続先」と「命中ルール」をセットで保存する認証に失敗した時刻、ターミナルのエラー、Clash Vergeに表示されたホスト名、選択されたグループを同じメモへ記録すると、ノード変更後の比較が容易になります。トークンやAPIキーなどの秘密情報はログとして共有しないでください。

まとめ：安定したCLI環境を作るために

一般的なVPNアプリや単純なシステムプロキシは、ブラウザ閲覧だけなら導入が簡単です。しかし、アプリ単位のログが見えない、ターミナルとGUIで経路が異なる、長時間のストリーミング接続が切れた理由を確認できない、といった不足があります。別のGUIクライアントでも手動プロキシ設定はできますが、プロファイルの切り替えとルールの命中状況を同じ画面で追跡しにくい場合があります。

その点、Clash Verge はシステムプロキシとTUNを用途に応じて選べ、接続ログからClaude Codeの認証・API通信・長時間タスクを段階的に検証できます。さらに専用グループと狭いルールを組み合わせれば、普段のWeb通信を巻き込みすぎず、ターミナルの出口だけを安定した経路へ寄せられます。特定のノードやホスト名を盲目的に固定するのではなく、ログを見て最小限の設定を保つことが、アップデート後にも維持しやすい構成です。

まずはシステムプロキシ、ターミナルの環境変数、Clash Vergeの接続ログを一つずつ確認し、短いリクエストから長いタスクへ進めてください。環境に合うクライアントの入手先と基本設定を整理してから始めたい場合は、次のダウンロード案内を確認するとスムーズです。

→ 無料でClashをダウンロードして、Claude Codeに合うクライアントと設定を確認しましょう。