Clash TUNモード完全解説:仮想NICが全トラフィックを乗っ取る仕組みと有効化方法

NT-02.1システムプロキシが「全部は拾えない」理由

Clashの既定の動作方式はシステムプロキシ(System Proxy)だ。クライアントがシステムのネットワーク設定にHTTP/HTTPSプロキシのアドレスを書き込み、OSがそのアドレスをアプリケーションに通知し、アプリケーション側が従うかどうかを判断する。この「従うかどうか」がポイントで、システムプロキシは本質的に一種の推奨設定であり、強制的な転送ではない。大半のGUIブラウザや主要チャットツールはシステムプロキシ設定を読み取って従うが、コマンドラインツール(`curl`、`git`、`ping`)や一部のゲーム、古いクライアント、Android/iOSの一部アプリはシステムプロキシ設定を無視し、OSの下位ネットワークインターフェースから直接パケットを送出することが多い。

ここでよくある現象が生まれる。ブラウザでは速度テストも正常で目的のサイトにもアクセスできるのに、ターミナルで同じアドレスに`curl`すると即タイムアウトする。あるいは、あるアプリの設定で「システムプロキシを使用」をオンにしているのに、パケットキャプチャで見るとトラフィックがプロキシポートを一切経由していない。これは設定ミスではなく、システムプロキシという仕組みそのものの適用範囲が限られているためだ——「自ら読み取り、従う意思のある」プロセスしかカバーできない。

TUNモードが解決するのは、まさにこの適用範囲の問題だ。アプリケーションが「自発的に」プロキシ設定を読み取ることに依存せず、OSのネットワークスタックのより下位に仮想NICを1枚作成し、システムのルーティングテーブルをこの仮想NICに向けることで、ほぼすべての送信トラフィックが回避できないようにする。

NT-02.2仮想NICがトラフィックを乗っ取る仕組み

TUN(Tunnel、トンネルデバイス)はOSが提供する仮想ネットワークインターフェースの一種で、物理NICやWi-Fiアダプタと同様にシステムのネットワークインターフェース一覧に表示され、独自のIPアドレスを持つ。しかしその背後に実際の物理リンクは存在せず、送受信するパケットはこれを作成したユーザー空間プログラムに直接渡される。Clash Meta(mihomoコア)でTUNモードを有効にすると、システム内にこの仮想NICが作成され、ルーティングテーブルが調整されて、デフォルトルートまたは指定セグメントのトラフィックがこの仮想NICへ導かれる。

以降、アプリケーションが送出するIPパケットは、プロキシの存在を「認識」しているかどうかにかかわらず、まずシステムのルーティング判定を経てTUN仮想NICへ送られる。mihomoコアはユーザー空間でこれらの生パケットを読み取り、宛先アドレスとプロトコル情報を復元し、ルールセットに従って対応するポリシーグループにマッチさせ、実際のネットワークインターフェースを通じて選択したノードへ転送する。応答パケットは同じ経路を逆にたどり、TUN NICを経由してリクエスト元のプロセスに返される。この一連の処理はアプリケーションから見れば透明で、自分は目的サーバーと直接通信しているつもりでも、実際には1パケットごとにカーネルのルール判定を経ている。

これがTUNモードが「グローバル透過プロキシ」と呼ばれる理由でもある。TUNはネットワーク層で動作し、システムプロキシはアプリケーション層プロトコル(HTTP/SOCKS)の上で動作する。層が下がるほど適用範囲は広がるが、その分トラブルシューティングの視点も切り替える必要がある——「このアプリにプロキシ設定があるか」ではなく、「この端末のトラフィックが正しくルーティングされているか」を見るべきだ。

NT-02.3有効化前に理解しておくべき3つの設定項目

TUNモードはスイッチひとつで完結するものではなく、設定ファイルには通常以下の項目が関わってくる。意味を理解しておくと、後の切り分けの手間を大幅に減らせる。

1. enable:TUN機能全体のオン/オフを制御するブール値。これを有効にしてはじめて仮想NICが作成される。
2. stack:ユーザー空間ネットワークスタックの実装を選択する項目で、よく使われる値はsystem、gvisor、mixed。コアのバージョンによって対応する値が異なるため、基本的にはドキュメントが推奨する既定値を優先し、互換性の問題が出た場合に切り替えて比較する。
3. dns-hijack:TUN層でDNSクエリをハイジャックするかどうかの設定で、通常はリスンアドレス+ポートの形式(例:any:53)で書く。この項目は後述のDNS処理と直結しており、設定を誤るとドメイン解決の異常や振り分けルールの不動作を招く。

さらに、TUNモード下での振り分け判定は依然としてルールセットに依存しており、システムプロキシモードと同一のrules設定を共有する。違いは「トラフィックがどう内核に渡されるか」だけで、「内核がどう振り分けるか」ではない。つまりTUNを有効にしても既存ルールが失効することはないが、これまでシステムプロキシモードでは拾えていなかったトラフィックが露出することがある。

NT-02.4各プラットフォームでの有効化手順

クライアントごとに画面の入口は異なるが、いずれも内部的にはmihomoコアのTUNパラメータを呼び出しており、考え方は共通している。

