Windows で Clash Verge Rev の TUN モードを有効にする：Service 導入と権限設定

なぜ Windows で TUN が必要になるのか

システムプロキシは、OS のプロキシ設定を尊重するアプリ（多くのブラウザや Win32 アプリ）に対して有効です。Clash Verge Rev がローカルで待ち受ける 127.0.0.1:ポート へトラフィックを向ける仕組みです。一方、UWP（Microsoft Store アプリ） はループバック通信が制限され、プロキシ設定を読まないアプリも少なくありません。結果として「Edge は海外サイトが開くのに Store だけ失敗する」「ログに対象アプリの接続がほとんど出ない」という状態になります。

TUN モードは仮想ネットワークアダプタ（多くは Wintun）を介して、IP レイヤでトラフィックを mihomo コアに渡します。アプリがプロキシを参照しなくても、ルールに従って DIRECT または PROXY へ振り分けられるため、UWP やプロキシ非対応ソフトの取りこぼしを減らせます。UWP だけ個別に CheckNetIsolation でループバック解放する方法もありますが、対象アプリが増えるほど運用が煩雑になります。全体キャプチャが必要なら TUN が現実的な選択肢です。UWP 特化の切り分けは「Windows UWP とループバック／TUN」も参照してください。

始める前の前提条件

TUN は変数が増える機能です。土台（購読・コア・システムプロキシ）が未整備のまま TUN だけオンにすると、原因が DNS なのかルールなのか Service なのか切り分けにくくなります。初日はブラウザ疎通を確認してから本稿の Service／TUN 手順に進むのが安全です。

システムプロキシと TUN の使い分け

方式	向いている場面	弱点
システムプロキシ	ブラウザ中心、設定が軽い、管理者権限が少ない	UWP・一部 CLI・ゲームが無視しやすい
TUN モード	プロキシ非対応アプリ、Store／UWP、プロセス単位分流の土台	Service／ドライバ、DNS 設計、VPN 競合の管理が必要

両者は排他ではありません。Verge Rev では システムプロキシをオンにしたまま TUN も有効にする運用が一般的です。TUN が IP レイヤで拾い、HTTP プロキシ経路は従来どおり mixed-port へ流れるイメージです。初回有効化時だけは、一度 TUN をオフに戻せる状態を維持しながら進めてください。

手順 1：Clash Verge Service をインストールする

Windows 版 Clash Verge Rev では、TUN や仮想アダプタ操作を GUI プロセスから分離するため、Service モード（バックグラウンドサービス）の導入が推奨されます。設定画面（歯車アイコン）を開き、Service または サービスモード 相当の項目を探します。表示例はバージョンで多少異なりますが、次の流れが典型です。

1. Verge Rev を管理者として実行する（スタートメニュー → 右クリック → 管理者として実行）。
2. 設定 → Install Service（サービスをインストール）をクリックする。
3. UAC ダイアログで発行者とパスを確認し、はい で承認する。
4. 成功メッセージまたは Service 状態が「実行中」「Installed」などに変わることを確認する。
5. 必要なら Verge Rev を一度終了し、通常権限で再起動して Service 経由でコアが動くか見る。

手順 2：管理者権限と UAC を正しく通す

TUN 有効化時には Wintun などの仮想アダプタドライバのロード、ルーティングテーブルの更新、場合によってはファイアウォール規則の追加が走ります。初回は ユーザーアカウント制御（UAC） が複数回出ることがあります。実行ファイルのパスがインストール先の Verge Rev 本体であることを確認してから承認してください。

会社支給 PC では、管理者権限が制限され Service 登録自体が拒否されることがあります。その場合は IT 部門に「ローカルプロキシ／VPN クライアント用のサービス登録」可否を確認するか、許可された範囲でシステムプロキシのみの運用に留める必要があります。無許可のドライバ導入はポリシー違反になり得ます。

権限まわりを整えたら、Windows セキュリティ → ファイアウォール で Verge Rev および関連サービスがプライベートネットワークで通信できるかも見ておきます。過度に公開する必要はありませんが、ローカルループバックと TUN アダプタ間の通信が阻害されていないかは、不通時のチェック項目です。

手順 3：Verge Rev で TUN モードをオンにする

Service が正常な状態で、メイン画面または設定パネルの TUN モード（TUN Mode）トグルをオンにします。バージョンによってはホーム画面のスイッチ、設定 → システム設定 → TUN、またはトレイメニューから有効化する UI です。オンにした直後、次を確認します。

• デバイスマネージャーまたは 設定 → ネットワークとインターネット → 詳細なネットワーク設定 に、Clash／Wintun 系の仮想アダプタが追加されているか。
• Verge Rev のログに TUN 起動成功を示す行があり、エラーが連発していないか。
• 既存の システムプロキシ トグルが意図どおり（通常はオン維持）か。

有効化直後に一時的な接続断が起きることはあります。30 秒ほど待ってからブラウザと問題アプリを再試行してください。それでも全アプリが不通なら、すぐ TUN をオフに戻し、次節の Mihomo 設定と DNS を疑います。

手順 4：Mihomo の TUN 設定（auto-route・stack）

