Windows版Clash Verge Revの導入・設定ガイド｜システムプロキシ、TUN、ファイアウォール対策

まずシステムプロキシを確認し、その後TUNを有効にする

WindowsでClash Verge Revを初めて設定する場合は、「クライアントのインストール → 設定のインポート → プロキシグループの選択 → システムプロキシの確認 → サービスのインストール → TUNの有効化」の順に進めるのがおすすめです。最初からDNS、ルーティング、ファイアウォールを同時に変更するのは避けましょう。一度に一つずつ変更すれば、問題の発生箇所を特定しやすくなります。

Clash Verge Revは設定管理、システムプロキシ、画面操作を担当し、mihomoコアは設定の読み込み、ルール判定、プロキシ接続を処理します。サブスクリプションにはノードやルールなどの設定情報が含まれます。クライアントをインストールできても、サブスクリプションが使えるとは限りません。また、ノードの遅延が表示されても、すべてのアプリがプロキシ経由になるわけではありません。

インストーラーの選び方：CPUのメーカーではなくシステムのアーキテクチャを確認

Windowsの「設定」→「システム」→「バージョン情報」を開き、「システムの種類」を確認します。Windows 10では、このページは通常「詳細情報」と表示されます。
「x64 ベースプロセッサ」と表示される場合は、x64版インストーラーを選びます。AMD64はx64アーキテクチャの名称で、Intel製のx64プロセッサにも対応します。
「ARM ベースプロセッサ」と表示される場合は、プロジェクトが提供するARM64版インストーラーを選んでください。デバイスのブランドだけでアーキテクチャを判断しないようにしましょう。
クライアントのダウンロードページで対応プラットフォームを確認します。インストール前に旧クライアントを通常の手順で終了し、複数のコアが同じポートを奪い合わないようにしてください。

初回起動と実行環境

インストーラーの案内に従ってインストールし、まずは通常のユーザー権限でクライアントを起動します。WebView2ランタイムが見つからないという明確なエラーが表示された場合は、インストーラーの案内に従うか、Microsoftの公式チャネルからランタイムを導入してください。画面が真っ白になる原因は、グラフィック描画やセキュリティソフトのブロックの可能性もあります。画面が白いだけでサブスクリプションが無効だと判断しないでください。

Windowsにアプリの入手元や発行元に関する警告が表示された場合は、ダウンロード元とインストーラーの情報を確認してください。インストールの前提として、Windowsの保護機能を無効にする必要はありません。インストール後はクライアントの「設定」で、クライアントとコアのバージョンを記録しておきましょう。問題を報告する際は、「最新版」とだけ書くより、この2つの情報を添える方が役立ちます。

サブスクリプションをインポートしてルールモードを確認

クライアントの「サブスクリプション」ページにURLを貼り付けてインポートするか、ローカルのYAMLファイルを読み込みます。インポート後は、その設定を選択して現在の設定として適用してください。リストに設定名が表示されていても、コアへの切り替えが完了したとは限りません。

更新結果と実行ログを確認し、YAMLの解析エラー、フィールドの型エラー、ノードの読み込み失敗がないか確認します。
「プロキシ」ページを開き、まずはルールモードを使います。よく使うプロキシグループで選択されているノードを確認し、誤ってDIRECTやREJECTを選んでいないか確認してください。
候補のノードで遅延テストを実行します。タイムアウトした場合はノードとネットワークをさらに調べ、すぐにWindowsファイアウォールが原因だと決めつけないでください。
プロキシを使うはずのサイトやアプリにアクセスし、「接続」ページで適用されたルールとプロキシ経路を確認します。

ルールモードではrulesの順にルールを評価します。グローバルモードではGLOBALポリシーを使い、直接接続モードではノードを選んでも自動的にそのノード経由にはなりません。切り分けのために一時的にグローバルモードへ切り替えて比較することはできますが、確認後は本来のモードに戻し、適用されるルールを確認してください。

