この記事で分かること

Claude Codeをターミナルから起動したとき、ブラウザでは通信できるのに認証やモデルへのリクエストだけが失敗することがあります。この差は、Claude Code がターミナルのプロセスとして動き、ブラウザとは異なるプロキシ設定を参照するために生じる場合があります。Clash Verge でシステムプロキシを有効にしただけでは、シェルや CLI が同じ経路を使うとは限りません。

この記事では、Clash Verge にプロファイルを読み込んで接続先を選ぶところから、Claude Code の通信をルールに載せ、ターミナルでプロキシ環境変数を確認するところまでを順番に説明します。設定を変更した後は、短い接続テストを行い、Clash Verge の接続ログと照らし合わせます。画面の項目名や初期ポートはアプリのバージョン、OS、プロファイルによって異なるため、表示される設定値を確認しながら進めてください。

ここで扱うのはネットワーク経路の切り分けです。API の利用権限、アカウント状態、利用上限、Claude Code 自体のバージョンに起因するエラーは、プロキシ設定だけでは解消しません。まずは通信が Clash Verge を通っているかを確かめ、経路の問題とサービス側の問題を分けて考えることが大切です。

Clash Verge のプロファイルと接続状態を確認する

最初に、Clash Verge が起動しており、利用するプロファイルが読み込まれていることを確認します。プロファイルは通常、管理者や契約中のサービスから提供された購読 URL、または設定ファイルから追加します。購読 URL には接続先情報が含まれる場合があるため、公開のチャットや共有スクリーンショットに貼り付けないでください。追加後に更新を実行し、プロファイルがエラーなく読み込まれたこと、ノードやポリシーグループが表示されることを確かめます。

次に、Clash Verge の接続画面でコアが実行中かを確認し、利用可能なノードを一つ選びます。遅延テストの結果は参考になりますが、数値が小さいノードが Claude Code に必ず最適とは限りません。認証や長時間の応答が安定するかは、実際にリクエストして確認してください。ノードを選んでいない、または選択中のグループが有効なノードを含まない場合、ルールがプロキシを指していても通信できないことがあります。

初回の切り分けでは、システムプロキシや TUN を同時に何度も切り替えないようにします。まずは現在の状態を記録し、Clash Verge の画面に表示された HTTP、HTTPS、または混合ポートを確認してください。よくある初期値をそのまま決め打ちするのではなく、実際のポート番号を使うことが重要です。ほかの VPN やプロキシアプリが動作している場合は、原因が混ざらないよう、許可された範囲で一時的に停止して比較します。

確認項目 見る場所・内容 問題がある場合
プロファイル 更新が成功し、ルールとノードが読み込まれている 購読 URL、期限、更新エラーを確認する
コアとノード コアが稼働し、利用するグループに選択先がある コアの状態と選択中のノードを確認する
プロキシポート 画面に表示された HTTP/混合ポートを確認する 環境変数のポートと一致させる
競合アプリ 他の VPN、プロキシ、TUN が同時に動いていない 一つずつ停止して経路を比較する

Claude Code の通信をルールに載せる

Clash Verge のルールモードでは、通信先のドメインなどに応じて DIRECT やプロキシグループを選べます。Claude Code の API 通信をプロキシ経由にしたい場合は、接続ログに実際に現れた宛先を確認し、そのホストを適切なプロキシポリシーへ割り当てます。まずは API の代表的な宛先である api.anthropic.com を確認対象にします。認証や補助機能で別のホストが現れた場合は、名前を推測して一括登録するのではなく、ログと利用環境を照合して必要なものだけを追加してください。

ルールを設定ファイルへ追加する場合、次は書式の例です。PROXY はそのまま使える固定名称とは限らず、読み込んだプロファイルに実在するポリシーグループ名へ置き換える必要があります。また、同じ宛先に一致するルールがすでにある場合は、先に評価されるルールが適用されることがあります。新しいルールは既存ルールとの順序も確認し、意図したポリシーにマッチしているかを接続ログで確かめます。

rules:
  - DOMAIN,api.anthropic.com,YourProxyGroup
  # Keep the profile's remaining rules below this entry

ルールを編集する前に、元の設定をバックアップしておくと、入力ミスや更新後の差分を戻しやすくなります。購読型プロファイルは更新時に手動変更が上書きされる場合もあるため、Clash Verge が提供するオーバーライドやマージ機能を使えるか確認してください。設定ファイルを直接編集する場合は、YAML のインデントを崩さず、保存後にプロファイルの読み込みエラーがないことを確認します。

ルールモードなのにログ上で通信が DIRECT になっている場合、候補はルールの欠落、優先順位、別のプロファイルを編集していること、あるいはルールの再読み込み忘れです。逆にプロキシグループへ割り当てられているのに失敗する場合は、選択ノードや上流経路、DNS、サービス側の応答を確認します。ルールの設定だけで原因を断定せず、ログに表示される宛先、マッチしたルール、最終的なポリシーを一組として見てください。

ターミナルにプロキシ環境変数を設定する

Claude Code を起動するターミナルが、Clash Verge のローカルプロキシを参照できるようにします。ここではポート番号を仮に 7897 としていますが、実際には Clash Verge の画面に表示された HTTP または混合ポートへ置き換えてください。たとえば macOS や Linux の Bash、Zsh では、現在のターミナルセッションだけで試すために次のように設定できます。

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