Windows

1. 使用しているクライアントのコアがClash Meta/mihomoであることを確認する(旧Clashコアベースの一部クライアントはTUNに非対応)。
2. クライアント設定内で「TUNモード」または「Tun Mode」のスイッチを探す。初回有効化時は通常、管理者権限のリクエストが表示されるので許可する。
3. 非管理者権限でクライアントを起動していてスイッチが機能しない場合は、「管理者として実行」でクライアントを再起動する。
4. 有効化後、システムの「ネットワーク接続」一覧に、通常MihomoやMetaといった文字列を含む名称の仮想NICデバイスが新たに表示される。

macOS

1. クライアント設定でTUNモードを有効にすると、「ネットワーク拡張機能」または「システム拡張機能」の許可を求めるダイアログが表示される。
2. 「システム環境設定→プライバシーとセキュリティ」または「システム設定→ネットワーク→VPNとフィルタ」から、その拡張機能を手動で許可する。macOSのバージョンによってダイアログの表示位置は多少異なる。
3. 許可が完了したら、TUNスイッチを再度オンにする。クライアントのインストール時にすでにネットワーク拡張機能の権限処理が済んでいる場合、この手順は不要な場合もある。

Android

1. AndroidではTUNモードはシステムのVPNサービスインターフェースに対応し、有効化時に「接続のリクエスト」のようなシステム許可ダイアログが表示されるので、許可をタップすればよい。
2. 許可後はステータスバーにVPNアイコンが常時表示される。これはシステムレベルの通知であり、異常を示すものではない。
3. 他のVPN系アプリを同時にインストールしている場合、システムは通常1つのVPNサービスしかアクティブにできず、両者が互いに切り替わる形になる点に注意する。

Linux

1. TUNデバイスの作成にはCAP_NET_ADMIN権限が必要で、GUIクライアントでは通常sudoや権限付与の形でコアプロセスを起動する必要がある。
2. コマンドラインでmihomoコアを起動する際、権限を付与せずに起動するとログにTUNデバイス作成失敗が記録されるため、起動方法を確認する。
3. 一部のディストリビューションでは標準でファイアウォール(ufw、firewalldなど)が有効になっているため、仮想NICの転送を阻害する追加ルールがないか確認する。

NT-02.5有効化後によくある問題の切り分け

TUNモードは新たなルーティング層を導入するため、以下のような問題が頻発しやすい。

• 有効化後、まったくネットに接続できない:ルーティングテーブルが完全に乗っ取られた状態で、ルール設定に誤りがあるか、コアプロセスが異常終了して仮想NICが「ルートは占有しているが転送していない」状態になっているケースが多い。まずTUNを無効にしてシステムプロキシに戻し基本的な接続を確認したうえで、TUN設定のブロックを個別に切り分ける。
• 一部のセグメントでLAN内デバイスにアクセスできない:TUNモードが既定で全ルートを乗っ取ると、LAN内のプリンターやNASなどのデバイスへのアクセスに影響が出ることがある。ルールでLANセグメント(例:192.168.0.0/16、10.0.0.0/8)に直結(DIRECT)ポリシーを設定し、プロキシルーティングの対象から除外する必要がある。
• 他のVPNソフトとの競合:同一デバイスで企業VPNや他の仮想NICベースのツールを併用していると、両者がデフォルトルートを取り合い、断続的な切断やルートの乱れとして現れることがある。同時に有効化する仮想NIC系ツールは1つに絞ることを推奨する。
• DNS解決の異常:dns-hijackとfake-ipを合わせて設定していない場合、ドメイン解決が依然として端末本来のDNSを経由し、ドメイン名でマッチする振り分けルールが機能しないことがある。これは「ネットには繋がるが振り分けが正しくない」という形で現れる。

NT-02.6TUNが向いているケースと不要なケース

TUNモードは「グローバルであればあるほど良い」という選択肢ではなく、有効化するかどうかは実際のニーズによって決めるべきだ。

• コマンドラインツール、開発環境、ゲームクライアントなどブラウザ以外のプログラムをプロキシ経由にする必要がある場合、TUNは現時点で最も確実な方法だ。
• 普段ブラウザと主要なチャットツールしか使わず、それらがシステムプロキシを正しく読み取れているなら、システムプロキシモードのままにしておくほうが手間が少なく、問題が出たときの切り分けも短時間で済む。
• 企業のオフィスネットワークや、常駐するVPNクライアントが既にある端末では、既存のネットワークポリシーと競合しないかを先に確認したうえで、慎重にTUNを有効化する。
• モバイル端末のバッテリーや安定性に不安がある場合は、まずデスクトップ環境でルールセットの設定が妥当かを確認してから、スマートフォンで常時有効化するかどうかを判断するとよい。

総じて、TUNモードが解決するのは「適用範囲」の問題であり、システムプロキシが解決するのは「これで十分」という日常的な場面だ。両者がネットワークスタックのどの層で動いているかという違いを理解しておけば、「あるアプリがプロキシを通っていない」という問題に遭遇したときも、クライアントを何度も再起動して試行錯誤するのではなく、どのモードに切り替えるべきかを即座に判断できる。