この記事で分かること
Claude Codeをターミナルから使い始めたものの、認証画面が開かない、モデルへのリクエストが途中で止まる、長い処理だけタイムアウトするといった問題に悩んでいませんか。ブラウザ版の Claude が動いていても、Claude Code はターミナルから別の HTTPS 接続を作るため、Clash Verge の設定がそのまま反映されるとは限りません。
本稿では、国内の自宅回線や開発用 PC で Clash Verge を使い、Claude Code の通信を確認するための基本手順をまとめます。プロファイルの追加、プロキシポートの確認、HTTP_PROXY と HTTPS_PROXY の設定、Claude 関連ホストのルール分流、ログと curl による切り分けまで、実際に手を動かす順番で説明します。特定のノードやサービスを無条件に推奨する内容ではなく、利用中のネットワーク規約と Anthropic の利用条件を確認したうえで、安定した開発環境を組み立てるためのガイドです。
Claude Codeだけ接続に失敗する理由
Clash Verge のウィンドウでプロキシを有効にし、ブラウザでウェブサイトを開けたとしても、シェルから起動したプログラムが同じ経路を使うとは限りません。ブラウザは macOS や Windows のシステムプロキシ設定を参照することがありますが、Node.js、Python、Go などで作られた CLI は、独自の HTTP クライアントや環境変数を優先する場合があります。
そのため、次のような症状が出たときは、Claude Code のアカウントや API キーだけを疑うのではなく、まず通信経路を確認します。
- ログイン用のブラウザは表示されるが、認証後にターミナルへ戻ると処理が止まる。
- 短い質問は成功するが、長いコード解析やストリーミング応答で切断される。
- 同じコマンドでも、内蔵ターミナルと macOS の「ターミナル」、または PowerShell で結果が異なる。
- Clash Verge の接続ログに、Claude Code を実行した時刻の通信が表示されない。
最後の症状は特に重要です。ログに接続が存在しないなら、ノードの品質より前に、CLI がプロキシを認識していない可能性があります。反対にログへ接続が出ているのに失敗する場合は、ルール、DNS、TLS、ノードの切断などを順番に調べます。
事前準備：Clash Verge側を整える
設定を始める前に、Clash Verge が正常に起動し、Mihomo 系のコアが読み込まれていることを確認してください。アプリの名称や画面配置はバージョンによって異なりますが、基本的には「Profiles」「Proxies」「Rules」「Logs」またはそれに近い項目を使います。
| 確認項目 | 確認する内容 | 問題がある場合 |
|---|---|---|
| プロファイル | 購読 URL または YAML 設定が読み込まれ、現在使用中になっているか | URL の期限、入力ミス、配布元の障害を確認する |
| プロキシポート | HTTP または混合ポートの番号を確認する | ポート番号を推測せず、Clash Verge の設定画面から転記する |
| モード | Rule、Global、Direct のどれが選択されているか | 検証時は Rule または Global にし、切り替え後に再接続する |
| システムプロキシ | OS のプロキシを Clash Verge に向ける設定が有効か | ブラウザの確認には使えるが、CLI には環境変数も設定する |
プロファイルを追加した直後は、いきなり Claude Code を実行せず、まず一般的な HTTPS 通信で確認します。ノードを一つ選び、遅延テストの結果だけで判断せず、実際の接続ログと HTTPS 応答を確認してください。遅延が小さくても、長時間接続に弱いノードや、ストリーミング中に接続を閉じるノードは開発用途に向かないことがあります。
実践手順：ターミナルにプロキシを渡す
ここからは Claude Code を実行するターミナルへ、Clash Verge のローカルプロキシを明示的に渡します。ポート番号は環境によって異なるため、以下の例では 7890 を仮の値として使います。実際には Clash Verge に表示されている HTTP または Mixed ポートへ置き換えてください。
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
export NO_PROXY=127.0.0.1,localhost,::1環境変数名はソフトウェアによって参照方法が違うため、大文字だけで反応しない場合は小文字も追加します。
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
export no_proxy="$NO_PROXY"その同じターミナルで Claude Code を起動し、Clash Verge の Logs を開きます。プロキシ設定を ~/.zshrc や ~/.bashrc に保存すれば新しいシェルでも有効になりますが、社内ネットワークや国内サービスまで常にプロキシへ送ることがあります。常用する場合は、必要なプロジェクトや専用の起動スクリプトだけで設定する方法も検討してください。
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="127.0.0.1,localhost"設定後に同じウィンドウから Claude Code を実行してください。別の PowerShell、コマンドプロンプト、VS Code の統合ターミナルは、起動時の環境を別々に持つことがあります。設定が反映されないときは、ターミナルを閉じて開き直し、Get-ChildItem Env:*proxy* で値を確認します。
ルール分流：Claude関連通信を確認する
Clash Verge の Rule モードでは、接続先のドメインに応じて DIRECT やプロキシグループを選べます。Claude Code の通信を特定の経路へ送りたい場合、最初から大量のドメインを登録するのではなく、実際のログに現れたホストを確認して追加するのが現実的です。エンドポイントや補助ホストはクライアント更新で変わる可能性があるためです。
- API 本体の候補：
api.anthropic.com。まずこの接続がどのポリシーへ入ったかを確認します。 - ウェブ認証や補助サービス：
claude.aiなどが表示されることがあります。ただし、用途を確認せず一括でプロキシへ送らないでください。 - 開発ツールの取得先：npm、GitHub、パッケージ CDN などが別に表示される場合があります。Claude の API 通信と同じグループにする必要があるとは限りません。
ルールの優先順位にも注意が必要です。特定ドメインのルールを MATCH より下に置くと、先に読み込まれた汎用ルールへ到達して意図と違う経路になることがあります。ログに表示される「Matched Rule」「Policy」「Proxy Group」に相当する情報を確認し、ルールの追加後は既存接続を切るために Claude Code を再起動してください。
国内向けの運用では、すべてをプロキシへ送るより、国内の銀行、行政、社内 Git、会社の VPN などを必要に応じて DIRECT に残す方がトラブルを減らせます。組織のネットワークでは、プロキシ経由の AI サービス利用やソースコード送信が規約で制限されていることもあります。個人の設定であっても、会社や顧客のコードを入力する場合は、データ保持と学習利用に関する契約条件を確認してください。
接続テストとトラブルシューティング
Claude Code の画面だけを見ていると、認証エラー、経路エラー、サービス側の制限を区別しにくいことがあります。まず Clash Verge のログを表示した状態で、ターミナルから接続テストを実行します。
curl -I -v --proxy http://127.0.0.1:7890 https://api.anthropic.com/このコマンドの目的は、認証済み API 呼び出しを行うことではありません。プロキシへ接続できるか、TLS ハンドシェイクまで進むか、Clash Verge に対象ホストが記録されるかを確認するためのテストです。401 や 404 が返っても、ネットワーク層が応答しているなら、少なくとも「完全に到達不能」という問題とは切り分けられます。
ログに何も出ない場合は、ポート番号、Clash Verge の起動状態、環境変数の綴りを確認します。接続先が 127.0.0.1 ではなく別のアドレスになっている場合や、コンテナ内からコマンドを実行している場合、コンテナから見た localhost はホスト PC と異なります。Docker や WSL を使うときは、ホストへ到達できるアドレスとファイアウォールの許可も確認してください。
ログには接続が出るものの Claude Code だけが失敗する場合は、次の順番で調べると効率的です。
- Clash Verge で選択中のノードを変更し、同じ操作を再試行する。
- Rule モードと Global モードを短時間だけ比較し、ルール漏れかノード品質かを分ける。
- 古い Claude Code プロセスを終了し、環境変数を設定した新しいターミナルから起動する。
- 企業プロキシやウイルス対策ソフトが TLS を検査していないか確認する。
- API の利用権限、アカウント状態、レート制限、モデル名を公式の案内と照合する。
ストリーミング応答だけが途中で止まるなら、単純な DNS 失敗ではなく、ノードや中継装置が長時間接続を閉じている可能性があります。短い応答、長い応答、連続した複数リクエストを分けて試し、どの条件で失敗するかを記録してください。発生時刻、使用ノード、Clash のルール名、エラー文を残しておくと、設定を戻した後の比較やサポートへの問い合わせにも役立ちます。
安定運用のためのチェックポイント
動作確認が終わったら、設定を増やしすぎないことが大切です。Claude Code 用に作った環境変数を全ユーザー環境へ永続化すると、Git、npm、社内ツールまで同じプロキシを使い始めることがあります。プロジェクト単位のスクリプト、シェルの関数、または専用のターミナルプロファイルに閉じ込めると、意図しない通信経路を減らせます。
また、Clash Verge のプロファイル更新後は、プロキシグループ名やルールの並び順が変わっていないかを確認してください。購読更新が成功しても、選択中のグループが自動で別ノードへ変わる場合があります。重要な作業の前には、短いテストリクエストを行い、ログに期待するホストとポリシーが出ることを確認する習慣をつけると安心です。
同類の GUI プロキシツールは、システムプロキシだけを切り替える設計だとブラウザは動いても CLI や開発コンテナへ設定が届かず、逆に全体 VPN 型のツールは社内ネットワークや国内サービスまで迂回して原因を追いにくくなることがあります。それに対して Clash Verge は、環境変数、Rule 分流、ログ、必要時だけの TUN を段階的に選べるため、Claude Code の API 通信だけを検証しながら構成を調整できます。もし複数の端末や開発用途で同じ考え方を試したいなら、利用規約とネットワークポリシーを確認したうえで、対応する Clash クライアントをダウンロードして環境に合わせて始めるのが自然です。