Claude Codeをターミナルから利用するとき、ブラウザでは問題なく通信できるのに、Claude Codeだけが接続待ちになったり、認証処理で失敗したりすることがあります。これは、Clash Vergeの「システムプロキシ」がオンになっていても、ターミナルやNode.jsベースのCLIツールがその設定を自動的に読み取るとは限らないためです。本稿では、Clash Vergeへサブスクリプションを読み込むところから、実際のプロキシポートの確認、macOS・Linux・Windowsのターミナルへの反映、接続テスト、TUNモードを使う場合の注意点までを順番に整理します。設定を一度に変更しすぎず、各段階で通信を確認することが、原因を早く特定するポイントです。
Clash Vergeにサブスクリプションを読み込む
最初に確認すべきなのは、Clash Verge自体が正常に起動し、利用可能なプロファイルとノードを読み込めているかどうかです。Claude Codeの環境変数を設定しても、Clash Verge側のコアが停止していたり、選択中のプロファイルに有効なプロキシグループがなかったりすれば、ターミナルからの通信は成功しません。
サブスクリプションを追加して更新する
- Clash Vergeを起動し、プロファイルまたはProfilesの管理画面を開きます。
- サブスクリプション提供元から取得したURLを、サブスクリプション追加欄へ貼り付けます。
- 追加したプロファイルの更新を実行し、YAMLの取得が成功するか確認します。
- 取得後のプロファイルを選択し、Proxy画面で実際に使用するプロキシグループを選びます。
- 必要であれば、同じグループ内の別ノードへ切り替え、接続状態を比較します。
更新に失敗する場合は、Claude Codeの設定に進む前にサブスクリプションの問題を解決してください。HTTP 403や404はリンクの権限・期限・URLの誤り、タイムアウトは提供元または現在の回線から配布サーバーへ到達できない可能性を示します。更新は成功してもノード一覧が空になる、または以前より大幅に減る場合は、提供元側の設定変更や期限切れも確認します。
サブスクリプションURLにはアカウントを識別する情報が含まれることがあります。公開チャットや無関係なオンラインテスターに貼り付けず、漏えいが疑われる場合は提供元の管理画面からリンクを再発行してください。
Claude Codeが使うローカルポートを確認する
Claude CodeからClash Vergeへ接続するには、Clashのローカルリスニングポートを正しく指定する必要があります。Clash Vergeの設定画面では、HTTPポート、SOCKSポート、Mixedポートなどが表示されます。環境変数を簡単に扱うなら、HTTPとSOCKSの両方を受け付けるMixedポートを使う方法が分かりやすいでしょう。よく見かける番号は7890や7897ですが、これは固定値ではありません。必ず現在の画面に表示されているポートを使用してください。
| 確認項目 | 意味 | 注意点 |
|---|---|---|
| HTTPポート | HTTP CONNECTを含むHTTPプロキシ接続を受け付ける | HTTPS通信でも環境変数のURLは通常http://で指定する |
| SOCKSポート | SOCKS5形式のプロキシ接続を受け付ける | ツールがSOCKS環境変数に対応しているか確認する |
| Mixedポート | HTTPとSOCKSの両方を受け付ける | CLIの検証用に使いやすいが、実際の番号は設定によって異なる |
| Allow LAN | ローカル以外の機器からの接続を許可する | 同じPCのClaude Codeだけなら通常は不要で、無用な公開を避ける |
ターミナルへプロキシ設定を反映する
Clash Vergeのシステムプロキシをオンにするだけでは、Claude Codeの通信経路が変わらないことがあります。ターミナルで動作するCLIは、OSのGUIプロキシ設定ではなく、HTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を参照することが多いからです。まずは現在のシェルで一時的に設定し、接続確認が終わってから永続化する手順が安全です。
macOS・Linuxで設定する
Clash VergeのMixedポートが7890の場合、zshやbashでは次のように設定します。ポート番号は自分の環境に置き換えてください。
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"
export NO_PROXY="localhost,127.0.0.1,::1"
HTTPS通信であっても、プロキシサーバーの指定方式は通常 http://127.0.0.1:7890 です。これは「宛先がHTTPSであること」と「ローカルプロキシへ接続する方式」が別だからです。https://127.0.0.1:7890 と書くと、ClashのローカルポートへTLSで接続しようとして失敗する場合があります。
設定が反映されたかどうかは、次のコマンドで確認できます。
env | grep -i proxy
curl -I https://api.anthropic.com
シェルを開くたびに設定したい場合は、zshなら ~/.zshrc、bashなら ~/.bashrc など、実際に使用しているシェルの起動ファイルへ追記します。編集後は新しいターミナルを開くか、次のように読み込み直します。
source ~/.zshrc
Windows PowerShellで設定する
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"
$env:NO_PROXY="localhost,127.0.0.1"
環境変数を設定したPowerShellからClaude Codeを起動する必要があります。別のターミナルウィンドウ、IDE内蔵ターミナル、タスクランナーから起動したプロセスには、設定前の環境が渡されることがあるためです。永続化する場合はユーザー環境変数として登録できますが、会社の端末や共有PCでは認証情報・通信経路の管理方針に従ってください。
環境変数名はツールによって参照される大文字・小文字が異なる場合があります。確実性を高めるため、HTTP_PROXYとHTTPS_PROXYに加えて、対応する小文字の変数も必要に応じて設定します。重複した値がある場合は、どの値を採用しているか確認してください。
Claude Codeの通信を段階的にテストする
いきなり認証や大きな処理を実行するのではなく、まずプロキシポート、次にHTTPS接続、最後にClaude Codeという順序でテストします。こうすると、Clashの問題とCLIの認証問題を混同せずに済みます。
ローカルポートが待ち受けているか確認する
macOS・Linuxでは、ClashのポートへTCP接続できるかを次のように確認できます。
nc -vz 127.0.0.1 7890
Windows PowerShellでは次のコマンドを使えます。
Test-NetConnection 127.0.0.1 -Port 7890
ここで接続できない場合、環境変数を何度修正しても解決しません。Clash Vergeのコアが起動しているか、プロファイルが選択されているか、ポート番号が一致しているかを確認します。別のアプリが同じポートを使用している、ポート設定を変更したのにコアを再起動していない、といったケースもあります。
curlでHTTPSプロキシ接続を確認する
ローカルポートが開いていることを確認したら、環境変数を使った状態でHTTPSリクエストを送ります。
curl -v https://api.anthropic.com
詳細表示にプロキシへの接続とCONNECT処理が現れれば、少なくともターミナルからClashへ到達しています。401や403のようなHTTP応答が返る場合も、ネットワーク経路自体は成立している可能性があります。反対に、Connection refusedはローカルポートの問題、Could not resolve hostはDNS解決、Connection timed outはノード・回線・ルールのいずれかを優先して調べます。
Clash Vergeのログ画面も同時に開き、テスト時刻に対象ドメインの接続記録が出るか確認してください。ログがまったく増えないなら、Claude Codeまたはcurlが環境変数を読んでおらず、Clashを経由していない可能性があります。
TUNモードを使う場合と接続トラブルの切り分け
環境変数を設定してもClaude Codeの通信が一貫しない場合、TUNモードを検討できます。TUNは仮想ネットワークインターフェースを作成し、アプリケーションがプロキシ設定を読むかどうかに依存せず、より広い範囲の通信をClashへ取り込む方式です。ただし、TUNを有効にすれば必ず問題が解決するわけではありません。仮想インターフェース、ルーティング、DNS、権限の状態が合っていないと、通常のシステムプロキシより複雑な障害になることもあります。
TUN有効化時の確認項目
- Clash VergeのTUN設定を有効にし、OSから仮想ネットワークインターフェースが認識されているか確認する。
- Windowsでは管理者権限、macOSやLinuxでは必要な権限やネットワーク拡張の許可が求められる場合がある。
- DNS hijackやfake-ipを使う場合、ローカル開発用ドメイン、
localhost、プライベートネットワークを誤ってプロキシへ送らないよう確認する。 - VPN、別の仮想NIC、セキュリティソフトが同時にルートを変更していないか確認する。
- まずTUNを無効にして環境変数方式で再テストし、どちらの方式で症状が変わるか比較する。
よくある症状から原因を絞り込む
| 症状 | 優先して確認する箇所 | 対処の方向 |
|---|---|---|
| Clashのログに通信が出ない | 環境変数、起動シェル、IDEのターミナル | 同じセッションで変数を確認し、そこからClaude Codeを起動する |
| 127.0.0.1への接続拒否 | Clashコア、リスニングポート | コアを起動し、画面に表示されたポートへ修正する |
| DNS解決エラー | DNS設定、TUNのDNS hijack、ルール | Clashログと直接接続時の名前解決結果を比較する |
| HTTPSハンドシェイク失敗 | 選択ノード、TLS、セキュリティソフト | 別ノードを試し、時刻や証明書検査のエラーをログで確認する |
| 認証だけ失敗する | Claude Codeの認証状態、環境変数、アカウント設定 | 通信成功と認証成功を分けて確認し、認証情報を再設定する |
ノードを無作為に何度も変更するより、同じノードでcurlの結果とClashログを保存し、その後に別ノードと比較する方が効率的です。特定ノードだけ失敗するならノード側の停止やプロトコルパラメータを疑い、すべてのノードで失敗するならローカル回線、DNS、Clashのポート、あるいはサブスクリプション全体を疑います。設定ファイルを編集する場合は、変更前のバックアップを残し、1回に1項目だけ変更して結果を記録してください。
安定した構成は、Clash Vergeで有効なプロファイルとプロキシグループを選択し、実際のMixedポートを確認したうえで、Claude Codeを起動するターミナルへHTTP_PROXYとHTTPS_PROXYを渡す構成です。TUNを使う場合も、まず環境変数方式で基本経路を検証してから段階的に切り替えると、問題の範囲を小さく保てます。
Clashクライアントを入手する
Clash Vergeの基本設定、対応クライアント、プロファイルの扱い方を確認し、Claude Codeを含むターミナルツールの通信環境を整えましょう。