Windows版Clash Verge Revのインストール方法｜ファイアウォール・TUN・システムプロキシのトラブル対策

インストール前に確認すること：システムの種類と設定の入手元

WindowsにClash Verge Revをインストールしたら、「クライアントの起動 → サブスクリプションの追加 → システムプロキシの確認 → サービスモード → TUN」の順に設定するのがおすすめです。最初からすべての機能を有効にせず、まずプロキシ接続が正常に使える状態にします。その後、システムプロキシに対応していないアプリの設定に進めば、問題の切り分けが簡単になります。

Clash Verge Revはデスクトップ向けの管理画面です。通信処理やルール適用を担うのはmihomoコアで、Clash Metaとも呼ばれます。インストールが完了しても、利用可能なノードがあるとは限りません。コアに対応した設定ファイル、またはサービス提供元から発行されたClash形式のサブスクリプションが別途必要です。

CPUアーキテクチャに合ったインストーラーを選ぶ

Win + IキーでWindowsの設定を開き、「システム」→「システム情報」の順に進んで「システムの種類」を確認します。Windowsのバージョンによっては、このページが「バージョン情報」と表示されます。
一般的なIntel・AMD搭載の64ビットPCにはWindows x64版を選びます。ARMプロセッサ搭載デバイスには、リリースページにあるARM64版を選択してください。
使用中のWindowsのバージョンが、選択したリリースの対応対象であることを確認してください。ファイル名にWindowsとあるだけで古いOSにも対応すると判断したり、x64版を32ビットOSにインストールしたりしないでください。
インストーラーを起動し、ウィザードの案内に従ってインストールします。旧バージョンがある場合は、システムプロキシの設定が競合しないよう、先に終了してください。

初回起動時のファイアウォール警告への対応

コアの初回起動時に、Windowsからアプリのファイアウォール通信を許可するか尋ねられることがあります。対象はクライアントの場合も、実際にポートを待ち受けるコアのプログラムの場合もあります。許可するネットワークを決める前に、プログラムのパスがインストール先にあることを確認してください。名前が似ているだけでは、正しいプログラムとは判断できません。

ローカル端末での利用と、LAN内での共有は別の設定

このPCだけで使う場合：「LAN接続を許可」はオフのままにし、プロキシの待ち受け先はループバックアドレスを優先してください。通常、PC内のループバック接続のためにLANへ受信ポートを公開する必要はありません。
スマートフォンや別のPCと共有する場合：LANからのアクセスを明示的に有効にし、信頼できるプライベートネットワークに対して受信ルールを設定します。パブリックネットワークまで安易に許可しないでください。
組織によって管理されている端末の場合：管理者ポリシーにより、コアの通信、サービスのインストール、仮想ネットワークアダプターの作成が制限されていることがあります。ファイアウォール全体を無効にするのではなく、管理者に確認してください。

誤って「キャンセル」した場合は、「Windows セキュリティ」→「ファイアウォールとネットワーク保護」→「ファイアウォールによるアプリケーションの許可」で設定を確認できます。プログラムのパス、ポート、接続先アドレスごとに範囲を指定するには、スタートメニューで「セキュリティが強化された Windows Defender ファイアウォール」を検索し、該当ルールの適用範囲を確認してください。アプリの許可リストは主に受信アクセスに関する設定です。チェックが入っているだけで、送信接続も必ず許可されているとは限りません。

アップデートでインストール先やコアのパスが変わると、以前のルールが適用されなくなることがあります。問題が確認できたルールだけを修正し、接続障害の切り分けのためにすべてのネットワークプロファイルでファイアウォールを無効にしないでください。

サブスクリプションを追加し、まずシステムプロキシで接続を確認する

クライアントの「サブスクリプション」ページを開き、新規作成またはインポートからサブスクリプションURLを入力して設定をダウンロードし、対象の設定を選択します。ボタンの名称はバージョンによって異なる場合があります。
プロキシグループにノードが表示されることを確認します。利用できることが分かっているノードを選択し、クライアントが「全て直結」ではなくルールモードになっていることも確認してください。
「設定」のClash設定で混合ポートを確認し、システムプロキシを有効にします。以下の例では混合ポートを7897としています。実際にはクライアントに表示されているポートを使用してください。
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシが127.0.0.1と先ほど確認したポートを指しているか確認します。
ブラウザーで接続先のサイトを開き、クライアントの「接続」または「ログ」ページで、どのルール、プロキシグループ、ノードが使われたかを確認します。

ノードの遅延テストに成功しても、その時点でテスト先に到達できたことが分かるだけです。すべてのサイト、UDP通信、DNSリクエストが正常とは限りません。ノード一覧が空の場合は、TUNドライバーを調べる前に、サブスクリプションの形式、ダウンロードエラー、設定ファイルの解析エラーを確認してください。

明示的なプロキシ接続で問題箇所を切り分ける

PowerShellを開き、以下の2つのコマンドを実行します。1つ目でローカルポートを確認し、2つ目でHTTPプロキシを明示してテストサイトにアクセスします。ここではcurl.exeを使います。旧バージョンのWindows PowerShellでcurlが別のコマンドとして解釈されるのを避けるためです。

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

