Windows版Clash Verge Revの導入・設定ガイド｜システムプロキシ、TUN、よくあるエラー

インストール前に確認：Windowsのアーキテクチャとクライアントの役割

Clash Verge Revは、サブスクリプションの管理や設定の切り替え、システムプロキシ、サービスの操作を行うGUIクライアントです。通信のルール判定や接続先への通信はmihomoコアが担います。クライアントをインストールしただけでは、利用可能なノードは使えません。初回利用時には、有効なサブスクリプションURLか、ノード・プロキシグループ・ルールを含むローカルのYAML設定ファイルが必要です。

Windowsの「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。x64のPCにはx64版、ARM64デバイスには対応するARM64版のインストーラーを選んでください。
クライアントのダウンロードページで、Clash Verge RevのWindows版とシステム要件を確認できます。旧バージョンのWindowsがサポートされているかは、選択したリリースの説明をご確認ください。
使用中のプロキシツールの状態を確認しておきます。初回の動作確認では、ほかのVPN、プロキシクライアント、ネットワーク高速化ツールを終了してください。複数のアプリが同時にシステムプロキシやデフォルトルートを変更するのを防げます。
既存のサブスクリプションやオーバーライド設定はバックアップしてください。サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、公開チャットに貼ったり、スクリーンショットに写したりしないでください。

インストール時はウィザードに従って保存先を選びます。通常、クライアントの画面操作には一般ユーザー権限で十分です。システムサービスのインストール、仮想ネットワークアダプターの作成、ルートの変更には管理者の許可が必要です。組織管理下のデバイスでは、ネットワークサービスのインストールが許可されているか確認し、セキュリティポリシーを無効にして回避しないでください。

サブスクリプションを追加する：設定が有効か確認

リモートサブスクリプションとローカルファイルの追加手順

「サブスクリプション」画面を開き、入力欄にURL全体を貼り付けてインポートします。使用中のバージョンでインポートが「新規作成」内にある場合は、リモート設定を選んでからURLを入力してください。
ダウンロードと解析が完了するまで待ち、YAMLの構文エラー、認証エラー、リクエストのタイムアウトが表示されていないことを確認します。
追加した設定を選択し、現在の有効な設定にします。リストに表示されているだけでは、コアがその設定に切り替わったとは限りません。
「プロキシ」画面を開き、設定から読み込まれたプロキシグループとノードを確認します。実際に通信で使われる選択グループ内で、利用可能なノードを選択してください。
ローカルファイルを使う場合は、設定のインポート画面からYAMLファイルを選択します。ノード一覧だけでプロキシグループやルールを含まないファイルは、そのままでは完全な実行設定として使えない場合があります。

サブスクリプションを追加したら、まずはルールモード（設定項目は mode: rule）を使います。ルールモードでは、rulesの記述順に接続を照合し、指定されたプロキシグループまたはアウトバウンドに振り分けます。グローバルモードでは選択したGLOBALのアウトバウンドが使われますが、ルールやプロキシグループの確認に代わるものではありません。

サブスクリプションを追加できないときの確認ポイント

HTTP 401または403：まずサブスクリプションの有効期限、アクセストークンが再発行されていないか、サーバー側でクライアントの種類が制限されていないかを確認します。認証エラーへの対処としてDNSを何度も切り替える必要はありません。
HTMLが返る、またはYAMLの解析に失敗する：URLがログイン画面やエラーページを指しているか、別のクライアント向けの形式を返している可能性があります。Clash/mihomo対応の設定を取得してください。
リクエストがタイムアウトする：現在のネットワークからサブスクリプションのサーバーにアクセスできるか確認します。以前使っていたプロキシがシステム設定に残っている場合は、旧クライアントを終了してから再度試してください。
ノードは表示されるのにWebサイトに接続できない：実際に適用されているプロキシグループを確認します。速度テストの成功は、テスト先に接続できたことを示すだけで、すべてのWebサイト、プロトコル、出口が使えるとは限りません。

システムプロキシ：まずブラウザーのHTTP通信を確認

クライアントで「システムプロキシ」を有効にし、TUNはオフのままにして、原因を絞り込みます。システムプロキシはWindowsのプロキシ設定を変更し、その設定に従うブラウザーやアプリに適用されます。デバイス全体の通信を中継する機能ではありません。一部のゲーム、コマンドラインツール、独自のネットワーク処理を行うプログラムは、この設定を使わない場合があります。

Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシのアドレスとポートを確認します。アドレスは通常127.0.0.1ですが、ポートはクライアントで現在有効な設定に従ってください。以下では7890を例にします。すべての環境でこのポートが使われるわけではありません。

確認項目	例・期待される状態	注意点
混合ポート	`mixed-port: 7890`	同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。
Windowsのプロキシサーバー	`127.0.0.1:7890`	実際に待ち受けているポートと一致させます。
現在の動作モード	`mode: rule`	接続ログとあわせて、適用されたルールを確認します。
LANからのアクセス	`allow-lan: false`	このPCだけで使う場合は、LAN共有を有効にする必要はありません。

