#TUNモードとシステムプロキシの違い:通信捕捉レベル・互換性の差・選び方

システムプロキシの仕組み:アプリケーション層の自発的な協調

システムプロキシとは本質的にOSが提供する環境変数やレジストリ項目であり、「HTTP通信をどのアドレス・ポートに送るか」を記録している。Clash系クライアントでシステムプロキシを有効にすると、この設定は自身がリスンしている port(HTTP)や socks-port(SOCKS5)に向けられ、ブラウザやネットワーク設定を持つ大半のアプリはリクエスト送信前にこれらの値を読み取り、自ら接続をClashのリスンポートに向けて張る。そのうえでClashがルールに従って振り分ける。

この仕組みのキーワードは「自発的」だ。アプリが自らプロキシ設定を読み取り、それに従うことに依存している。もし何らかのプログラムがシステムプロキシを読み取らない場合(古いバージョンのJavaプログラム、一部のゲームクライアント、環境変数を無視するデフォルト動作のCLIツールなど)、その通信は物理ネットワークカードから直接外に出てしまい、Clashのルール判定を完全にすり抜ける。これはClash側の欠陥ではなく、システムプロキシという接管方式そのものの限界であり、「協調してくれる」プロセスしか制御できない。

TUNモードの仕組み:ネットワーク層の仮想ネットワークカード

TUNモードの発想はまったく異なり、アプリケーション層で説得する作業をせず、OSのネットワーク層に直接仮想ネットワークインターフェース(virtual network interface)を挿入する。有効化すると、Clash Meta(mihomoコア)は utun(macOS)、Metaあるいは類似の名前(Windows/Linux)を持つ仮想ネットワークカードを作成し、システムのルーティングテーブルを書き換えて、デフォルトルートまたは一部サブネットの通信をこの仮想NICへ向ける。

これ以降、OS層から見えるのは「あるアプリがプロキシを使うかどうか」ではなく、「このパケットがどのネットワークカードから出ていくべきか」――これはカーネルのルーティング層の判断であり、アプリがプロキシを意識しているかどうかとは無関係になる。パケットが仮想NICに入ると、mihomoコアがユーザー空間でTCP/UDPセッションとして解析・復元し、プロキシルールに従って転送処理を行う。判断ポイントがネットワーク層まで下がったことで、ほぼすべてのプロセスが生成する通信がこの仮想NICに捕捉され、「あるプログラムだけ従わない」という問題が起こらない。

# config.yamlでTUNモードを有効にする基本フィールド
tun:
  enable: true
  stack: system   # system / gvisor / mixed から選択可
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

ここで stack は仮想ネットワークカードの実装方式を決める:system はOS標準のTUN/TAPドライバを使い、性能は良好だがOSのバージョンに一定の要件がある。gvisor はユーザー空間のネットワークスタックで、互換性は高いがスループットはやや低い。mixed は比較的新しいカーネルが提供する折衷案だ。auto-route はルーティングテーブルへの自動書き込みを担い、無効にすると手動でルート設定が必要になるため、上級者以外は有効のままにすることを推奨する。

両者の対応範囲と互換性の差

対応範囲について、システムプロキシは自らプロキシ設定を読み取るプロセスしか制御できず、代表例はブラウザや大半のデスクトップアプリのネットワークリクエストだ。一方でシステムサービス、一部のバックグラウンドプロセス、CLIツール、ゲームクライアントのネットワークモジュールはシステムプロキシを読み取らないことが多く、通信は直接迂回してしまう。TUNモードはルーティング層で動作するため、理論上「プロキシを認識しない」プロセスを含め、IPプロトコルスタックに基づくすべての通信を捕捉できる。

ただし対応範囲が広いことは互換性のコストがないことを意味しない。以下のような場面には注意が必要だ。

• 仮想マシン・コンテナのネットワーク:仮想マシンがNATまたはブリッジ接続を使っている場合、その通信経路がホスト側のTUNルーティングテーブルと衝突し、仮想マシンが通信不能になったり誤った経路を通ったりすることがある。通常は route-exclude-address に仮想マシンのサブネットを除外設定する必要がある。
• ローカルネットワークへのアクセス:TUN有効時にLAN内のプリンター、NAS、ルーター管理画面にアクセスする際、直接接続ルールやローカルセグメントの例外を正しく設定していないと、プロキシ転送が必要と誤判定されアクセス失敗が起こりうる。
• VPNソフトとの併用:2つの仮想ネットワークカードが同時にデフォルトルートを取り合い、互いを上書きしたり切断したりしやすい。一般にシステムレベルのVPNとClashのTUNモードを同時に有効にすることは推奨されない。
• 管理者/システム権限が必要:仮想ネットワークカードの作成やルーティングテーブルの変更はシステムレベルの操作であり、TUNモードはWindowsでは管理者権限での実行が必要、macOS/Linuxでは通常 sudo または対応する権限付与フローが必要になる。この点はシステムプロキシの「スイッチひとつでON」とは異なる。

