Claude CodeをClash Vergeで使う設定と接続トラブル対策

Claude CodeとClash Vergeの通信経路を理解する

Claude Codeの通信は、ターミナルで実行したプロセスから外部の認証サービスやAPIエンドポイントへ向かいます。Clash Vergeのシステムプロキシが有効な場合、対応するアプリケーションはWindowsやmacOSのプロキシ設定を参照し、ClashのHTTPプロキシまたは混合ポートへ接続できます。しかし、ターミナル、Node.js、シェルスクリプト、開発用ランタイムは、システム設定を常に同じ方法で読み取るとは限りません。

そのため、確認すべき経路は大きく3つあります。1つ目はブラウザーなどがOSのシステムプロキシを使う経路です。2つ目は、シェルに HTTP_PROXY、HTTPS_PROXY、ALL_PROXY などを設定し、コマンドラインツールへ明示的にプロキシを渡す経路です。3つ目はTUNモードで、対応するネットワーク通信を仮想インターフェースからClashへ取り込む経路です。

最初からTUNモードと複数の環境変数を同時に有効にすると、どの設定が通信経路を決めているのか分かりにくくなります。まずはClash VergeのHTTPまたはmixed-portを明示的に指定する方法で動作を確認し、必要な場合だけTUNモードへ進むのが安全です。

Clash Verge側でポートとノードを準備する

Clash Vergeを開いたら、使用中のプロファイルが正常に読み込まれていることを確認します。プロファイルの形式がYAMLであっても、現在のコアがその中のすべてのフィールドやプロトコルに対応しているとは限りません。コアの起動エラー、プロキシグループの空欄、ノードの遅延テスト失敗がある場合は、Claude Codeの設定を変更する前に解消してください。

1. Clash Vergeでプロファイルを選択し、コアが起動していることを確認します。
2. プロキシグループから、接続テストに使う安定したノードを手動で選びます。最初の検証では頻繁に切り替わる自動グループを避けると、結果を比較しやすくなります。
3. 設定画面でHTTPポート、SOCKSポート、またはmixed-portの番号を確認します。例として 127.0.0.1:7890 が使われることがありますが、実際の番号は環境によって異なります。
4. ブラウザーでHTTPSサイトを開き、Clash Vergeの接続ログにリクエストが表示されることを確認します。
5. システムプロキシを有効にした場合は、OSのプロキシ設定が古いポートを指していないか確認します。

HTTPプロキシを使う場合、環境変数の値は一般に http://127.0.0.1:ポート番号 のような形式になります。SOCKSポートを使う場合は、ツールやランタイムがSOCKSをサポートしているかを確認してください。対応が不明なときは、まずClash Vergeのmixed-portまたはHTTPプロキシポートを使う方が切り分けやすいでしょう。

ターミナルからプロキシを明示的に設定する

システムプロキシを有効にしてもClaude Codeが接続できない場合は、ターミナルの環境変数を一時的に設定して動作を比較します。環境変数は現在開いているシェルと、そのシェルから起動したプロセスに適用されます。Clash Vergeのポート番号は、実際の画面に表示されている値へ置き換えてください。

シェル別の一時設定

macOSやLinuxのbash、zshでは、次のように設定できます。通常のHTTPS通信を対象にする場合は、まず HTTPS_PROXY を指定します。ツールによって参照する変数名が異なるため、互換性を確認する目的で大文字と小文字の両方を設定する方法もあります。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"

claude

Windows PowerShellでは、現在のセッションだけに適用する設定を次のように記述します。

$env:HTTP_PROXY = "http://127.0.0.1:7890"
$env:HTTPS_PROXY = "http://127.0.0.1:7890"

claude

SOCKSを利用する場合は、クライアントやNode.jsの通信ライブラリが socks5 または socks5h を解釈できるかを確認してください。対応していない処理にSOCKSのURLを渡すと、プロキシが起動していても接続エラーになります。まずHTTP形式のmixed-portで確認し、必要性が明確な場合だけSOCKSを試すのが無難です。

プロキシを使わない宛先を指定する必要がある場合は、NO_PROXY を利用できます。ただし、広すぎる除外は通信を直接接続へ逃がしてしまいます。社内ホストやローカル開発サービスなど、本当に直接接続が必要な宛先だけを列挙してください。

export NO_PROXY=localhost,127.0.0.1
# PowerShell
$env:NO_PROXY = "localhost,127.0.0.1"

設定を恒久化する場合は、bashやzshのプロファイル、PowerShellのプロファイルへ追加できます。ただし、会社の端末や共有環境では、認証情報を含むURLをシェル履歴や設定ファイルへ保存しないでください。Clashのローカルポートに認証が必要な環境であっても、トークンやパスワードをコマンド履歴へ直接書く方法は避け、使用中のクライアントが提供する安全な認証方法を確認してください。

実際に通信経路を確認する手順

設定を変更した後は、いきなりClaude Codeの複雑な操作を試すのではなく、低い層から順番に確認します。目的は「インターネットに接続できるか」だけでなく、「Clash Vergeのログにリクエストが現れたか」を確認することです。ログに記録がなければ、ルールやノードより前の段階で通信がClashへ届いていない可能性があります。