プロキシを明示したリクエストで、アプリとコアの問題を切り分ける

PowerShellで以下のコマンドを実行します。HTTPプロキシを明示するため、アプリがWindowsのプロキシ設定を読み取るかどうかに左右されません。ポートはクライアントに表示されている値に置き換えてください。テスト用ドメインはHTTPSリクエストを1回送るためのもので、特定のWebサイトにあらゆるネットワークから接続できることを示すものではありません。

Test-NetConnection 127.0.0.1 -Port 7890
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

TcpTestSucceeded: Trueで確認できるのは、ローカルのポートにTCP接続できることだけです。HTTPSリクエストでレスポンスヘッダーが返れば、このリクエストでプロキシのネゴシエーションと後続の接続が完了したと判断できます。明示したプロキシ経由では成功し、特定のアプリで失敗する場合は、クライアントをすぐ再インストールするのではなく、まずそのアプリのプロキシ設定を確認してください。

クライアントの接続ログも開き、リクエスト先のドメイン、適用ルール、プロキシグループ、最終的なノードを確認します。リクエストがDIRECTに一致している場合は、ルールが想定どおりかを確認してください。プロキシグループで使えないノードが選択されている場合、システムプロキシのアドレスを変更しても解決しません。

TUNとサービスモード：基本の通信を確認してから有効にする

TUNモードは仮想ネットワークインターフェースとルートを使い、システムプロキシに従わないアプリの通信も取り込みます。サービスモードは、特権が必要なコアの処理をバックグラウンドサービス経由で実行するためのものです。サービスがインストール済みでもTUNが有効とは限らず、TUNを有効にしてもルートやDNSが正しく設定されたとは限りません。

まず前の節の手順でシステムプロキシを使い、サブスクリプション、ノード、コアが動作することを確認します。
「設定」を開いて「サービスモード」を探し、画面に表示されるインストールまたは管理の操作からサービスをインストールします。Windowsユーザーアカウント制御の確認画面が表示されたら、プログラムの提供元を確認してから許可してください。
サービスが正常に動作していることを確認してから、「TUNモード」を有効にします。コアの再起動を求められた場合は、再起動が完了してから動作を確認してください。
TUNを個別に検証するには、一時的にシステムプロキシをオフにします。以前からシステムプロキシを使わずにいたアプリでリクエストを送り、クライアントの接続ログを確認してください。
通常のWebページ、ドメイン名の名前解決、社内ネットワークへのアクセスを確認します。TUNでインターネットに接続できても、社内ネットワーク、プリンター、ほかのVPNとのルート競合がないとは限りません。

TUNの設定項目を理解する

以下はmihomoの設定例であり、完全なサブスクリプションではありません。クライアントがこれらの項目を自動生成または上書きする場合があります。最終的に適用される設定を確認してから、クライアントが対応するオーバーライドまたはマージ機能で変更してください。リモートサブスクリプションの内容を直接編集すると、次回の更新で上書きされる可能性があります。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

auto-routeは関連するルートを自動設定します。ルートが正しく設定されていない場合、アプリの通信がTUNを通らないことがあります。
auto-detect-interfaceはアウトバウンドに使うインターフェースを自動検出します。複数のネットワークアダプター、仮想マシン、ほかのVPNを併用している場合は、ログで実際の出口を確認してください。
dns-hijackのany:53は、該当する従来型DNSリクエストを取り込む設定であり、暗号化DNSをすべて取り込むものではありません。ブラウザーが独自に送信するDoHは、別のHTTPS接続です。
fake-ipは該当するリクエストに対応するアドレスを返し、コアがそのアドレスとドメイン名を関連付けます。上流のDNSサーバーはDNS設定全体で正しく指定する必要があります。この数行をコピーしただけでDNS設定が完了したと判断しないでください。

よくあるエラー：ポート、権限、ルートの順に確認

ポート競合：「address already in use」

ログにbind、address already in useなど待ち受けに失敗したメッセージが出た場合は、まずそのポートを使用しているプロセスを調べます。以下はPowerShell用のコマンドです。ポートが7890以外の場合は、該当箇所を置き換えてください。

Get-NetTCPConnection -State Listen -LocalPort 7890 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Id 4321

2つ目のコマンドにある4321は例示用のPIDです。1つ目のコマンドが返したOwningProcessの値に置き換えてください。プロセスが以前使っていたプロキシクライアントのものなら、まずそのクライアントを通常の手順で終了します。ポートを解放できない場合は、現在のクライアントの混合ポートを7897など別の空きポートに変更し、コアを再起動してWindowsのプロキシポートも合わせて確認してください。所有者を確認せずにシステムプロセスを強制終了しないでください。