TcpTestSucceeded : False：コアが起動しているか、ポートが変更されていないか、ほかのプログラムがポートを使用していないかを確認してください。
ローカルプロキシには接続できるものの、ハンドシェイクに失敗する、またはタイムアウトする場合：ログを確認し、ノード、接続先サイト、DNS、TLSのエラーを調べます。
明示的なプロキシ接続でHTTPレスポンスを取得できるのにブラウザーでは失敗する場合：ブラウザーのプロキシ設定、拡張機能、システムプロキシの反映状態、プロキシ除外リストを確認します。

テストサイトから403や405などのHTTPステータスが返る場合も、サーバーからレスポンスを受信できたことを示す場合があります。ただし、目的のサービスに正常にアクセスできたとは限りません。クライアントの接続履歴も確認し、リクエストが想定したプロキシルールを通ったか、ルールによって直結になっていないかを確かめてください。

サービスモードとTUN：順番にインストール・有効化・確認する

システムプロキシは、Windowsのプロキシ設定を参照するアプリで利用できます。一部のコマンドラインツール、ゲーム、独自のネットワーク処理を行うソフトはシステムプロキシを参照しません。TUNは仮想ネットワークインターフェースとルーティングを使って通信を処理するため、より広い範囲をカバーできますが、ルート、DNS、権限に関する要因も増えます。

まずサービスモードを動作させる

クライアントの「設定」から「サービスモード」の項目を開いてインストールします。Windowsユーザーアカウント制御のダイアログに表示されるプログラムの発行元を確認してから許可してください。
インストール後、クライアントにサービスが実行中と表示されることを確認します。未インストールや起動失敗の表示が続く場合は、インストールを繰り返す前にクライアントのログを確認してください。
動作を確認済みの設定とノードを維持したまま、TUNモードを有効にします。インターフェースの作成失敗、権限不足、ルート設定失敗などがログに記録されていないか確認してください。
Win + Rキーを押してncpa.cplを実行し、「ネットワーク接続」に仮想インターフェースが表示されるか確認します。以下のPowerShellコマンドを使って、非表示のインターフェースを確認することもできます。

Get-NetAdapter -IncludeHidden |
  Select-Object Name, InterfaceDescription, Status

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

インターフェース名はコアや設定によって異なり、Clashという名前が必ず含まれるわけではありません。仮想ネットワークアダプターが見えても、通信が必ずそこを通るとは限りません。ルートとクライアントの接続履歴も確認してください。TUNを有効にしても、元のデフォルトルートが必ず削除されるわけではありません。コアがより具体的なルートを追加して通信を処理する場合があります。

TUNドライバーのエラーが出ても、出所不明のファイルをダウンロードしない

WindowsでTUNインターフェースを作成するには、対応するドライバーと十分な権限が必要です。実装方法は使用するコアとクライアントの配布パッケージによって異なります。通常はクライアントに用意されたインストール、修復、更新機能を使います。ログにドライバーコンポーネントの不足が明記されている場合は、まずセキュリティソフトの隔離履歴とインストール状態を確認し、信頼できる配布元のファイルを使って修復してください。

サービスモードは関連コンポーネントをサービスとして実行するためのもので、サブスクリプションの互換性を自動で解決したり、使えなくなったノードを修復したりする機能ではありません。システムプロキシのテストがすでに失敗している場合は、設定とノードの問題から確認してください。TUNを有効にしただけで、同じノードの障害が解消されるわけではありません。

システムプロキシを有効にしても効かない場合：症状から原因を特定する

「スイッチがオン」という状態は、クライアントがプロキシを設定しようとしたことを示すだけで、対象のアプリがその設定を参照しているとは限りません。まずリクエストがクライアントに届いているか確認し、その結果に応じてアプリ、ルール、ノードを調べます。何度も再インストールするより、以下の順に確認するほうが効率的です。

症状	まず確認する項目	次の対応
すべてのブラウザーで失敗し、ローカルポートのテストも失敗する	コアの実行状態、ポート、待ち受けプロセス	混合ポートを確認し、コアの起動ログを調べます。
明示的なプロキシ接続は成功するが、特定のブラウザーだけ失敗する	プロキシ拡張機能、ブラウザー独自のプロキシ設定、プロキシ除外リスト	一時的にプロキシ拡張機能を無効にし、ブラウザーのネットワーク設定を確認します。
ブラウザーは正常だが、ターミナルやゲームがプロキシを通らない	アプリがシステムプロキシに対応しているか	アプリ内のプロキシ設定や一時的なプロキシ環境変数を使うか、TUNで動作を確認します。
リクエストはクライアントに届くが、DIRECTと表示される	ルールの優先順位、プロキシグループの選択、動作モード	適用されたルールを確認し、該当するルールまたはプロキシ設定を調整します。
TUNを有効にしたときだけインターネットに接続できない	DNS、ルート、ほかのVPN、サービスの権限	TUNをオフにして通常の接続状態に戻し、項目ごとに確認します。

ポートの競合：PIDを確認し、プロセス名だけで終了しない

