TUN モードとシステムプロキシの違い:通信の乗っ取り方式を層ごとに解説

まず動作レイヤーを見分ける:どこで何を横取りしているか

違いを理解するには、まずアプリが送り出したリクエストが実際に通信されるまでにいくつの層を通るかを知る必要がある。システムプロキシとTUNモードが乗っ取るのは同じ層ではなく、これが挙動差の根本原因になっている。

システムプロキシはアプリケーション層で動作する。OSは「プロキシ設定」というインターフェースを用意し、ブラウザや一部のターミナルツール、デスクトップアプリがこの設定を読み取って、自分の通信を指定したプロキシポートへ自主的に転送する。転送処理はあくまでアプリ側の実装で、OSは設定値を保持し、参照したいプログラムに渡すだけだ。

TUNモードはネットワーク層、より正確にはIPパケットのレベルで動作する。Clash Meta(mihomo)がTUNを有効化すると、システム内に仮想ネットワークインターフェースを作成し、ルーティングテーブルを書き換えてデフォルトルートをこの仮想NICへ向ける。以降、IPプロトコルで送出されるすべてのパケットは、送信元プロセスを問わず、まずこの仮想NICを経由してカーネルからClashへ渡され、ルールに従って直接接続かプロキシノード経由かが決定される。

一言でまとめると、システムプロキシは「設定は用意されているが読むかどうかはアプリ次第」、TUNは「ルートそのものを変えるので、パケットは避けて通れない」。

システムプロキシ:アプリ側の協力に依存する委任方式

システムプロキシの実装方法はOSによって多少異なるが、基本ロジックは共通している。

• Windows / macOS のGUI設定——OSがグローバルなプロキシ設定項目を提供し、Clashクライアントで「システムプロキシとして設定」を有効にすると、この設定値がシステム環境設定に書き込まれ、主要ブラウザや多くの現行アプリがデフォルトで参照する。
• コマンドライン端末——参照するのは http_proxy、https_proxy といった環境変数で、システム側のプロキシ設定はターミナルには反映されないことが多く、個別にexportする必要がある。
• PACスクリプト——一部のクライアントはPAC(Proxy Auto-Config)ファイルを使い、ドメインごとにプロキシを経由するか動的に判定する。ブラウザがこのスクリプトを読み込み、ルールに従って経路を決める。

この仕組みは「アプリ側が協力してくれる」ことが前提だ。プログラム内部に接続先が直接埋め込まれていたり、そもそもシステムプロキシの設定を確認しない実装(一部のゲーム、更新サービス、バックグラウンドデーモンでよく見られる)の場合、システムプロキシは効かず、通信はそのまま直接外へ出ていく。システムプロキシを有効にしてもブラウザは正常に振り分けられるのに、特定のクライアントソフトだけプロキシノードにつながらない——というのは、そのソフトが「素直に読んでくれる側」に入っていないからだ。

TUNモード:ネットワーク層に仮想NICを作り、全通信を横取り

TUNモードはアプリ側の協力を必要とせず、パケットがデバイスを出る前に必ず通る経路そのものを変える。有効化すると、おおむね次の流れで処理される。

1. Clash Meta(mihomo)のコアが仮想ネットワークインターフェース(utunやMetaなどの名前で作成されることが多い)を作成し、これはシステム上で実在のネットワークアダプタと同等に扱われる。
2. ローカルのルーティングテーブルを書き換え、デフォルトルート(または指定したセグメント)をこの仮想NICへ向ける。優先度は既存の物理NICのルートより高くなる。
3. カーネルがルーティングテーブルに従ってパケットを転送する際、デフォルトルートに一致した通信はまず仮想NICへ送られ、そこからClashプロセスが読み取り、解析し、ルールに従って処理する。
4. 処理後の通信はプロキシノードまたは直接接続の出口から送出され、応答パケットは元の経路を逆にたどって送信元プロセスへ戻る。プロセス自身はこの一連の転送処理をまったく意識しない。

乗っ取りがルーティング層で行われるため、IPプロトコルで通信するすべてのトラフィックが捕捉対象になる——ブラウザかコマンドラインツールかシステムのバックグラウンドサービスかを問わず、プロキシ設定への対応も不要だ。これこそがTUNモード最大の価値であり、「素直に言うことを聞かない」プロセスの通信を処理できる点にある。