システムプロキシが効かない場合：ポートとリクエスト経路を確認

システムプロキシは、Windowsのプロキシ設定に従うブラウザーなどの動作確認に適しています。ただし、全システムの通信を制御する機能ではありません。一部のゲーム、コマンドラインツール、独自のネットワーク設定を持つソフトは自動的に利用せず、通常のHTTPシステムプロキシですべてのUDP通信を処理することもできません。

127.0.0.1と実際の混合ポートを確認

まずクライアントの設定画面で混合ポートを確認し、その後「システムプロキシ」を有効にします。以下では診断例として7897を使います。クライアントに7890など別のポートが表示されている場合は、コマンド内の数値を実際の値に置き換えてください。例に合わせるためだけにポートを変更しないでください。

# PowerShellでローカルの待ち受けポートを確認
Test-NetConnection 127.0.0.1 -Port 7897

# 現在のユーザーのWindowsプロキシ設定を確認
Get-ItemProperty 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings' |
  Select-Object ProxyEnable, ProxyServer, AutoConfigURL

# 待ち受けプロセスを確認。出力の最後の列がPID
netstat -ano | findstr LISTENING | findstr :7897

TcpTestSucceeded : Trueは、ローカルポートに接続できることを示すだけで、リモートノードが利用できるとは限りません。結果がFalseの場合は、まずコアが動作しているか、設定が読み込まれているか、ポートが別のプログラムに使用されていないかを確認します。タスクマネージャーの「詳細」タブでPIDからプロセスを特定できます。不明なシステムプロセスを終了しないでください。

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

# HTTPプロキシを明示して、アプリがシステム設定を参照するかどうかの違いを除外
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

ここではcurl.exeを使い、一部のPowerShell環境でcurlが別のコマンドとして解釈されるのを防ぎます。このリクエストもコアのルールモードに従うため、「接続」ページで対象が実際にプロキシ経由になっているか、直接接続になっていないかを確認してください。HTTPレスポンスが返っても、このリクエストに応答があったことを示すだけで、すべてのサイトにアクセスできるとは限りません。

明示的なプロキシ接続は成功するが、ブラウザーは失敗する：ブラウザーの拡張機能や独自のプロキシ設定を確認し、Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」の設定が他のソフトによって変更されていないか確認してください。
明示的なプロキシ接続は失敗するが、ローカルポートには接続できる：プロキシグループ、ノード認証、リモート接続、コアのログを確認してください。システムプロキシのスイッチを何度も切り替えるのは避けましょう。
ブラウザーは使えるが、特定のアプリは失敗する：そのアプリがシステムプロキシに従うか確認してください。必要に応じてアプリ内でプロキシを設定するか、TUNを試してください。

netsh winhttp show proxyで表示されるのはWinHTTPのプロキシ状態であり、現在のユーザーのブラウザーが使うWindowsプロキシ設定とは異なります。「直接アクセス」と表示されても、それだけでClash Verge Revのシステムプロキシが機能していないとは判断できません。この結果だけを見て、システム全体のWinHTTP設定をむやみに変更しないでください。

TUNサービスのインストール：まずサービス、次にルーティングを確認

TUNは仮想ネットワークインターフェイスとルーティングを使って通信を取り込むため、システムプロキシに従わないアプリにも適しています。対応する権限が必要で、他のVPN、仮想ネットワークアダプター、企業ネットワークのポリシーと競合しやすくなります。TUNはノードの問題を修復する機能ではありません。システムプロキシで使えないノードは、通常TUNを有効にしても使えるようにはなりません。

ほかのプロキシクライアントやサードパーティ製VPNを終了し、通常の直接接続でネットワークが使えるか記録します。
Clash Verge Revの「設定」を開き、「サービスモード」とそのインストールまたは管理項目を探します。画面の案内に従ってサービスをインストールし、Windowsのユーザーアカウント制御の許可を確認してください。
画面にサービスが利用可能と表示されてから、「仮想ネットワークアダプター」または「TUNモード」を有効にします。サービスの状態に問題がある場合は、まずインストールエラーを解決してください。TUNを何度も切り替えるのは避けましょう。
問題の切り分けのため、システムプロキシを一時的に無効にしてTUNだけを使います。対象のアプリを開き、「接続」と「ログ」に該当する通信が表示されるか確認します。

