Claude Codeを快適に使うためのClash Verge設定ガイド

Claude Code に必要な通信と Clash Verge の役割

Claude Code はターミナルからコードの読解、編集、テスト実行、Git 操作などを行う開発ツールである。通常のブラウザー利用とは異なり、認証処理、API リクエスト、設定確認、モデル情報の取得などが複数の HTTPS 通信として発生する。したがって、ブラウザーだけがプロキシ経由になっていても、ターミナルで起動した Claude Code の通信が同じ経路を通るとは限らない。

Clash Verge はプロキシノードを管理する GUI であり、実際に通信を処理するのは内蔵された Clash Meta または mihomo 内核である。Clash Verge でプロファイルを読み込み、システムプロキシを有効にすると、HTTP プロキシに対応したアプリケーションは設定された入口を利用できる。一方、ターミナル上の Node.js、Python、curl、Git などは、環境変数を個別に参照する場合がある。最初に「Clash Verge が起動しているか」「内核が正常に動作しているか」「Claude Code のプロセスがどの入口を使うか」を分けて確認することが重要だ。

本稿では、Clash Verge Rev を含む Clash Verge 系クライアントと mihomo 内核を前提に、通常のシステムプロキシ、ターミナル用の環境変数、ルールによる通信分け、そして設定後の検証方法を順に整理する。プロバイダーから取得したサブスクリプションの内容を全面的に書き換えるのではなく、必要な部分だけを上書きする構成を基本とする。

Clash Verge 側で確認する基本設定

まず Clash Verge を起動し、使用するプロファイルを選択する。プロファイルが読み込まれていても、内核が停止していれば通信は処理されない。画面上でプロファイルが有効になっていること、プロキシグループに利用可能なノードが表示されていること、内核のログに設定エラーが出ていないことを確認する。

次に、モードは通常「Rule」を選ぶ。Global はすべての通信をプロキシ側へ送るため原因の切り分けには便利だが、開発環境のパッケージレジストリ、社内 Git、ローカルホストまでプロキシへ送る可能性がある。Direct はすべてを直結するため、対象サービスへの接続確認以外では適切でない。Rule モードなら、ドメインや IP に応じて Claude Code 関連通信、一般サイト、ローカルネットワークを分離できる。

Clash Verge の設定画面では、システムプロキシのスイッチと TUN モードを混同しないようにする。システムプロキシは OS の HTTP・HTTPS プロキシ設定を変更する機能で、対応アプリに対して有効である。TUN は仮想ネットワークインターフェースを作り、アプリケーションがプロキシ設定を持たない場合でも、より広い範囲の TCP・UDP 通信を内核へ渡す方式だ。ただし、管理者権限、仮想インターフェース、DNS、VPN ソフトとの競合が関係するため、まずはシステムプロキシと環境変数で動作を確認し、必要な場合だけ TUN を使う方が安全である。

ターミナルにプロキシを渡す手順

Claude Code を起動するターミナルから Clash のローカルプロキシを明示的に利用するには、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY などの環境変数を設定する。Clash Verge のポート番号は環境によって異なるため、画面または設定ファイルで mixed-port、port、socks-port の実際の値を確認する。以下では HTTP と SOCKS の混合ポートが 7890 で待ち受けている例を示す。

# macOS / Linux: 現在のシェルで有効
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# 設定を確認
env | grep -i proxy

# 不要になった場合は解除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

HTTPS_PROXY の値に http:// を指定するのは誤りではない。これは接続先が HTTPS であっても、ローカルの HTTP CONNECT プロキシへ接続するという意味である。Clash の SOCKS ポートを使う場合は、クライアントが SOCKS5 を正しく解釈できることを確認する。環境変数名はツールによって大文字・小文字の扱いが異なるため、互換性を重視する場合は小文字も設定しておくとよい。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890
export no_proxy=127.0.0.1,localhost,::1,.local

Windows の PowerShell では次のように設定できる。これは現在開いている PowerShell セッションだけに適用されるため、別のターミナルを開いた場合は再設定が必要になる。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7890"
$env:NO_PROXY="127.0.0.1,localhost"

環境変数を恒久的に登録する場合は、シェルの設定ファイルや OS のユーザー環境変数を利用する。ただし、会社内の Git サーバーやローカル API まで外部プロキシへ送らないよう、NO_PROXY に内部ドメインとループバックアドレスを追加する。共有端末や自動化環境では、プロキシ設定を常時残すことが情報漏えいの原因になる場合もあるため、作業終了時に解除する運用が望ましい。

Claude Code 関連ドメインをルール分けする