それに対しシステムプロキシはルーティングテーブルや仮想ネットワークカードに関与しないため、基本的に仮想マシンや他のVPNと衝突せず、必要な権限も少ない。これが互換性の面での強みで、問題はあくまで「カバーしきれない」点だけだ。

性能コストと安定性の比較

システムプロキシの転送経路は比較的短い:アプリがClashのリスンポートへ直接接続し、Clashがルール判定後に目的サーバーへ転送する。中間を通るのはユーザー空間のプロキシ処理一回のみで、コストの大半はルールマッチングと暗号化・復号によるもので、大半の帯域環境への影響は小さい。

TUNモードには「ネットワーク層での捕捉+プロトコル復元」という工程が一段追加される:パケットはまず仮想NICに入り、カーネルのネットワークスタックが処理した後にmihomoのユーザー空間プログラムに渡されて完全なTCP/UDPセッションとして解析され、そこからさらにプロキシルールと転送処理を通る。この過程はシステムプロキシよりカーネル空間とユーザー空間の間のデータコピーが一回多く、理論上わずかな遅延とCPU使用率の増加を招く。具体的な幅は stack の選択に関係し、system スタックは通常 gvisor よりシステムプロキシの性能水準に近い。一般的なウェブ閲覧や動画視聴などの場面ではこの差はほぼ感知できないが、小さなパケットが大量に発生する場面や高並列接続の場面(一部のダウンロードツールやブロックチェーンノードの同期など)では差がより顕著になる。

安定性については、システムプロキシで問題が起きると通常「特定のアプリだけプロキシを通っていない」という形で現れ、影響範囲が限定的で特定しやすい。TUNモードで問題が起きるとルーティングテーブルの異常による広範囲の通信断として現れることがあり、回復手段はTUNを無効にするかネットワークサービスを再起動することで、切り分けコストは相対的に高い。これが多くのクライアントがTUNモードを「詳細設定」に配置し、デフォルトで有効にしない理由でもある。

CLIツール・ゲーム・UWPアプリでの選び方

アプリの種類によってプロキシ設定への対応度は大きく異なる。以下は典型的な場面ごとの目安だ。

CLIツール(curl、git、パッケージマネージャーなど)

大半のCLIツールはデフォルトでシステムプロキシを読み取らず、明示的に設定された環境変数に依存する。例えば:

export http_proxy="http://127.0.0.1:7890"
export https_proxy="http://127.0.0.1:7890"

ツールごとに環境変数を設定するのが煩わしい場合、あるいはツール自体が環境変数さえ認識しない場合(一部のGo/Rustで静的にビルドされたツール)、TUNモードを有効にする方が手間が少ない――ツールごとの個別設定が不要になり、仮想NICが一括で捕捉してくれる。

ゲームクライアント

多くのゲームはランチャーと本体が別プロセスに分かれており、大量のUDP通信を使う(特に対戦系ゲームのリアルタイム同期データ)。システムプロキシのUDP対応は限定的で、多くの場合ランチャーのログイン段階までしかプロキシできず、対局に入った後の通信は物理ネットワークカードのままになる。対局中の通信もルールに従って振り分けたい場合(専用ノードで低遅延化したいなど)、TUNモードがほぼ唯一の確実な方法になる。ネットワーク層でTCPとUDPを一括捕捉できるためだ。ゲームアクセラレーション用のノードは事前にルールで専用グループに分けておき、動画やダウンロードなど大容量通信のルールグループに帯域を奪われないよう注意する必要がある。

UWPアプリ(Windowsストアアプリ)

Windows上のUWPアプリは独立したネットワーク隔離コンテナ(Network Isolation)内で動作し、デフォルトではシステムプロキシを読み取らず、TUNモードの通常のルーティング捕捉範囲にも入らない。これはWindowsのシステム設計によるサンドボックス隔離であり、Clashクライアント側の不備ではない。UWPアプリ(一部のストア版ブラウザやチャットツールなど)もプロキシ経由にしたい場合、通常は CheckNetIsolation.exe 関連のコマンドで当該アプリのネットワーク隔離を解除するか、クライアント側で「UWPアプリのループバック/ネットワークアクセスを許可」といったスイッチを探す必要がある。この手順はシステムプロキシとTUNモードのどちらでも個別対応が必要で、どちらかが自然に対応しているわけではない。

どう選ぶか:簡単な判断の流れ

日常的な用途がブラウザや一般的なデスクトップアプリに集中している場合、システムプロキシで大半の場面はカバーできる。設定が簡単で問題の切り分けもしやすく、より手間の少ないデフォルトの選択肢だ。以下のいずれかに当てはまる場合はTUNモードへの切り替えを検討する:CLIツールで頻繁にプロキシが必要だが環境変数をいちいち設定したくない、ゲームや音声通話などのUDP通信をルールで振り分けたい、あるプロセスが明確にシステムプロキシを読み取らずルールが機能していない。切り替え前には、仮想マシンや他のVPNソフトが仮想ネットワークカードとルーティング上で衝突しないか確認し、クライアント内のLAN直接接続ルールが正しく設定されているかチェックしておくと、有効化後に内部ネットワーク機器へのアクセスが異常になる事態を避けられる。