Clash TUN モードとは:仮想ネットワークアダプタが全通信を捕捉する原理と有効化手順

DOC-01

システムプロキシモードの適用範囲

多くのユーザーが Clash に初めて触れる際に使うのは、システムプロキシモードです。この仕組みは、クライアントがローカルに HTTP/SOCKS5 ポートを立て、OS やブラウザがそのポートをプロキシ設定に書き込み、アプリがリクエストを発行する際にこの設定を読み取って、通信をローカルポートへ転送し、Clash が処理するという流れです。この経路には二つの前提があります――アプリがシステムプロキシ設定を読み取る仕組みに対応していること、そしてアプリが使うプロトコルがプロキシの対応範囲内であることです。

問題はまさにこの二つの前提にあります。一部のコマンドラインツール、一部のゲームクライアント、独自のネットワークスタックを内蔵したアプリは、システムプロキシ設定を読み取らない、あるいは HTTP プロトコルのみ対応で UDP をサポートしないケースがあります。こうした通信は Clash を迂回し、そのまま物理ネットワークアダプタから直接送信されます。結果として、ブラウザの振り分けは正常なのに、特定のクライアントだけ常に接続に失敗する、あるいは常に本来の実 IP で通信してしまう――こうした問題の根本原因は大抵ここにあります。

システムプロキシモードの適用範囲の盲点は三種類に分類できます。システムプロキシ設定に従わないプロセス、UDP に依存していてプロキシプロトコルが転送に対応していないケース、そしてアプリ層より下位で通信を発生させるシステムサービスやドライバーです。TUN モードはまさにこれら三種類の盲点を埋めるために存在します。

DOC-02

TUN モードの動作原理

TUN は仮想ネットワークデバイスの一種で、OS のカーネルネットワークスタックのインターフェース層で動作します。Clash Meta(コア mihomo)で TUN モードを有効にすると、システム内に仮想ネットワークアダプタが作成され、システムのルーティングテーブルを書き換えることで、デフォルトルートまたは指定したセグメントの通信をこの仮想アダプタへ導きます。この時点で、通信の捕捉ポイントはアプリ層のプロキシ設定から、ネットワーク層のルーティングルールへと移ります。

この違いが適用範囲の差を決定づけます。システムプロキシモードは「アプリ側が能動的に対応してこそプロキシされる」のに対し、TUN モードは「システムルートを通る限り必ず捕捉される」という仕組みです。通信を発生させたのがブラウザであれ、コマンドラインツールであれ、バックグラウンドサービスであれ、そのデータパケットがシステムネットワークスタックを経由する限り、仮想ネットワークアダプタへルーティングされ、Clash コアがルールに従って処理します――直接接続か、プロキシ経由か、拒否か。判定ロジック自体は通常のプロキシモードと完全に同じで、通信の入口だけが変わっているのです。

具体的な流れは概ね以下の通りです。

1. Clash コアが仮想ネットワークアダプタ(Meta や utun デバイスなど)を作成し、仮想 IP セグメントを割り当てる。
2. コアがシステムルーティングテーブルにルールを挿入し、捕捉が必要な通信をこの仮想アダプタへ向ける。
3. アプリが送信したデータパケットがシステムのルーティング判定を通過し、物理アダプタではなく仮想アダプタへ入る。
4. Clash コアがユーザー空間で仮想アダプタのデータを読み取り、元の TCP/UDP 接続リクエストを復元する。
5. ルールリストに従って直接接続か特定のプロキシノード経由かを判定し、対応する出口から転送する。

この仕組みには、仮想ネットワークアダプタの作成とルーティングテーブル書き換えを行うシステム権限がクライアントに必要です。これが、システムプロキシモードのようにスイッチひとつで使えるのとは違い、TUN モードが各プラットフォームで追加の権限承認を求める理由です。

DOC-03

二つのモードの主な違いの比較

システムプロキシモードと TUN モードを同一の表で比較すると、どの場面でどちらを使うべきか判断しやすくなります。

簡単な結論としては:ブラウザの振り分けだけが目的であればシステムプロキシモードで十分で、設定もより簡単です。プロキシ設定に対応しないプロセスも含めて、ローカルの全通信をルール管理下に置きたい場合は、TUN モードが必須の選択肢になります。