TUN関連フィールドの見方

以下はmihomoでよく使われるTUNフィールドの設定例です。ノード、プロキシグループ、ルールを含む完全な設定ではありません。Clash Verge Revは実行時にこれらのフィールドを上書きして生成する場合があるため、クライアントの設定画面を優先し、最終的に適用された設定を確認してください。tunキーが重複しないよう、設定全体をサブスクリプションの末尾にそのまま追加しないでください。

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

auto-routeはルートを自動設定する項目です。有効にした後も、通信が実際にコアへ届いているか確認してください。
auto-detect-interfaceは送信に使うネットワークインターフェイスを自動検出する項目です。複数のネットワークアダプター、テザリング、VPNを併用している場合は、ログで検出結果を確認してください。
dns-hijackのany:53は、該当する従来型のDNSリクエストを横取りする設定です。HTTPSで暗号化されたDNSリクエストをすべて通常のDNSに自動変換するものではありません。
stackの対応状況や動作は、コアとプラットフォームによって異なります。ログで根拠を確認せずに、ネットワークスタックを何度も切り替えないでください。

TUNを有効にした直後に全体のネットワークが切れた場合は、まずTUNを無効にして接続を復旧し、送信インターフェイス、DNS設定、他のVPNのルートを確認します。スリープからの復帰後や、有線LANからWi-Fiに切り替えた後に問題が起きた場合も、いきなりOSを再インストールせず、まずインターフェイスとサービスの状態を確認してください。

UWPアプリがネットに接続できない場合：ループバック制限とプロキシ経路を切り分ける

Microsoft Storeなど、アプリコンテナーのネットワークモデルを使用するプログラムは、ローカルのループバック接続が制限される場合があります。127.0.0.1:7897のローカルプロキシを使おうとしている場合、通常のブラウザーが使えても接続に失敗することがあります。Microsoft Storeからインストールしたアプリがすべて同じネットワークモデルとは限らないため、一律にUWPとして扱わないでください。

2つの切り分け方法

システムプロキシを使い続ける：使用中のバージョンにUWPのループバック解除ツールがある場合は、必要なアプリだけに許可します。該当する項目がない場合は、Windows標準のツールで確認してください。入手元が不明な一括変更スクリプトはダウンロードしないでください。
TUNで通信を取り込む：システムプロキシを無効にして個別にテストし、アプリの通信がコアに届いているか確認します。TUNで通信経路は変えられますが、アプリの認証、DNS、サーバー側のエラー確認に代わるものではありません。

# 管理者権限のターミナルで、既存のアプリコンテナーのループバック解除設定を確認
CheckNetIsolation.exe LoopbackExempt -s

このコマンドは既存の解除設定を一覧表示するだけで、すべてのアプリの制限を自動解除するものではありません。新たに追加する場合は、まずGet-AppxPackageで対象アプリのパッケージファミリ名を確認し、ツールのヘルプに従って対象を指定してください。影響を受けているアプリだけを処理し、「すべて解除」を一般的な最適化として使わないでください。

TUNを使っても失敗する場合は、クライアントに対象アプリの通信が表示されるか確認します。通信がまったく表示されない場合は、まず通信の取り込み経路を調べてください。通信が表示され、認証エラーや地域制限のエラーが返る場合は、アカウント、接続元、サービス側の要件を確認します。ループバック制限だけを原因と決めつけないでください。

ファイアウォールの確認：保護機能は維持し、必要なルールだけ変更