Verge Rev は GUI から TUN 関連オプションを書き込み、生成 Profile に mihomo の tun: ブロックをマージします。上級者は Profile エディタや mixin で直接編集することもできます。典型的な Mihomo TUN 設定の考え方は次のとおりです。

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  strict-route: false
  dns-hijack:
    - any:53

stack は TUN スタックの実装方式です。system は Windows ネイティブに近く互換性が高い一方、gvisor や mixed は環境によって UDP や特定アプリで挙動が変わります。まずは Verge Rev の既定（多くは system）で試し、Discord 音声など UDP 問題が出たら「TUN と UDP／Discord 音声」を参照してください。

auto-route をオンにすると、既定ルートが TUN 側へ向き、ルールに従って DIRECT／PROXY が決まります。dns-hijack は DNS クエリを Clash の DNS モジュールへ誘導し、fake-ip と組み合わせた Profile では名前解決の一貫性に効きます。逆に、社内 DNS や split DNS と衝突すると「接続はあるのにページが開かない」症状になります。その場合は「DNS と fake-ip の切り分け」が先です。

strict-route はルートを厳密に TUN に縛るオプションです。LAN や Tailscale などローカル網を DIRECT で残したい場合は、strict-route: false のまま、route-exclude-address やルール側で私有 IP を DIRECT にする設計が一般的です。Tailscale や Zerotier と併用する場合は「Tailscale と TUN のルート優先」も読んでください。

手順 5：初回有効化後の検証

TUN をオンにしたら、次の順で動作確認すると原因切り分けが速くなります。

1. ブラウザ：海外・国内サイトが Rule どおりに振り分けられるか（従来どおりであるべき）。
2. 問題だった UWP／Store：更新やログインが Clash ログに載るようになったか。
3. ターミナル：curl -I https://example.com などで出口が変わるか（環境変数 HTTPS_PROXY 未設定でも TUN なら拾える場合がある）。
4. 遅延テスト：Verge Rev 内蔵のノード遅延が TUN オン後も正常か。
5. ログ：DIRECT ばかりならルール順、全面タイムアウトなら DNS やノード、tun 関連エラーなら Service／ドライバ。

うまくいかないときの対処

Service インストールが失敗する

以前の Clash 系 Service が残っている場合、サービス管理（services.msc）で同名または類似名のサービスを確認し、不要ならアンインストール後に Verge Rev を再インストールします。ポータブル版を複数フォルダにコピーしていると、Service が別パスを指して混乱することもあります。一つのインストール先に統一してください。

仮想アダプタの競合

商用 VPN、Hyper-V、仮想化ソフト、別の TUN 製品が同時にルートを握ると、TUN オン直後から不安定になります。検証時は他 VPN を一度オフにし、デバイスマネージャーで無効な仮想アダプタを整理してから再試行します。

TUN オン後に名前解決だけ失敗する

dns-hijack と Profile 内 dns: ブロック、fake-ip の組み合わせを見直します。一時的に TUN をオフに戻し、システムプロキシだけで DNS 問題が再現するか切り分けます。社内 DNS 必須環境では hijack 範囲を狭める必要があることもあります。

終了後もネットがおかしい

TUN とシステムプロキシの両方が OS に残留すると、Verge Rev を閉じてもプロキシ設定やルートが残ることがあります。「Clash 終了後のシステムプロキシ復旧」の手順で OS 側を手動リセットしてください。

よくある質問

Q. Service は必須ですか？

厳密な必須ではありませんが、Windows で TUN を常用するなら Service 導入を強く推奨します。管理者昇格なしの日常起動でも TUN を維持しやすく、UAC の出現頻度も下がります。PoC だけなら管理者 GUI でも構いません。

Q. Windows 10 でも同じ手順ですか？

大筋は同じです。Win10 初回導入の細部（SmartScreen 等）は「Verge Rev · Windows 10 インストール」を併せて参照してください。TUN と Service の項目名は Verge Rev のバージョンに依存します。

Q. システムプロキシはオフにすべきですか？

通常はオン維持で問題ありません。TUN が拾えない特殊な経路をシステムプロキシが補完する場合もあります。両方オフにするとローカルリスナーへトラフィックが届かず、全面不通になりやすいので注意してください。

まとめ：Windows で TUN を安全に有効化する順序

ワンクリック型 VPN や、TUN／Service 設定を隠した簡易クライアントでは、UWP やプロキシ非対応アプリの取りこぼしを後から個別に直す余地が少なく、ログも見づらいことが多いです。ルール編集や DNS 設計を自分でコントロールしたいユーザーには、オープンな Clash／Mihomo エコシステムの方が、長期運用での再現性に優れます。

Clash は Meta 互換の構成資産をそのまま活かせ、Windows でも macOS でも同じ YAML の考え方で TUN と分流を組み立てられます。Verge Rev で Service と権限の壁を越えたあと、ルールや mixin で環境に合わせた TUN 設計を重ねていくのが、2026 年時点での現実的な Windows 運用です。設定方針が固まったら、公式の入手経路から Clash をダウンロードし、同じ Profile 資産を他クライアントへ持ち運ぶ選択肢も検討してみてください。