設定後、env | grep -i proxy を実行し、値が表示されることを確認します。小文字と大文字の変数を両方設定しておくと、利用するツールや実行環境による参照方法の違いを切り分けやすくなります。ただし、すでに別のプロキシ値が設定されている場合は、上書きしてよいか確認してください。接続確認のためだけに設定するなら、シェルを閉じれば一時設定を解除できます。

Windows の PowerShell では、同じ端末内で試すときに次のように設定できます。ポート番号は必ず自身の Clash Verge の値に合わせます。

$env:HTTP_PROXY = "http://127.0.0.1:7897"
$env:HTTPS_PROXY = "http://127.0.0.1:7897"
$env:http_proxy = $env:HTTP_PROXY
$env:https_proxy = $env:HTTPS_PROXY

環境変数を設定したあとに Claude Code を起動してください。すでに起動しているプロセスは、後から変更した環境変数を引き継がないことがあります。IDE の統合ターミナルを使っている場合も、外部ターミナルとは別のシェル設定や起動環境が使われることがあります。外部ターミナルでは成功し、IDE 内だけ失敗するなら、IDE を再起動したうえで統合ターミナル内の環境変数を調べます。

設定を恒久化する場合は、利用中のシェルに合わせて設定ファイルへ追加できますが、まず一時設定で通信を確認するのが安全です。組織内ネットワークや共有端末では、プロキシ情報を環境変数に保存することがポリシーに反しないかも確認してください。ローカルアドレスへの通信をプロキシから除外する必要がある環境では、既存の NO_PROXY の内容を確認し、必要なローカルホストだけを適切に扱います。広い範囲を除外すると、Claude Code の通信まで直結になる可能性があります。

接続をテストし、エラーを切り分ける

Claude Code を起動する前に、同じターミナルからプロキシ経由の HTTPS 接続を試します。次のコマンドは接続先の応答ヘッダーを確認する例です。認証が必要な API では、未認証を示す応答が返る場合がありますが、TLS 接続や到達性の確認には役立ちます。ここでは API キーなどの秘密情報をコマンドラインへ貼り付けないでください。

curl -I https://api.anthropic.com

実行中は Clash Verge のログを開き、api.anthropic.com への通信が記録されるか、どのルールとポリシーが選ばれたかを確認します。ログに何も出ない場合は、コマンドや Claude Code が指定したポートを利用しているか、ターミナルの環境変数が設定されているかを見直します。ログに接続が出ていてもタイムアウトするなら、選択ノードを変えて再試行し、DNS や上流経路の問題がないか比較します。一度に複数の設定を変えると、改善した理由を追えなくなるため、変更は一つずつ行ってください。

  • 接続拒否:Clash Verge のコアが停止している、ポート番号が違う、または対象ポートで HTTP プロキシを待ち受けていない可能性があります。
  • 認証・API エラー:通信先へ到達した後の応答であれば、アカウント、API 利用権限、利用上限、サービス側の状態も確認します。
  • タイムアウト:ログで接続先とポリシーを確認し、ノードを変更して同じテストを比較します。モデル応答だけが遅い場合は、API の混雑や処理時間も考慮します。
  • 証明書エラー:OS の時刻、企業ネットワークの TLS 検査、証明書設定を確認します。原因を確かめずに証明書検証を無効化しないでください。
  • ブラウザだけ成功:ブラウザはシステムプロキシを使っていても、CLI は環境変数を参照していないことがあります。起動元ターミナルで変数とログを確認します。

確認が終わったら、システムプロキシや TUN を使う必要があるかを改めて判断します。環境変数を認識する CLI なら、ローカルプロキシを明示する方法のほうが、対象プロセスと経路を説明しやすいことがあります。アプリケーションが環境変数を無視する、または複数の通信が別経路へ漏れる場合は、Clash Verge のシステムプロキシや TUN を検討できます。ただし TUN は VPN、ファイアウォール、企業向けネットワーク製品と競合する場合があるため、必要性を確かめてから有効にします。

安定運用のための確認手順

Claude Code の通信が不安定なときは、毎回同じ順序で状態を確認すると、設定の再現性が高まります。まず Clash Verge のプロファイル、コア、選択ノードを確認し、次にターミナルの環境変数とポート番号を照合します。その後、短い curl テストと接続ログで、実際にプロキシを通ったか、どのルールに一致したかを記録します。設定を変更したら、古い Claude Code のプロセスを終了して新しく起動し、同じ操作をもう一度試してください。

仕事用と個人用のプロファイルを使い分ける場合は、どのプロファイルを選んだ状態で成功したかもメモしておきます。プロファイル更新後に手動ルールが残っているか、ポリシーグループ名が変わっていないかを点検することも重要です。接続ログにはホスト名や接続時刻などが含まれる場合があるため、共有する前に個人情報や機密情報が写っていないか確認し、購読 URL や認証情報は必ず伏せてください。

GUI のシステムプロキシ設定だけに頼る方法は手軽ですが、ターミナルのプロセスがその設定を参照しないと原因が見えにくくなります。一方、複雑なネットワークツールでは経路が複数に分かれ、CLI ごとの設定確認に手間がかかることがあります。Clash Verge なら、プロファイル、ルール、ノード、接続ログを一つの画面で確認しながら、環境変数によるプロセス単位の設定と組み合わせて切り分けられます。利用環境に合うクライアントと配布元を確認したい場合は、各プラットフォーム向けの案内をご覧ください。

ダウンロード →