通常のローカルプロキシは127.0.0.1で待ち受けるため、インターネット接続のために混合ポートをLAN全体へ公開する必要はありません。他の端末からこのPCのプロキシに接続する必要がある場合に限り、「LAN内の接続を許可」、待ち受けアドレス、受信ルールを検討し、接続元ネットワークを制限してください。

症状	まず確認する項目	対処方法
ローカルポートに接続できない	コアの状態、ポートの競合	まず待ち受けを復旧し、ファイアウォールルールの追加は後回しにする
ローカルでは待ち受けているが、リモート接続がタイムアウトする	ノード、送信方向のブロック、セキュリティソフトの記録	ログと別のノードを比較して原因を特定する
アップデート後にブロックされる	ルールに関連付けられたプログラムのパス	現在のコアの保存場所を確認し、無効になったルールを修正する
他の端末からこのPCのプロキシに接続できない	待ち受けアドレス、LAN接続の設定、受信元の範囲	共有が必要な場合に限り、必要なアクセスだけ許可する

Win + Rを押し、wf.mscと入力して「セキュリティが強化された Windows Defender ファイアウォール」を開きます。まず「送信の規則」に、現在のクライアントまたはコアを対象としたブロックルールがないか確認し、次にセキュリティソフトのブロック記録を確認してください。Windowsの既定設定では一般に送信接続が許可されますが、組織管理のPCでは異なるポリシーが適用される場合があります。管理者に相談してください。

「このアプリにファイアウォール経由の通信を許可しますか」と表示されても、すべてのネットワークの種類に機械的にチェックを入れないでください。用途に応じて許可します。PC上でプロキシを使うことと、公衆Wi-Fiで他の端末からの受信接続を許可することは別です。通常のWeb閲覧の問題を解決するために、コアのコントロールAPIを公開しないでください。

最終確認と終了後にネットワークがつながらない場合の復旧

インストール後は、タスクトレイのアイコンを見るだけでなく、決まった手順で動作を確認しましょう。まずは動作確認済みのノードと一つの通信経路だけを使い、安定してから複雑なルールや追加設定を戻すのがおすすめです。

設定を確認：使用するサブスクリプションが選択され、コアのログに継続的なエラーがなく、プロキシグループが誤ってDIRECTやREJECTになっていないことを確認します。
通信を確認：プロキシを使う対象にアクセスし、「接続」で適用ルールと経路を確認します。出口IPの確認は補助として使ってください。確認リクエスト自体が直接接続のルールに一致する可能性があります。
アプリを確認：ブラウザーと、以前接続できなかったアプリをそれぞれテストします。ブラウザーが使えるだけで、すべての動作が正常だと判断しないでください。
終了時の状態を確認：まずシステムプロキシとTUNを無効にしてからクライアントを通常終了し、通常のネットワーク接続が復旧することを確認します。

クライアント終了後もWindowsのプロキシ設定がローカルを指している

クライアントが異常終了し、Windowsに127.0.0.1のプロキシ設定が残ったまま対応ポートの待ち受けがなくなると、システムプロキシに従うアプリはエラーになります。Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」を開き、「手動プロキシセットアップ」の「プロキシサーバーを使う」を確認してください。そのアドレスが終了したクライアントのものだと確認できた場合に限り、無効にします。組織で必要なプロキシや設定スクリプトは独断で削除しないでください。

TUNを無効にした後だけ問題が起きる場合は、クライアントを再起動し、TUNを通常の手順で無効にしてから仮想ネットワークアダプターとルートが復旧したか確認します。ネットワークアダプターを一括削除したり、ルートテーブルを消去したり、すべてのネットワーク設定をリセットしたりしないでください。他のVPNや企業ネットワークに影響する可能性があります。

フィールドをさらに調整する場合は、YAML設定マニュアルを参照してください。まず最小限の設定と一つの通信経路で動作させ、その後カスタムDNS、ルールによる振り分け、その他のネットワークツールを順に戻すと、すべてのオプションを一度に有効にするより問題を特定しやすくなります。