DOC-04

プラットフォーム別の有効化手順

各プラットフォームの仮想ネットワークアダプタの実装は異なり、承認方法も異なります。以下ではプラットフォームごとに説明します。

Windows

Windows 上の TUN 実装は Wintun ドライバーに依存しており、主要なクライアント(Clash Verge Rev、Clash for Windows 系デスクトップクライアントなど)のインストーラーにはこのドライバーが既に統合されています。初回有効化時には通常、システムのドライバーインストール確認や UAC 権限昇格のダイアログが表示されるため、クライアントを管理者権限で実行し、ドライバーのインストール要求を許可する必要があります。そうしないと仮想アダプタを作成できません。

1. システムプロキシモードを無効にする(二つのモードのルーティングルールが干渉するのを避けるため)。
2. 管理者権限でクライアントを再起動する。
3. 設定内で TUN モードのスイッチを見つけて有効化し、ドライバーインストールの確認画面が出たら許可をクリックする。
4. 「ネットワーク接続」パネルを開き、Meta などの名称の仮想アダプタが表示され、状態が接続済みになっていることを確認する。
5. ブラウザで IP 確認ページにアクセスし、出口 IP がプロキシノードの所在地域に変わっているか確認する。

macOS

macOS はシステム標準の utun インターフェース群を使用するため、クライアントによる仮想アダプタ作成自体には追加のドライバーは不要ですが、ヘルパープロセスの権限が必要です。デスクトップクライアント(Clash Verge Rev、ClashX 系など)で初めて TUN を有効化する際、特権付きヘルパーツールのインストールが要求され、システムがパスワード入力欄を表示するので、現在のユーザーのパスワードを入力して承認します。

1. 設定内で TUN モードのスイッチを有効にする。
2. システムが権限承認画面を表示したら、macOS のログインパスワードを入力して確認する。
3. クライアントがヘルパーサービスのインストールまたは更新が必要だと表示した場合、案内に従って一度だけインストールを完了する。
4. システムの「ネットワーク」設定パネルで、新しい仮想インターフェースが追加されているか確認する。

比較的新しいバージョンの macOS はシステム拡張機能やネットワーク拡張機能の権限を厳しく制限しているため、承認画面が表示されない、またはクリックしても反応がない場合は、「システム設定 - プライバシーとセキュリティ」でブロックされているバックグラウンドコンポーネントがないか確認し、手動で許可してからクライアントを再起動して試してください。

Android

Android 上の TUN モードはシステムの VPNService インターフェースを通じて実装されており、これはシステムがアプリに提供している全体プロキシの標準的な仕組みで、root 権限は不要です。有効化方法は一般的な VPN アプリを承認するのと似ています。

1. クライアント(Clash Meta for Android など)内で TUN または「仮想ネットワークアダプタ」のスイッチをオンにする。
2. システムが「接続リクエスト」ダイアログを表示し、このアプリが VPN 接続を確立することを通知するので、OK をタップする。
3. ステータスバーに VPN アイコンが表示されれば、仮想アダプタが有効になったことを示す。
4. 特定のローカルアプリをプロキシから除外したい場合は、アプリ別プロキシ設定で個別にチェックを外す。

注意点として、システム上では同時に一つの VPNService しか有効にできません。デバイス上に他の VPN 系アプリがインストールされ有効になっている場合、両者が競合するため、先にもう一方を無効にする必要があります。

iOS

iOS 上での相当する仕組みは NetworkExtension フレームワーク配下の個人用 VPN 設定です。クライアントが対応するモードを初めて有効にする際、VPN 設定プロファイルのインストールが要求されるので、システムの確認画面で信頼を確認する必要があります。

1. クライアント設定内で全体通信捕捉に関するスイッチを有効にする。
2. システムが「VPN 設定の追加を許可」の画面を表示するので、デバイスのパスコードを入力するか Face ID で確認する。
3. 「設定 - VPN」でこの設定の状態が接続済みになっていることを確認する。

Linux