その代償も明確だ。仮想NICはOSのネットワークスタック深部に関わるため、権限要件が高くなる(Windowsでは管理者権限での実行やドライバの許可が必要、macOSではシステム拡張やroot権限のヘルパーサービスが必要)。設定を誤った際のトラブル範囲も広く、ルーティングテーブルの競合、他のVPNソフトとのデフォルトルート争い、ファイアウォールによる仮想NIC通信の遮断など、TUNモード特有のトラブルシューティング項目がある。システムプロキシモードではほとんど発生しない類のものだ。

DNS処理:両者の差が最も大きい部分

DNS解決をプロキシ経由にするかローカルで済ませるかは、両方式の挙動差が最もはっきり出る部分であり、初心者が最も混乱しやすいポイントでもある。

システムプロキシモードでは、DNSリクエストは通常Clashを経由しない——横取りされるのはアプリが自発的に張るTCP/HTTP接続だけで、ドメイン解決自体は多くの場合端末に設定された既存のDNSサーバーで完了し、その結果を使ってプロキシへ接続する。つまりDNSクエリ自体はローカルの通信事業者に見えている可能性があり、さらにローカルDNSが汚染されていた場合、誤ったアドレスが解決されて接続失敗や誤ったサーバーへの接続が起きうる。

TUNモードでは、Clash Meta(mihomo)がDNSリクエスト自体を乗っ取れる。よく使われるのがfake-ipで、コアがドメインに対して一時的な偽のIPアドレス帯を割り当て、アプリはこの偽IPで接続を試みる。Clashはネットワーク層でこの接続がどのドメインに対応するかを識別し、ルールに従ってプロキシ経由か直接接続かを判定し、実際の名前解決はプロキシ側で行われる。これによりDNSクエリとその後の通信がすべてClashの管理下に入り、ドメイン汚染が判定結果に影響しにくくなる。

適用範囲の比較:どんな通信が漏れるか

実際の運用で最も聞かれる質問は「プロキシは有効なのに、一部の通信がプロキシを経由していない」というものだ。答えはどちらの方式を使っているかに大きく依存する。

システムプロキシモードで漏れやすい典型的なケース:

• コマンドラインツール(curl、git、パッケージマネージャーなど)はシステムプロキシを認識せず、環境変数しか見ないため、個別に設定しないと直接接続になる。
• 一部のデスクトップクライアント(チャットアプリ、ダウンローダー、ゲームのアップデーターなど)は独自のネットワークスタックを使い、システムプロキシ設定を確認しない。
• システムレベルのバックグラウンドサービス(自動更新、テレメトリ送信など)は、ユーザーレベルのプロキシ設定に縛られないことが多い。

TUNモードでは、上記のケースはほぼすべて捕捉対象になる。ルーティング層はプロセスの種類を区別しないためだ。しかしTUNモードにも独自の「漏れ」がある——ルールで特定のセグメント(LANなど)を直接接続に設定していたり、仮想NICのルート優先度が他のネットワークツール(一部のVPNクライアントや仮想マシンのNICなど)に奪われている場合、通信は同様にClashを回避する。この種の問題を調べる方向はルーティングテーブルとNICの優先度であり、アプリの設定ではない。

どちらを使うべきか:シーン別の選び方

「どちらが優れているか」ではなく「今の用途にどちらが合うか」で判断する。実用的な目安をいくつか挙げる。

• 普段はブラウザ中心で、たまに定番ツールを使う程度——システムプロキシで十分。設定がシンプルで、トラブル時の調査範囲も狭いため、まずこのモードから始めるのが手堅い。
• コマンドラインツール、ゲーム、バックグラウンドサービスなどプロキシ設定に対応していないプログラムも対象にしたい——TUNモードを使う。これこそがTUNモードの存在意義だ。
• すでに他のVPNを利用中、または仮想NICの競合トラブルの経験がある——まずルーティングテーブルを確認してからTUNの有効化を判断する。2つのネットワーク乗っ取り機構がデフォルトルートを奪い合うと接続が不安定になる。
• DNS汚染に敏感で、ドメイン解決の漏洩が気になる——TUNモード+fake-ipのほうが徹底している。システムプロキシの経路ではDNSクエリ自体を管理できない。

両モードは排他的なものではなく、多くのクライアントはいつでも切り替え可能だ。ある場面で挙動が異常な場合は、まず現在どちらの方式を使っているかを確認し、上の比較表に照らして原因を特定する方が、闇雲な再インストールやノード変更よりずっと効率的だ。