2つの通信引き受け方式の本質的な違い
Clash クライアント(および mihomo コア)は、通信を引き受ける方法として大きく異なる2つの仕組みを備えています。システムプロキシと TUN モードです。両者は「効果がほぼ同じ2つのスイッチ」として扱われがちですが、OSレベルでの動作原理は全く異なり、この違いがどの通信がプロキシを通り、どれが漏れるかを直接左右します。
システムプロキシは、OSやブラウザのプロキシ設定項目を書き換え、プロキシプロトコルに対応するアプリケーションに「HTTP/HTTPS リクエストはこのアドレスとポートへ送ってください」と伝える方式です。これはアプリケーション層での取り決めであり、各プログラムが自らこの設定を読み取り、遵守することに依存します。Windows の「ネットワークとインターネットの設定」、macOS の「ネットワーク環境設定」、Linux デスクトップ環境のプロキシ項目は、いずれも本質的には照会可能な設定を書き込むだけで、プログラム側がそれを読み取って使うかどうかを自分で判断します。
一方 TUN モードは全く異なり、OSカーネルレベルで仮想ネットワークインターフェース(virtual network interface)を作成し、システムにネットワークアダプタが1枚増えたと認識させます。その上で Clash はルーティングテーブルやファイアウォールのルールを使い、デバイス上のほぼ全てのアウトバウンド通信をこの仮想アダプタへ誘導し、mihomo コアがユーザー空間でこれらの生のIPパケットを解析し、具体的な接続要求に復元してからルールに従って転送します。この方式はネットワーク層で動作し、アプリケーションが「協力的」かどうかに依存しない、より低レイヤーな通信ハイジャック機構です。
システムプロキシで通信が漏れる理由
システムプロキシの根本的な限界は、それが「自発的な遵守」機構であり、強制的な引き受けではない点にあります。これにより、実際に遭遇しやすい漏れのパターンがいくつか生まれます。
システムプロキシ設定を読み取らないプログラム
多くのコマンドラインツール、バックグラウンドサービス、一部のデスクトップアプリケーションはシステムプロキシの設定を自ら照会せず、直接 TCP 接続を確立します。よくある例として curl、git、ssh、プロキシを明示的に設定していない一部のパッケージマネージャー(pip、npm など)、Electron アプリ以外の多くのネイティブクライアントが挙げられます。これらのプログラムが発するリクエストは Clash を直接迂回し、端末のデフォルトのネットワーク経路をそのまま通ります。
UDP通信は基本的にシステムプロキシの制約を受けない
システムプロキシの設定は本質的に HTTP/HTTPS のような TCP ベースのリクエストを想定したものであり、OSレベルには統一された「UDP用システムプロキシ」という概念が存在しません。つまり、UDP に依存するアプリケーション──多くのオンラインゲームのリアルタイム同期通信、QUIC(HTTP/3)ベースのウェブリクエスト、一部のビデオ通話ソフト、DNSクエリ自体など──は、システムプロキシモードでは Clash を全く経由しないことが多くなります。プロキシノード自体が UDP 転送(Shadowsocks や一部の Trojan 実装など)に対応していても、システムプロキシモードではその機能は使われません。
ゲームクライアントの特殊性
ゲームはネットワーク遅延に極めて敏感で、多くのゲームエンジンは低レイヤーの socket インターフェースを直接呼び出して接続を確立し、システムプロキシを照会することもほとんどなく、アプリケーション層のプロキシプロトコルに対応することもまずありません。ゲーム通信をプロキシ経由にしたい場合、ほぼネットワーク層での引き受け方式に依存するしかなく、システムプロキシはこの場面ではほとんど効果がありません。
システムプロキシモードで「一部のサイトにはアクセスできるが、一部は繋がらない」という現象は、多くの場合ノードやルールの問題ではなく、そのプログラム自体がシステムプロキシ設定に従っていない、またはシステムプロキシの管轄外である UDP 経路を使っていることが原因です。トラブルシューティングの前に問題のあるプログラムのネットワーク実装方式を確認しておくと、ノードを何度も切り替える手間を省けます。
TUN モードがどのように全域を引き受けるか
TUN モードの引き受け範囲は明らかに広く、原理上システムプロキシで漏れがちなほとんどの場面をカバーします。これはアプリケーション層ではなくネットワーク層で動作するためです。
- プログラムの協力に依存しない。仮想ネットワークアダプタとルーティングテーブルの組み合わせにより、インターネットへ送られる全てのパケットはデフォルトでこの仮想インターフェースを経由します。接続を開始するプログラムがプロキシの存在を「認識」しているかどうかに関わらず機能するため、コマンドラインツールやプロキシ設定に対応していないプログラムにとって特に重要です。
- UDP をネイティブにサポート。mihomo コアは TUN 通信を処理する際に UDP パケットを解析しルールに従って転送するため、選択したプロキシノードが対応プロトコルでの UDP 転送に対応していれば、ゲーム、音声通話、QUIC リクエストも正常にプロキシされ、システムプロキシモードの盲点ではなくなります。
- 端末上の全ネットワークインターフェースに対して有効。仮想マシン、コンテナ、一部の開発環境が発する通信も、最終的にシステムのデフォルトルートを経由する限り TUN アダプタに捕捉されるため、アプリケーションごとにプロキシを設定するよりも網羅性が高くなります。
ただし、TUN モードは「設定不要の万能スイッチ」ではない点に注意が必要です。OSレベルの権限に依存しており、Windows では仮想ネットワークアダプタの作成とルーティングテーブルの変更のために管理者権限での実行が必要、macOS と Linux では通常カーネル拡張のインストールや特定のネットワーク拡張フレームワークの利用と、それに応じた権限の付与が必要です。一部のクライアント(Clash Verge Rev、FlClash など)では設定画面に「サービスモード」や「TUN モード」のスイッチが用意されており、有効化前に権限の許可を求めるプロンプトが表示されるのが通常の流れであり、エラーではありません。
両モードの実際の違いの比較
| 比較項目 | システムプロキシ | TUN モード |
|---|---|---|
| 動作レイヤー | アプリケーション層(プログラムが設定を自ら読み取る必要あり) | ネットワーク層(仮想ネットワークアダプタ + ルーティングテーブル) |
| コマンドラインツールの網羅性 | ツールがプロキシ環境変数を読み取るかどうかに依存 | デフォルトで全て網羅 |
| UDP / ゲーム通信 | 一般的に非対応 | 対応(ノードのプロトコル対応状況に依存) |
| 必要な権限 | 一般ユーザー権限で十分 | 管理者/root権限またはシステムのネットワーク拡張の許可が必要 |
| 導入コスト | 低く、スイッチ一つで利用可能 | やや高く、初回の権限設定が必要 |
| ローカルネットワークツールとの互換性 | 基本的に競合なし | 一部の仮想マシンネットワークやVPNクライアントとルーティングが競合する可能性あり |
どう選ぶか:場面に応じた判断基準
どちらが絶対的に優れているというものではなく、実際の利用場面に基づいて選ぶべきです。以下は典型的な判断パターンです。
普段のウェブ閲覧やオフィスソフトから外部サービスへのアクセスだけの場合
システムプロキシで十分です。ブラウザや大多数のオフィス系クライアントはシステムプロキシの設定に従うため、TUN モード導入に伴う追加の権限設定や潜在的なルーティング競合のリスクを負う必要はありません。これは多くのクライアントで初期設定として採用されているモードでもあります。
ターミナルで git、curl、パッケージマネージャーなどのツールを使う必要がある場合
TUN モードを優先的に検討するか、これらのツール向けに個別にプロキシ環境変数を設定します(例:HTTP_PROXY/HTTPS_PROXY 環境変数を Clash の Mixed ポートに向ける)。後者の方が軽量ですが、ツールごとに設定が必要で、TUN モードで一括対応するほどの効率はありません。
海外サーバーに接続する必要があるオンラインゲームをプレイする場合
基本的に TUN モードに依存するしかありません。ゲーム通信は主に UDP であり、システムプロキシ設定を読み取らないため、システムプロキシモードではゲーム接続にほとんど効果がなく、コミュニティで見られる「プロキシを有効にしてもゲームが繋がらない」という現象の一因でもあります。
業務用パソコンやシステム権限の変更に懸念がある環境
システムプロキシの利用を推奨します。TUN モードはより高いシステム権限を必要とし、ルーティングテーブルを変更するため、管理下にある業務用デバイスで有効化する前に、所属組織のデバイス利用規定に適合するか確認する必要があります。
主要なクライアント(Clash Verge Rev、FlClash、Clash Plus など)はいずれも設定画面から直接システムプロキシと TUN モードを切り替えられ、設定ファイルのフィールドを手動で編集する必要はありません。初回に TUN モードを有効化する際は表示に従って一度だけ権限の許可を完了すれば、以降の切り替えは単なるスイッチ操作になります。
併用に関する補足
一部のユーザーはシステムプロキシと TUN モードを同時に有効化しますが、理論上は競合しないものの、実質的な意味は限られます。TUN モードが有効になると、ほぼ全ての通信は既にルーティングテーブルによって仮想アダプタへ誘導されているため、システムプロキシの設定はほとんどトリガーされなくなります。同時に有効化するのは心理的な「二重の安心感」に過ぎず、追加のカバー範囲は生まれません。
また、TUN モードは一部の VPN クライアントや仮想マシン向けデスクトップソフトのネットワークアダプタとルーティングテーブルを取り合う可能性がある点にも注意が必要です。TUN モードを有効化した後に仮想マシンのネットワークが異常になったり、別の VPN 接続が機能しなくなったりした場合、通常はルーティングの優先度の競合が原因であり、設定内で TUN のルートメトリック(metric)を調整するか、競合している一方を一時的に無効化して問題を特定すればよく、Clash 自体の不具合を疑う必要はありません。
どちらのモードを選ぶにしても、ポリシーグループ、プロキシノード、振り分けルールの設定ロジックは共通です。TUN モードが変えるのは「通信がどのように Clash に渡されるか」だけであり、その後のルール判定、ノード選択、転送という処理チェーンはシステムプロキシモードと完全に同一です。この点を理解すれば、両モード間の切り替えは単に引き受け方式を選ぶだけのことであり、新たにルール体系を学び直す必要はありません。