TUN モードが「システム級」の手触りになる理由
一般に Clash 系クライアントでいう TUN（仮想ネットワーク／トンネル）モードは、オペレーティングシステムに仮想インターフェイスを追加し、TCP だけでなく多くの UDP セッションも同じルールエンジンに流し込む仕組みです。HTTP プロキシ設定を読まないゲームクライアントや、環境変数を見ない OS コマンド、その他プロキシ非対応のバイナリがシステムプロキシ越しに取りこぼされる典型例に対して、TUN は「スタックの一段上でトラフィックをひとまとめに預ける」アプローチを取ります。
したがってユーザー体験としては、意図した範囲の通信がまとめて Mihomo（俗称 Clash Meta）のパイプラインに入り、そこでルール・プロファイル・DNS ポリシーが一貫して適用される点が「システムに近いグローバルさ」の正体です。もちろん銀行アプリの直結やローカル NAS など、意図的に直達させたい経路もルールで残す必要があり、ここを誤ると国内サイトまで遠回りして遅延が跳ね上がります。
システムプロキシだけでは何が足りないのか
OS が提供する「システムプロキシ」は、ブラウザや Electron アプリ、多くのデスクトップ向け HTTP クライアントには効きます。しかし次のような空隙が残りがちです。一つ目は、独自ソケットを開いてプロキシ設定 API を呼ばないゲームやボイスチャット。二つ目は HTTP_PROXY などを見ない CLI ツール。三つ目は UDP を主体にしつつプロキシ情報を参照しないサービス観測ツールです。これらは仮想的にいうと「OS が配るプロキシ案内を無視する」ことがあるため、HTTP ポートへ誘導するだけの構成では取りこぼします。
TUN はそこに仮想 NIC を差し込み、スタックが配送しようとするパケットを Mihomo 側のユーザー空間処理へ引き渡します。結果として「アプリがプロキシを意識していなくても」同じルーティング判断に乗せられる余地が広がります。反対に、権限昇格、他 VPN との排他、ドライバ署名、セキュリティソフトとの併用といった OS レベルの話題も一緒についてくるため、不必要に常時オンにしない運用も現場では一般的です。
スタック処理と DNS を同時に設計する
Mihomo は fake-ip や redir-/tun スタックの組み合わせにより、名前解決から転送までを一貫して握る設計が可能です。TUN を有効にしても、DNS の向き先が OS の既定リゾルバに残っていると、意図しない漏れやループが発生します。典型的には「ブラウザでは速いのにターミナルだけ遅い」「特定ドメインだけ国内サーバに届かない」などの不整合が症状として現れます。
実務では次の観点をチェックリスト化すると安定しやすいです。プロファイル内の dns ブロックで enhanced-mode や nameserver／fallback の階層が妥当か。tun セクションの stack 指定と OS の相性。route-address や除外ネットワークがローカル帯を飲み込んでいないか。ログに出る「DNS クエリがループ」「インターフェイス競合」といった警告を放置していないか。ここまでが揃って初めて「システム級」の利点が頭打ちなく活きます。
Windows：昇格と仮想アダプタの承認
Windows では仮想アダプタの作成やルートテーブル調整に管理者権限が関わることがあり、ユーザーアカウント制御（UAC）のダイアログが表示されます。Clash Verge Rev では設定ページの TUN トグルをオンにし、求められたら承認します。企業端末ではグループポリシーでドライバ追加が制限されている場合もあるため、その際は情報システム部門の方針に従ってください。
手順を具体化すると、① Mihomo 対応ビルドが動いていること、②有効な購読プロファイルが選択されていること、③モードがルール（Rule）であることを確認、④ TUN をオン、⑤タスクトレイまたはダッシュボードでインターフェイスがアクティブか表示を見る、の順が安全です。もしオンにできない場合は、他社フルトンネル VPN が先行している、SmartScreen 以外のエンドポイント制御がブロックしている、古い TAP ユーティリティが競合している、といった線を疑います。
macOS：ネットワーク拡張とプロファイル競合
macOS ではネットワーク拡張権限や鍵チェーン関連のダイアログが出ることがあります。初回のみ許可が必要なケースがほとんどです。Apple Silicon と Intel でパッケージが分かれているため、自分の CPU アーキテクチャに合ったビルドを入れておく前提を忘れないでください。
TUN をオンにした直後に国内動画だけ遅くなった場合は、地理的に近い CDN へ行くはずの経路がルール上プロキシ側へ流れている可能性があります。GEOIP や DOMAIN-SUFFIX の並び順を見直し、ローカル直結すべきドメインを上に持ってくると改善することがあります。Spotlight や iCloud の同期系が遅いときも同様で、盲目的にグローバルモードへ逃げるよりルール調整が筋が良いです。
Android：VPN スロットによる実質 TUN
Android はユーザー空間から直接カーネル TUN をさわる代わりに、VPN API を通じて単一のトンネル接続を提供します。FlClash のような Mihomo GUI は接続ボタンを押し、VPN 権限を与えると、実質的にデスクトップ TUN と同種の「全体取り込み」が始まります。画面には「VPN が接続中」と出ますが、中身は購読ルールにしたがって振り分けられます。
注意点は二つ。他アプリも VPN スロットを奪い合うため、常時接続型の企業 VPN と同時利用は期待しないこと。バッテリー最適化でバックグラウンドプロセスが止まる端末では、接続が勝手に切れることがあり、除外設定を検討することです。いずれも「技術的には TUN 相当だが OS の枠組みに依存する」という意味での制約です。
ルールモードを外さない理由
TUN はトラフィックを拾う仕組みであり、出口の選び方そのものはモード設定とルールファイルが決めます。もしグローバルモードで運用すると、国内のニュースサイトや決済 API まで遠方のノードへ流れ、体感速度とサーバ負荷の両方が悪化します。利用者にとってもプロバイダにとっても得にならないので、日常利用ではルールモードを既定に戻すのが筋です。
また、社内イントラや医療機関のポータルなど、プロバイダ既定リストに無いドメインはローカル追記が必要です。リストは自動更新される一方で、勤務形態によっては自前の例外が増えるため、メモを残しながら小さな YAML フラグメントで管理する手法が現場では安定します。
切り分け：よくある症状と当面の対処
ブラウザは通るが特定アプリだけ不通
まずシステムプロキシのみの状態と TUN オンを比較します。後者で改善するならプロキシ非対応／UDP 優先の可能性が高いです。改善しないならルールで該当ホストが拒否や別出口に落ちていないかを確認します。
TUN トグルがすぐオフに戻る
競合 VPN、権限不足、企業ポリシー、クラッシュ後のフェイルセーフなどを疑います。ログにスタックトレースが出ていないか、同じ構成をクリーンインストールした環境でも再現するかを見ます。
遅延がジワジワ増える
UDP を含むトラフィックが地理的に遠いノードへ寄ったサインです。該当サービスのASNや地域ルールを直結側へ寄せ、必要ならノードを差し替えます。速度より安定性を取る用途では、遅延テストより実ゲームやボイスでの往復を観察したほうが早いこともあります。
よくある質問（本文）
Q. 仕事用 VPN と併用したい。
通常は同時に一本しか張れません。業務端末ポリシーを優先し、個人用トンネルは時間を分けるか、許可されたスプリット構成があればそれに従ってください。
Q. Linux ヘッドレスでも同じか。
概念は同じですが、GUI トグルは無いため systemd ユニットやコマンドラインで tun スタックを上げます。権限は root 相当が必要になる場面があります。
Q. ルーター全体へ広げたい。
TUN は端末ローカルの話です。LAN 全体を覆うにはゲートウェイ側に別途透過プロキシや専用機を置くアーキテクチャになり、本稿のスコープ外です。
実運用では「核」と「殻」の両方が効く
要件が高度になるほど、YAML の美しさより実際に TUN を安全に載せられるクライアント実装がボトルネックになります。更新が止まったフォークは新プロトコルやドライバ署名の変更に追従できず、表面的には同じトグルでも裏側の実装差で不安定になることがあります。逆に、コミュニティレビューが透明で Mihomo のリリースに追随し、購読取り込みやログ閲覧が素直な製品は、同じルール群でも「つながり切る率」が段違いです。
また、匿名性だけを謳うクローズドビルドの中には、余計な権限を要求したり、挙動の説明が曖昧なものも混じります。システムレベルでトラフィックを預ける以上、信頼できる配布元と検証可能な更新履歴を選ぶほうが、長期的には短絡的な機能アピールよりもリスクを減らします。もし「TUN の原理は理解できたが、どのパッケージから入れば安全か分からない」という段階なら、まずは整理済みの入手導線で自分の OS に対応したビルドを確かめるのが近道です。
当サイトのクライアント一覧では、Mihomo ベースでメンテが確認しやすいものをプラットフォーム別にまとめています。自身の環境に合わせて入手し、この記事のチェック項目に沿ってルールと DNS を整えれば、システムプロキシだけでは届かなかったトラフィックも、過剰なグローバル化を避けつつ束ねられるはずです。