1. ローカルポートを確認します。Clash Vergeでコアが起動し、待ち受けポートが表示されていることを確認します。
2. CLIの簡単なHTTPS通信を試します。利用可能な環境で、設定したプロキシを明示して curl を実行します。
3. Clash Vergeのログを見ます。コマンド実行時刻に対応する接続先が表示されるか確認します。
4. 同じターミナルからClaude Codeを起動します。別のターミナルを開くと環境変数を継承していない場合があるため、設定したセッションから実行します。
5. ノードを固定して再試行します。自動選択による切り替えを停止し、同じノードで成功と失敗を比較します。

curl -I -x http://127.0.0.1:7890 https://example.com

このコマンドの結果だけでClaude Codeの利用可否を断定することはできませんが、ClashのHTTPプロキシポートへ接続できるかを確認する材料になります。接続ログが表示され、レスポンスも返るなら、少なくともローカルポート、基本的なTLS通信、選択中のノードは動作している可能性が高くなります。反対に、接続拒否ならポート番号、コアの状態、ファイアウォールを確認します。タイムアウトなら、ノード、ルール、DNS、上流ネットワークを順番に切り分けます。

認証エラーと通信不良を切り分ける

認証エラーが表示されたとき、すぐにAPIキーを再発行したり、Clashの設定を全面的に書き換えたりするのは避けてください。認証ページを開くブラウザーと、認証後にAPIへ接続するClaude Codeのプロセスが、異なるネットワーク経路を使っていることがあります。ブラウザーだけがシステムプロキシを利用し、ターミナルは直接接続しているケースでは、ログイン画面は進んでも後続の通信が失敗する可能性があります。

代表的な症状から確認する

• ブラウザーもClaude Codeも接続できない：Clash Vergeのコア、ノード、システムネットワーク、DNSを先に確認します。
• ブラウザーは接続できるがCLIだけ失敗する：ターミナルへ HTTPS_PROXY が反映されているか、CLIを同じシェルから起動しているか確認します。
• ClashのログにCLIの通信が出ない：環境変数の名前やURL形式が誤っている、またはツールがその変数を参照していない可能性があります。
• ログには通信が出るがTLSエラーになる：ノードの安定性、システム時刻、TLSインターセプトの有無、プロキシのHTTPS処理を確認します。
• 認証後にセッションが維持されない：ブラウザー連携、認証キャッシュの権限、端末時刻、プロキシの断続的な切り替えを確認します。

Clash Vergeのルールが原因の場合、認証サービスやAPIのドメインが意図せず REJECT や不適切なグループへ送られていないかをログで確認します。ドメイン名を推測して固定ルールを大量に追加するより、実際の接続ログに表示された宛先、使用された策略グループ、接続結果を見てから最小限のルールを調整してください。サービス側のエンドポイントは変更される可能性があるため、古い記事のドメイン一覧をそのまま設定へ貼り付けるのは危険です。

DNSモードを変更した直後にだけ失敗する場合は、DNS解決とプロキシ接続を分けて調べます。ホスト名が解決できない、IPv6経路だけ失敗する、TUNモードでDNS要求が別経路へ出るといった問題が重なることがあります。まずTUNを一時的に無効にし、明示したHTTPプロキシと固定ノードで再現性を確認すると、設定の層を減らして原因を絞れます。

安定運用のための設定と戻し方

接続できるようになった後は、設定を最小限に整理します。常にターミナルからClaude Codeを使うなら、使用するシェルのプロファイルへプロキシ環境変数を追加する方法があります。一時的な作業だけなら、セッション単位で設定し、終了時に環境変数を解除する方が他の開発ツールへの影響を抑えられます。

unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy NO_PROXY
# PowerShell
Remove-Item Env:HTTP_PROXY, Env:HTTPS_PROXY, Env:NO_PROXY

システムプロキシ、環境変数、TUNモードを同時に使用する場合は、同じ通信が二重にプロキシを通らないよう注意してください。二重経路は必ずしも機能しないわけではありませんが、TLSエラー、遅延、DNSの不一致、接続ログの読みづらさにつながります。通常は、開発用CLIに環境変数を使うか、TUNでシステム全体を取り込むかのどちらかを基本にし、目的に応じて選びます。

Clash Vergeや内蔵コアを更新した後は、ポート、プロファイル、プロキシグループ、TUN、DNSの状態が変わっていないか確認してください。GUIの更新とコアの更新は別に扱われることがあり、クライアントが新しくても設定フィールドやプロトコルの互換性が自動的に保証されるわけではありません。2026年時点でも、トラブル対策の基本は「クライアントが起動しているか」「コアが設定を読み込めているか」「CLIの通信がClashのログに現れるか」を順番に見ることです。

最終的には、ブラウザーの通信確認、CLIの明示的なプロキシ確認、Claude Codeの認証確認を別々に行うと、問題の位置を正確に把握できます。認証を何度もやり直す前に、ターミナルが実際にClash Vergeへ接続しているかを確認することが、最も短い解決手順になります。