プロファイルの rules には、Claude Code が利用するサービスのドメインを必要に応じて追加する。一般に API 通信の中心は api.anthropic.com であり、ログイン方式や利用中の機能によって Anthropic の認証・コンソール関連ドメインへのアクセスも発生する。実際に必要なドメインは Claude Code のバージョン、認証方式、地域、設定によって変わるため、固定リストを無条件に増やすのではなく、Clash Verge の接続画面で実際の接続先を確認してから追加する。

ルールは上から評価され、最初に一致した行で処理が確定する。特定ドメインを専用グループへ送る場合は、広い GEOSITE、RULE-SET、GEOIP、MATCH より前に記述する。プロキシグループ名はサブスクリプションによって異なるため、例の Claude-Proxy は実際に存在するグループ名へ置き換える必要がある。

rules:
  - DOMAIN,api.anthropic.com,Claude-Proxy
  - DOMAIN-SUFFIX,anthropic.com,Claude-Proxy
  - DOMAIN-SUFFIX,claude.ai,Claude-Proxy
  - DOMAIN,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - MATCH,選択

DOMAIN-SUFFIX,anthropic.com は配下のサブドメインも対象にするため、必要以上に広い通信をプロキシへ送る可能性がある。最小限の構成を好む場合は、接続ログに現れたホスト名を確認し、DOMAIN,api.anthropic.com のような完全一致ルールから始める。逆に認証画面や利用状況の取得が失敗する場合は、コンソールや認証関連の実ドメインが別に存在しないかを確認する。

動作確認とトラブルシューティング

設定を保存したら、いきなり Claude Code だけで判断せず、段階的に確認する。まず Clash Verge の接続ログを開き、プロキシ入口に接続が届いているかを見る。次にターミナルから対象ドメインへ HTTPS リクエストを送り、DNS 解決と TLS 接続が成功するかを確認する。レスポンスの内容そのものより、Clash のログで実際のルールと出口グループが表示されることを重視する。

# HTTP_PROXY の経路を使った接続確認
curl -I https://api.anthropic.com

# 環境変数を一時的に無視して比較
env -u HTTP_PROXY -u HTTPS_PROXY -u ALL_PROXY \
  curl -I https://api.anthropic.com

プロキシ経由では接続できるが Claude Code だけ失敗する場合、起動したシェルが環境変数を継承しているか、Claude Code 側の通信ライブラリがその変数に対応しているかを確認する。逆に curl も失敗する場合は、ノードの状態、プロファイルのルール、DNS、ローカルポートの順に切り分ける。認証画面だけが開かないときは、ブラウザーとターミナルが異なるプロキシを使っている可能性が高い。

「接続は成功するが応答が遅い」場合は、ノードの遅延だけでなく DNS の解決経路、TUN とシステムプロキシの二重適用、TLS 接続の再試行も確認する。TUN を有効にした状態で環境変数も設定すると、アプリによっては同じ通信が二重にプロキシ処理されることがある。まずシステムプロキシまたは TUN のどちらか一方を主経路として選び、不要な方式を停止して比較する。

API キーを環境変数へ保存している場合は、設定ファイル、シェル履歴、CI ログ、画面共有に露出させない。認証方式に応じた公式の手順を使い、キーや OAuth 用の認証情報をプロキシ設定の YAML に直接書かないことも重要である。Clash のログレベルを一時的に上げて調査した後は、通常の warning または info に戻し、認証情報やリクエスト内容が不要に記録されない状態で運用する。

安定運用のための設定方針

Claude Code を日常の開発作業で使うなら、最初から複雑なルールセットを導入するより、専用のプロキシグループを一つ用意し、Anthropic 関連の通信だけをそこへ送る構成が管理しやすい。自動選択グループを使う場合も、測定 URL が常に利用できるとは限らないため、手動選択できる予備ノードを残しておく。ノードを切り替えた後は、既存の認証セッションが再利用されるとは限らないため、認証状態と接続ログを改めて確認する。

設定を変更する前には、現在動作しているプロファイルをバックアップする。サブスクリプション本体を直接編集せず、Merge やローカルオーバーライドで差分を管理すれば、更新後の復元が容易になる。ルールを追加した後は、構文チェック、Clash Verge の再読み込み、curl による確認、Claude Code の実行という順序で検証すると、どの段階で問題が起きたかを特定しやすい。

重要なのは、Claude Code の不具合とネットワーク経路の不具合を分けて考えることである。Clash Verge の接続ログに対象ドメインが現れ、想定したプロキシグループへ振り分けられ、ターミナルから HTTPS 接続が成功しているなら、次は認証状態、アカウント権限、モデル利用条件、Claude Code 自体の設定を確認する段階になる。この切り分けを守れば、ノードを無作為に変更したり、ルールを大量に追加したりする必要はない。