TUNモードとシステムプロキシの違い:2つのトラフィック制御方式を徹底比較
システムプロキシはアプリ側の設定読込に依存し、TUNは仮想NICでネットワーク層から全トラフィックを制御します。実装経路・カバー範囲・性能差を解説し、CLIツールやゲームでTUNが必要な理由を説明します。
2つの方式の本質的な違い
Clashクライアントには、トラフィックをプロキシ経由にする方法として「システムプロキシ(System Proxy)」と「TUNモード」の2つが用意されています。多くの人はこれを「どちらが便利か」という二択のスイッチのように扱いますが、実際は両者が完全に異なる階層で動作しており、解決している問題自体が違います。この階層の違いを理解すれば、あるアプリはプロキシ設定を変えても効かないのに、あるCLIツールはどう設定しても接続できない、という現象の理由が見えてきます。
システムプロキシはOSが提供する設定インターフェースで、実質的には「HTTP/HTTPSプロキシサーバーのアドレス」という1行の情報をシステムやブラウザに書き込むだけの仕組みです。これはアプリケーション層で動作します。つまり、その設定を読み込んで、指定されたアドレスにリクエストを転送する意思のあるプログラムだけがプロキシを経由し、その設定を読まないプログラムのトラフィックは元のネットワーク経路をそのまま通り、プロキシとは無関係のままです。
一方TUNモードは全く異なります。クライアントがシステム内に仮想NIC(Virtual Network Interface)を作成し、システムのルーティングテーブルを書き換えることで、デバイス上のほぼ全て、あるいは全ての送信トラフィックをまずこの仮想NICへ送り、そこからClashコアに処理させます。このプロセスはネットワーク層で発生するため、アプリ側の協力を一切必要としません。パケットが外部へ送出される限り、上位でどんなプログラムが何のプロトコルを使っていても、必ず仮想NICを経由します。
システムプロキシの動作経路と限界
システムプロキシの実装経路は3段階に分けられます。まずクライアントがHTTP/SOCKS混合ポート(Clashのデフォルトでよく使われるmixed-portは7890)を起動し、次にクライアントがこのポート情報をシステムやブラウザのプロキシ設定に書き込み、最後にアプリがネットワークリクエストを発行する際にこの設定を参照してリクエストを該当ポートへ転送します。この経路の要は3段目です——転送処理は「アプリ側の協力」によって成立するもので、システムが強制するものではありません。
ほとんどのGUIブラウザや一般的なデスクトップアプリはシステムプロキシ設定を正しく読み込むため、日常的なWebブラウジング、チャットツール、大部分のデスクトップソフトであればシステムプロキシモードで十分カバーできます。しかし明確な弱点もいくつかあります。
- システムプロキシ設定に従わないプログラムには影響しません。一部のCLIツール、一部のゲームクライアント、独自のネットワークライブラリで直接通信するアプリなどによく見られます。
- カバーするのはHTTP/HTTPSと一部のSOCKS通信のみで、UDPが中心のプロトコル(UDP依存のゲームや一部のビデオ通話など)には対応しません。プログラム自体がSOCKS5のUDP転送に対応していない限り無効です。
- PACやシステム層の設定項目に依存するため、OSごとに実装の細部が異なります。macOS、Windows、Linuxのデスクトップ環境ではプロキシ設定の入口が異なり、挙動にも差があります。
TUNモードがネットワーク層でトラフィックを制御する仕組み
TUNとはTunnel(トンネル)仮想ネットワークデバイスの略で、OSカーネルが提供するネットワークインターフェースの一種です。動作としては実際のNICとほぼ同じで、独自のIPアドレスを持ち、ルーティングテーブルから参照でき、ファイアウォールルールにもマッチします。違いは物理ハードウェアに接続していない点で、送受信されるパケットはユーザー空間のプログラム(ここではClash / Clash Metaコア)が読み取り処理します。
TUNモードを有効化すると、クライアントは次の3つを行います。仮想NICを作成して内部IPを割り当てる、システムのデフォルトルートまたは一部のルートをこの仮想NICへ向ける、この仮想NICから流入するパケットをカーネル内部で捕捉してプロキシルールに従い転送する。ルーティングレベルでトラフィックが仮想NICへ導かれている以上、システムのネットワークスタックを通じてリクエストを送るプログラムはすべてこの制御から逃れられません。「プロキシ」という概念を理解しているかどうかは関係ありません。これがTUNモードが「グローバルトラフィック制御」と呼ばれる理由です。
この階層の違いを直感的に示す設定例として、Clash Meta(mihomo)の設定ファイルにあるTUN関連のよくある記述を挙げます。
tun:
enable: true
stack: system
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: trueauto-routeはルーティングテーブルへのエントリ自動追加を担い、dns-hijackはDNSクエリもまとめてカーネル内で処理するよう乗っ取ります。これによって、トラフィックはプロキシを通っているのにDNS解決だけ本来の出口が露出してしまう、という事態を防げます。この2つが組み合わさって初めて「グローバル制御」の名に恥じない仕組みになります。システムプロキシモードはDNSクエリを乗っ取ることができず、これは両者のプライバシー面での実際の差でもあります。
CLIツールやゲームでTUNが必須になる理由
CLIツール(パッケージマネージャー、バージョン管理ツール、独自スクリプトなど)は多くの場合システムプロキシ設定を読み込まず、ユーザーが手動で--proxyパラメータを渡すか、HTTP_PROXY/HTTPS_PROXY環境変数を設定しない限り有効になりません。ツール側にそうしたパラメータの実装がなければ、システムプロキシ設定はそのツールにとって見えない存在であり、プロキシ経由で通信させる唯一の方法がTUNです。TUNはルーティング層のパケットを制御するため、ツールが「プロキシに協力する意思」を持っているかどうかは全く関係ないのです。
ゲームクライアントも似た状況ですが、理由はもう少し複雑です。
- 多くのゲームのネットワークモジュールは低レベルのsocket APIを直接呼び出して接続を確立し、システムやブラウザのプロキシ設定項目を完全に迂回します。
- 対戦通信、ボイスチャット、一部のリソースダウンロードでは大量にUDPが使われますが、システムプロキシが標準でカバーするHTTP/HTTPSのシーンではUDPサポートが限定的です。
- 一部のゲームクライアントはチート対策やネットワーク環境検知を行い、既知のシステムプロキシのポート特徴を直接ブロックしますが、仮想NICのようなシステム層のネットワークインターフェースには特別な処理をしません。
この3点が重なり、「システムプロキシを有効にしたのにゲームは直接接続のまま」という現象が頻発します。TUNモードに切り替えると、トラフィックは即座に正しく制御されます。これが、多くのクライアントがTUNモードを独立した項目として設け、チュートリアルでゲームやCLIのシーンではTUN優先を強調する理由です。
性能と安定性の差は事前に把握しておく
TUNモードはカバー範囲が広い一方、ユーザー空間とカーネル空間の間でのデータコピーと処理が一段増えるという代償があります。理論的にはシステムプロキシよりわずかに遅延やCPU使用率が増え、特にトラフィックが大きいシーン(大容量ファイルのダウンロード、4K動画など)では差を感知しやすくなります。システムプロキシは経路が短いため、軽量なシーンでは概して軽快に動作します。実際の使用でこの差を多くの人が意識することはありませんが、デバイスの性能が限られている場合や遅延に極めて敏感な場合(対戦系ゲームなど)は、個人で比較テストをしてからどちらを常用するか決めることをお勧めします。
また、TUNモードはシステムのルーティングテーブルを変更するため、稀に他のVPNソフト、仮想マシンのネットワーク、社内イントラネット用クライアントとルーティングが衝突することがあります。症状としては、有効化後にネットワークに全く接続できない、または一部のアドレスにしかアクセスできない、といった形で現れます。この場合はまず、ルーティングテーブルを変更する他のネットワークツールが同時に動作していないか確認し、どちらかを停止すれば大抵は問題が特定できます。システムプロキシはルーティングテーブルを変更しないため、こうした衝突は基本的に発生せず、互換性が安定しています。
どちらを選ぶべきか:適した使用シーン
「どちらが優れているか」で悩む必要はありません。両者はもともと異なるシーンのために設計されています。以下の考え方で選ぶとよいでしょう。
- 日常的なWebブラウジング、主要なチャットツールやデスクトップアプリの利用であれば、システムプロキシで十分です。経路が短く、リソース消費も少なくて済みます。
- CLIツール、SDK、パッケージマネージャーがネットワーク接続を必要とするのにシステムプロキシ設定を認識しない場合は、TUNを直接有効化しましょう。ツールごとにパラメータを探してプロキシを設定する手間が省けます。
- プロキシ経由が必要なゲームをプレイする場合、あるいはゲームがUDPを多用してシステムプロキシ下で遅延が異常な場合は、まずTUNを試してみましょう。
- あるアプリがプロキシ設定を迂回して直接接続していると疑われる場合は、まずシステムプロキシモードとパケットキャプチャツールを組み合わせて確認し、その上でTUNに切り替えて経路を完全に塞ぐかどうかを判断できます。
多くのクライアント(Clash Verge Rev、FlClash、Clash Nyanpasuなど)は設定画面でシステムプロキシとTUNモードを別々のスイッチにしており、両方を同時に有効化することも可能で、互いに干渉しません。ただし同時に有効化した場合、実際に制御を担う階層はTUN側が優先されます。クライアントをインストールしたばかりの場合は、まずデフォルトのシステムプロキシモードでノードやルールが正常に機能するか確認し、その後アプリごとの通信状況に応じて追加でTUNを有効化するかどうか判断することをお勧めします。