なぜ Windows では TUN が話題になるのか

ブラウザや一部アプリは OS の「システムプロキシ」設定を読みますが、ターミナル向けツール、旧来のデスクトップアプリ、ゲームクライアントなどはそもそも HTTP プロキシを参照しないことが珍しくありません。そこで登場するのが TUN モードです。仮想ネットワークアダプタ経由でトラフィックをコア（Mihomo／Clash Meta など）に引き込み、ルールエンジンで振り分ける、いわゆる透明プロキシに近い挙動を狙えます。

Windows ではその仮想層として Wintun が広く使われます。GUI によっては「TUN をオンにする」ボタン一つに見えますが、裏側ではドライバの導入・更新、管理者権限、他製品 VPN との既定ルートの取り合いが絡みます。見かけは単純でも、失敗パターンは層が重なるほど増えます。

Wintun とは／「入らない」ときにまず疑うこと

Wintun は WireGuard プロジェクト由来のユーザー空間向け仮想ネットワークドライバで、従来の TAP に比べてオーバーヘッドが小さいことが知られています。Clash 系クライアントの TUN 実装は、環境によって Wintun を同梱したり、初回起動時に展開したりする方式が一般的です。

インストールや初期化が失敗しやすい典型要因は次のとおりです。順に潰すと再現性の高い復旧がしやすくなります。

  • 管理者権限がない：TUN の有効化やドライバ操作には昇格が必要な GUI が多く、通常ユーザーだとサイレントに失敗することがあります。
  • セキュリティ製品や企業ポリシー：カーネルドライバのロードをブロックする EDR／AV があり、ログに「署名はあるがポリシーで拒否」と出るケースがあります。
  • 古い TAP／別 VPN の残骸：以前の OpenVPN 用 TAP や、別ブランドの仮想アダプタが残り、名前解決やルートテーブルが混乱することがあります。
  • 破損した更新の取りこぼし：アプリだけ更新し、同梱の Wintun バイナリやサービス側が古いまま、という不整合も起こり得ます。
注意：デバイスマネージャで未知のデバイスを無理に削除したり、レジストリを手編集したりするのは最終手段に留めてください。まずは公式 GUI の「修復」「再インストール」、クライアントのクリーンインストール、Windows の再起動から試す方が安全です。

有効化の現実的な手順（失敗しにくい順）

クライアントは Clash Verge Rev や他の Mihomo 同梱 GUI など様々ですが、共通して効くのは次の流れです。

  1. クライアントを管理者として実行できる状態にする（右クリックメニューや互換設定）。
  2. 他社 VPN や「常時接続」の仮想アダプタを一時停止し、ルートが一つにまとまる状況を作る。
  3. TUN をオフにした状態でコアが通常どおり接続できるか確認してから、TUN をオンにする（段階切り分け）。
  4. 失敗したらログを保存し、同じバージョンのクリーンインストールか、安定版へのロールバックを検討する。

設定ファイル側では tun.enable: true に加え、stack（例：system と gvisor）や auto-route、auto-detect-interface などの組み合わせが環境依存で効きます。ある PC では system が安定し、別環境では gvisor の方が競合が少ない、という話は珍しくありません。一度に複数項目を変えず、ログを見ながら一つずつ試すのがコツです。

TUN をオンにしたら「まったくネットに繋がらない」

症状が全アプリ同時に不通なら、プロキシノード自体より先に、ルーティングと DNS を疑うのが近道です。

既定ゲートウェイと競合 VPN

TUN は多くの場合、トラフィックをコアへ向けるためにルートテーブルを書き換えます。同時に別の VPN が「全トラフィックを自分へ」と主張していると、往復のどちらかが壊れて「見た目オンだが一切 ping も通らない」状態になります。対策は、併用するならどちらが主導権を握るかを決め、もう一方をスプリットトンネル相当に寄せるか、時間をずらして切り替えることです。

DNS が解けない

ルートは生きているのに名前だけが解けない場合は、OS の DNS キャッシュ、ブラウザのセキュア DNS、コア側の dns-hijack や dns.enable の整合を確認します。TUN と DNS はセットで設計した方が事故が減ります。詳細な設計思想は DNS 漏洩防止ガイド でも触れています。

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

上記はあくまで構造の例です。実際の stack やインタフェース名は GUI の生成 YAML とログに合わせてください。dns-hijack を広く取りすぎると社内ドメインやキャプティブポータルと衝突することもあるため、運用ポリシーに応じて範囲を絞る判断も必要です。

IPv6 の取りこぼし

IPv4 だけ TUN に載せ、AAAA クエリや IPv6 経路が別出口に逃げると、「一部サイトだけ開かない」「速度だけ不安定」などに見えます。ルータ設定と OS の IPv6 のオン／オフ、コア側の ipv6 フラグを揃えて比較テストしてください。

一部のソフトだけプロキシを踏まないように見える

TUN が有効でも、管理者権限で動くプロセス、独自にソケットを張るアンチチート、ハードコードされたエンドポイントを持つアプリは、想定外の経路を取ることがあります。また、ルールで DIRECT に落ちているドメインは、見かけ上「プロキシを使っていない」ように見えます。

切り分けの手順は次のとおりです。

  • コアのログで該当フローが どのルール行にマッチしたかを確認する。
  • PROCESS-NAME や PROCESS-PATH 系のルールがあれば、意図せず DIRECT になっていないか見る。
  • ゲームやライブ配信ツールは UDP と TCP の扱いが分割されやすいので、プロキシグループと fallback の挙動もあわせて確認する。

速度や遅延だけが気になる場合は、TUN 以前のボトルネック（購読の肥大化、DNS RTT、ノード選定）もあります。高速化のテクニック と併せて読むと、体感の改善ポイントが整理しやすくなります。

GUI の差と、用語の確認先

同じ Mihomo コアでも、GUI ごとに「TUN スイッチ」の名称、サービスモードの有無、YAML の編集画面が異なります。スクリーンショット付きの導線が必要なら、既存の Clash Verge Rev ガイド も参照ください。一方で、フィールド名の意味や全体像は ドキュメント の方が一次情報に近いことが多いです。

オープンソースのライセンスやソースコードを確認したい場合は GitHub 上の公式リポジトリが適切ですが、日々のクライアントの入手と更新は、検証済みパッケージがまとまっている公式のダウンロード導線に寄せた方が、Wintun 同梱物の取りこぼしなどを減らしやすいです。

最終チェックリスト（そのままメモにどうぞ）

  • 管理者昇格で TUN を試したか
  • 他 VPN／仮想アダプタを切り離して再現するか
  • TUN オフ時は通常接続できるか（ノードとルールの切り分け）
  • stack を切り替えて挙動が変わるか
  • DNS（OS・ブラウザ・コア）の二重指定を解消したか
  • IPv4／IPv6 の経路が期待どおりか
  • ログのルールマッチと期待が一致するか

まとめ

Windows で Clash 系の TUN を安定運用するコツは、ドライバ層・ルート・DNS・ルールの四層を同時に疑わないことです。一度に全部をいじると原因が特定できなくなるので、TUN オフでのベースライン確認から入り、オン後に何が変わったかをログで追う流れが再現性の高いトラブルシュートになります。

同じコアでも GUI や同梱物の世代差で挙動が変わるため、長期利用では「コアと GUI をセットで更新する」「異常時はクリーンインストールを許容する」といった運用が現実的です。関連トピックは 技術ブログの一覧 から辿れます。→ Clash を無料ダウンロードして、Windows で TUN を含む構成を試す