ログにアドレスが使用中と表示された場合は、PowerShellでポートの待ち受けプロセスを確認できます。以下では7897を例にしています。取得したプロセスIDをタスクマネージャーで確認し、プログラムのパスを調べてください。複数のプロキシクライアントを同時に起動していることはよくある原因ですが、正体の分からないプロセスを強制終了しないでください。

Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

ターミナルがシステムプロキシを引き継がない場合：一時環境変数で確認する

以下の環境変数に対応するコマンドラインツールでは、現在のPowerShellウィンドウだけにプロキシを設定できます。すべてのプログラムが環境変数に対応するわけではありません。また、動作確認前にシステム全体の環境変数として登録しないでください。

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

# テスト後に現在のウィンドウの環境変数を削除する
Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue
Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue

HTTPS_PROXYの値にhttp://を使っても、接続先サイトがHTTPに切り替わるわけではありません。これはクライアントからローカルのHTTPプロキシへの接続方式を表しており、HTTPSの接続先には通常CONNECTトンネルを使います。SOCKSプロキシしか受け付けないアプリでは、説明書に従って設定してください。HTTPの設定をそのまま流用しないでください。

TUNを有効にするとネットに接続できない場合：DNSとほかの仮想ネットワークを確認する

まずTUNをオフにし、システムプロキシは有効のまま同じ接続テストを行います。すぐに復旧するなら、サブスクリプション全体ではなくTUNの通信経路に問題がある可能性が高いでしょう。切り替え前後のログの時刻を記録し、複数のVPN、ほかのプロキシソフト、仮想マシンのネットワーク、企業向けセキュリティソフトが動作していないか確認してください。

DNSキャッシュと名前解決の経路を切り分ける

DNS設定を変更した後は、ipconfig /flushdnsを実行してWindowsのDNSキャッシュを消去し、テストするアプリを再起動してください。ブラウザーが独自のキャッシュや接続を保持している場合もあります。
ブラウザーのセキュアDNSやアプリ内蔵のDoHは、システムのDNS経路を使わないことがあります。調査時は元の設定を記録してから、条件をそろえて比較してください。複数のDNS設定を一度に変更しないでください。
fake-ipを有効にすると、一部のドメインが198.18.0.0/16の範囲のアドレスとして表示されることがあります。これは一般的なアドレスの割り当て方式です。この表示だけでDNS汚染と判断したり、そのアドレスを実際のサーバーアドレスとして設定したりしないでください。
社内ドメインやLAN内のデバイスには、専用のDNSルールや除外設定が必要な場合があります。インターネット上のサイトにアクセスできても、社内ネットワークの名前解決が正常とは限りません。

設定でDNSのリダイレクトを有効にしている場合は、実際の対象範囲とコアのログを確認してください。従来の53番ポートを使うDNSと、HTTPS経由で送信するDNSリクエストは別の通信です。53番ポートをリダイレクトするルールを1つ設定しただけで、すべてのアプリの名前解決を処理できるとは限りません。

ほかのVPNや仮想マシンのネットワークとの競合を解消する

仮想ネットワークアダプターをまとめて削除しないでください。まず、現在使っていないVPNやほかのプロキシクライアントを終了してからTUNを再度有効にし、動作を確認します。企業VPNを同時に使う必要がある場合は、管理者にルートの優先順位、社内ネットワークの範囲、DNSの振り分け方法を確認してください。ルートメトリックをむやみに下げると、本来社内に向かう接続が誤った経路に流れるおそれがあります。

終了方法、自動起動、日常のメンテナンス

インストール後、正常に終了できることを確認します。TUNとシステムプロキシをオフにしてからクライアントを終了し、通常のネットワーク接続が使えるかテストしてください。クライアントが異常終了した後にブラウザーが接続できなくなった場合は、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、ローカルポートを指す手動プロキシが残っていないか確認します。ほかのプログラムが使っていないことを確かめてから無効にしてください。

自動起動の設定は最後に行います。まず再起動後にサブスクリプションの読み込み、コアの実行、プロキシの状態を確認してください。GUIアプリの自動起動とサービスの起動は別の仕組みです。
アップデート後は重要な設定を確認します。コアのバージョン、混合ポート、サービスモード、TUNの状態を確認してください。設定項目に変更がある場合は、使用中のコアのドキュメントとエラーログを参照してください。
継続的な設定変更にはオーバーライド機能を使います。サブスクリプションからダウンロードしたファイルを直接編集すると、次回の更新時に変更が上書きされることがあります。
問い合わせには必要最小限の情報を添えます。Windowsのバージョン、クライアントとコアのバージョン、再現手順、個人情報を伏せたログを記録してください。サブスクリプションの認証情報、ノードのパスワード、管理APIのキーは必ず伏せてください。

トラブルシューティングでは、動作確認済みの経路を1つ保つことが重要です。まずローカルポートに接続できること、明示的なプロキシでレスポンスが返ること、想定どおりのルールが適用されることを確認し、その後にシステムプロキシやTUNへと範囲を広げます。各段階で結果を確認すれば、何度も再インストールして運任せにする必要はありません。