サービスのインストールに失敗する：アクセス拒否、またはサービスが起動しない

「サービスのインストール失敗」と「インストール済みサービスの起動失敗」を区別します。前者は権限やデバイスのポリシー、後者はインストール先のパスが無効になった、コンポーネントが隔離された、古いサービスが残っているなどの原因が考えられます。エラーメッセージ全体を記録し、以下の順に確認してください。

クライアントのサービスインストール画面から管理者権限の確認を再度求め、ユーザーアカウント制御の確認をキャンセルしていないか確認します。
Win + Rを押してservices.mscと入力します。クライアントに表示されているサービス名を使って状態と実行ファイルのパスを確認してください。サービス名を推測して削除しないでください。
Windowsセキュリティの「保護の履歴」と、「イベントビューアー」→「Windowsログ」→「システム」に記録された該当時刻のイベントを確認します。
アップグレード後にパスが無効になった場合は、まずクライアントにあるサービスのアンインストール機能と再インストール機能を使い、その後クライアントを再起動してください。

ファイアウォールやセキュリティ機能を長期間無効にする方法はおすすめしません。組織のポリシーで制限されている場合、サービスのインストールは管理者による対応が必要なことがあります。その場合は、動作確認済みのシステムプロキシ設定をひとまず使ってください。

TUNを有効にするとネットに接続できない、または社内ネットワークにつながらない

まずTUNをオフにし、通常のネットワークが復旧するか確認します。復旧したらシステムプロキシを再テストしてください。システムプロキシが正常なら、ノードや基本的なアウトバウンドよりも、仮想インターフェース、ルート、DNSに原因がある可能性が高いです。デフォルトルートを複数のプログラムが同時に制御しないよう、ほかのVPNを終了してから試してください。

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object RouteMetric |
  Select-Object -First 20 DestinationPrefix, InterfaceAlias, NextHop, RouteMetric

以下のコマンドは状態を確認するだけで、ネットワーク設定は変更しません。有効化前後のインターフェースとルートの違いを記録してください。社内ネットワークだけにアクセスできない場合は、社内ネットワークのアドレス範囲、アクセスルール、ルートの除外設定を確認します。ルールにDIRECTを追加するだけでは、宛先アドレスが誤ったルートに振り分けられている問題を解決できないことがあります。元の状態に戻すときは、まずTUNをオフにしてください。システムルートを一括削除しないでください。

クライアント終了後もインターネットに接続できない

まずWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」を確認します。手動プロキシが、待ち受けを停止した127.0.0.1のポートを指している場合は、手動プロキシをオフにしてから再度接続してください。通常の終了時は、クライアントのシステムプロキシを先にオフにしてからクライアントを終了すると、プロキシ設定が残るのを防ぎやすくなります。

まだ問題が続く場合は、バックグラウンドサービスが動作中か、TUNのルートが解除されているかも確認します。ウィンドウを閉じて通知領域に最小化する操作と、完全に終了する操作は異なります。ウィンドウが消えただけでコアも停止したと判断しないでください。

インストール後の確認：再現できるテスト手順を残す

設定後、すべてのスイッチを有効にする必要はありません。主にブラウザーで使うなら、まずはシステムプロキシだけを有効にします。ほかのアプリの通信も取り込む必要がある場合に、動作確認済みのTUN設定を使ってください。ルールモード、システムプロキシ、TUNはそれぞれ異なる層を制御するため、1つのスイッチの状態からほかの設定も正しいと判断することはできません。

設定：現在のサブスクリプションが有効で、プロキシ画面に使えるプロキシグループがあり、更新後も正常に読み込める。
ポート：クライアントが実際に待ち受けているポートとWindowsのプロキシ設定が一致し、プロキシを明示したリクエストで応答が返る。
ルール：直接接続とプロキシ接続の両方について、接続ログでアウトバウンドの選択が設定どおりかを少なくとも1回確認する。
TUN：システムプロキシをオフにしても、対象のアプリがTUN経由で接続ログに記録され、社内ネットワークにもアクセスできる。
再起動：Windowsを再起動した後、サービス、設定、プロキシの状態を改めて確認する。「スタートアップ時に起動する」ことと「通信が正しく取り込まれている」ことは別です。
元に戻す：システムプロキシとTUNをオフにして通常のネットワークに戻せる。復元に備えて、変更前のオーバーライド設定を保管する。

トラブルを報告する際は、Windowsのシステムの種類、クライアントのバージョン、コアのバージョン、動作モード、待ち受けポート、同じ時間帯のエラーログを記載してください。サブスクリプションのトークン、ノードの認証情報、個人のアクセス履歴は削除します。プロキシを明示したテストが成功したか、そのうえでTUNが失敗したかを説明すると、「Clashがつながらない」とだけ伝えるより原因を特定しやすくなります。設定項目の意味を確認するには、マニュアル全文をご覧ください。