Linux 上での TUN デバイス作成はカーネル標準の tun モジュールに依存しており、通常は追加のドライバーインストールは不要ですが、クライアントプロセスがインターフェースを作成しルーティングテーブルを書き換えるには CAP_NET_ADMIN 権限、または root 権限での実行が必要です。

# root 権限でクライアントを実行するか、バイナリファイルに個別にネットワーク管理権限を付与する
sudo setcap cap_net_admin,cap_net_raw=eip /path/to/clash-core

権限を付与した後は、通常ユーザー権限でクライアントを実行して TUN モードを有効にできるため、毎回 sudo でプログラム全体を起動する必要がなくなり、不要な権限露出を減らせます。

DOC-05

よくある競合と切り分けの考え方

TUN モードは仮想アダプタとルーティングテーブルの書き換えに関わるため、問題が発生したときは「接続はできるが効果が出ていない」「そもそもネットに繋がらない」といった形で現れることが多く、明確なエラーメッセージが出にくいのが特徴です。以下、よく発生するケースをいくつか紹介します。

他の VPN や仮想アダプタツールとの競合

デバイス上で企業用 VPN クライアント、一部のセキュリティソフトが内蔵するネットワークフィルタードライバー、あるいは別のプロキシツールの TUN コンポーネントが同時に動作している場合、複数の仮想アダプタがルーティングの優先度を奪い合うことになります。典型的な症状は、TUN を有効にした後ネットワークが断続的になる、または一部の通信が想定した経路を迂回するというものです。対処法としては、まず他の仮想ネットワークコンポーネントを停止し、一つだけを動かした状態で Clash の TUN が単独で正常に動作することを確認してから、両者を共存させる必要があるか、その場合どうルーティング優先度を調整するかを検討します。

DNS 解決の異常

TUN モードを有効にした後、ドメイン名解決が依然としてシステム本来の DNS を経由し Clash コアを通っていない場合、ドメインが誤ったアドレスへハイジャックされたり、ルール内のドメイン名マッチング項目が無効になったりする可能性があります。この場合は通常、設定内で DNS 制御に関する項目も同時に有効にし、解決リクエストをコアが一括処理する形にする必要があります。通信面だけ捕捉されて、解決面は依然システム標準の DNS を使っている、という状態を避けるためです。

仮想アダプタの作成失敗

Windows では、ドライバーが正しくインストールされていない、または権限不足であることが多い原因です。macOS では、特権付きヘルパーツールがシステムのセキュリティポリシーによってブロックされていることが多い原因です。Linux では、権限(ケーパビリティ)が正しく設定されていないことが多い原因です。切り分けの順序としては、まずクライアントが十分な権限で実行されているか確認し、次にシステムログやクライアントログに明確なドライバーまたは権限エラーがないか確認し、最後に同名の仮想ネットワークインターフェースを他のプログラムが占有していないか確認することを推奨します。

一部のアプリが依然として捕捉されない

ごく一部のアプリはシステムルーティングテーブルを迂回し、独自にネットワークインターフェースを指定してデータを送信することがあり、この場合は TUN モードでもカバーできません。これはアプリ自体の実装方式によるもので、設定ミスではありません。特定のアプリがどのモードでも制御できないことを確認した場合は、そのアプリ自身のネットワーク設定に独立したプロキシや直接接続のオプションがあるか確認してください。

DOC-06

TUN モードは常時オンにすべきか

TUN モードの適用範囲はより完全ですが、それはシステム層にもう一段階のルーティング書き換えが加わることを意味し、問題発生時の切り分け経路も長くなります。日常的にブラウザだけでネットを使い、振り分けの精密さをそれほど求めない場面では、システムプロキシモードで十分に要件を満たせ、設定も簡単で競合の可能性も低いです。ゲームクライアント、コマンドラインツール、バックグラウンドサービスなど、システムプロキシ設定に対応しない場面をカバーする必要がある場合は、TUN モードがより確実な選択になります。

両者は排他的なものではなく、大半のクライアントはいつでも切り替えが可能です。現在の使用シーンに応じて柔軟にオン・オフを切り替えればよく、一つのモードに固定して長期間使い続ける必要はありません。