Clash TUN モードとシステムプロキシの違い:通信の横取り方式を徹底比較

まずは2つの横取り方式の仕組みを理解する

Clashを使い始める前に、ネットワーク通信がどのようにしてプロキシへ「横取り」されるのかを理解しておくことは、個々のスイッチ名を覚えるよりもはるかに重要です。Clashおよびその派生コアであるClash Meta(mihomo)は、まったく異なる2つのアプローチを用意しています。1つは「システムプロキシ」、もう1つは「TUNモード」です。両者が解決しようとしている課題は同じ——デバイスから送信される通信をClashのルールエンジンに通してから転送する——ですが、介入する階層が根本的に異なり、それが適用範囲・互換性・設定コストの差につながっています。

システムプロキシはOSレベルで提供される設定インターフェースで、本質的には「対応するアプリへ、まずこのアドレスとポートにHTTP/HTTPSリクエストを送るように」指示する仕組みです。WindowsやmacOSには標準でシステムプロキシの設定項目があり、ブラウザや一部のダウンロードツール、IDEのネットワークコンポーネントがこの設定を読み取って動作します。一方、TUNモードは発想がまったく異なります。システム内部に仮想ネットワークインターフェース(Virtual Network Interface)を作成し、OSはこの仮想アダプタを実際のネットワーク出口として扱います。ルーティングテーブルの判定によりこの出口を経由すべきと判断されたIPパケットは、送信元のプロセスや使用プロトコルを問わず、まずこの仮想アダプタに流れ込み、その後Clashコアが解析・ルール照合を行い、対応するノードへ転送します。

システムプロキシ:軽量だが構造上どうしても穴がある

システムプロキシの利点は設定が簡単で、リソース消費が少なく、オン/オフの切り替えも柔軟なことです。Clashに初めて触れるユーザーの多くはまずこの方式から使い始めます。ただしその仕組みは、アプリケーション側が積極的に「協力」することを前提としています。アプリ内部がシステムや環境変数からプロキシアドレスを読み取り、自らそのアドレスに接続してリクエストを転送する必要があるのです。つまり、この約束事に従うアプリだけが正しく横取りされる仕組みです。

問題はまさにここにあります。すべてのネットワーク通信を行うアプリがシステムプロキシ設定を読み取るわけではなく、代表的な迂回パターンとしては以下が挙げられます。

• 一部のコマンドラインツールやバックグラウンドサービスはシステムプロキシの環境変数を読み取らず、HTTP_PROXY/HTTPS_PROXYを別途手動で設定する必要があります。
• 一部のアプリはハードコードされた直接接続ロジックや非標準ポートでの通信を採用しており、システムプロキシの設定が一切効きません。
• UDPプロトコルの通信(一部のリアルタイム通信やゲーム加速のシーンなど)は、システムプロキシの対象範囲外になることが多く、システムプロキシは主にTCPベースのHTTP/HTTPSリクエストを想定した設計です。
• モバイル向けアプリの実装はより分散しており、多くのアプリがOSの下位ネットワークライブラリを直接呼び出して接続するため、アプリ層のプロキシ設定を素通りしてしまいます。

つまり、システムプロキシは一種の「紳士協定」のようなものです。協力的なアプリは素直にプロキシ経由で通信しますが、協力しないアプリはそのまま直接通信を続けます。Clashを起動しているのに、あるクライアントで「プロキシに接続されていません」と表示されたり、想定と異なる結果になったりするのは、多くの場合ルール設定が間違っているのではなく、そのアプリがそもそもシステムプロキシの経路を通っていないことが原因です。

TUNモード:ネットワーク層で一括横取り

TUNモードの発想はより徹底しています。アプリが「協力する意思」を持っているかどうかに依存せず、OSのネットワークプロトコルスタック層に仮想ネットワークアダプタを差し込み、ルーティングテーブルの規則と組み合わせて、デバイス上のほぼすべての対象IPパケットをこの仮想インターフェースへ誘導します。パケットが仮想アダプタに入った後、Clash Meta(mihomo)コアがユーザー空間でプロトコル解析(一般的にはgVisorまたはOS標準スタックのいずれかの実装方式)、ドメイン照合、ルール判定を行い、どのノード経由にするか、あるいは直接接続にするかを決定します。

横取りがアプリ層ではなくネットワーク層で行われるため、TUNモードはアプリの種類をほとんど選びません。ブラウザ、コマンドラインツール、ゲームクライアント、OS自体のバックグラウンドサービスであっても、ルーティング条件に合致する通信であればすべて一括で管理対象となり、システムプロキシでは扱えなかったUDP通信も含まれます。ゲームや音声通信、クロスプラットフォームクライアントを細かく振り分けたいユーザーが最終的にTUNモードへ移行するのはこのためです。

互換性と安定性の実際の差

適用範囲が広いことは、TUNモードにコストがないことを意味しません。通信がネットワーク層で捕捉され、ユーザー空間のプロトコルスタックで処理されてから転送されるため、パケットが経由する封装・解析の層が増え、理論上はわずかな性能オーバーヘッドが発生します。低性能なデバイスや遅延に極めて敏感な用途では差を感じる場合があります。また、仮想アダプタは端末のルーティングテーブル、ファイアウォール設定、VPNクライアントと相互に影響し合う可能性があります。

• 同じ端末で他のVPNソフトや仮想ネットワークツールを併用している場合、ルーティングテーブルが競合し、一部通信が想定外の経路をたどることがあります。複数の仮想アダプタ系ツールを同時に有効化しないことを推奨します。
• 企業内ネットワークや一部のセキュリティソフトは、新たに追加された仮想ネットワークインターフェースを検知してブロックや警告を出すことがあります。TUNモードを初めて有効にする前に、利用しているネットワーク環境のポリシーを確認しておくとよいでしょう。
• OSごとにTUNデバイスの実装は異なり、WindowsはWintunドライバ、macOSはNetwork Extensionフレームワークを利用します。設定画面や権限申請の方法には多少の差がありますが、エンドユーザーが操作するオン/オフの体験自体はほぼ同じです。

対照的に、システムプロキシにはこうした低レベルのリスクがなく、設定すれば即時に反映され、無効化すれば即時に元に戻ります。不具合が起きた際の調査も分かりやすく、多くの場合「どのアプリがプロキシ設定を読み取っていないか」に行き着きます。これが、軽量な用途では今もシステムプロキシが標準的な選択肢である理由です。

適用範囲の比較一覧

システムプロキシを迂回しやすいアプリの例

あるアプリの通信がいつもプロキシルールに従わない場合、おおむね以下のいずれかに該当します。

1. コマンドラインツールや開発ツール:パッケージマネージャーやビルドツールなど、標準ではシステムプロキシを読み取らないものが多く、環境変数やツール独自のプロキシ設定を個別に行う必要があります。
2. 独自のネットワークスタックを持つクライアント:チャットアプリやクラウドストレージ同期系のソフトの一部は、接続速度を優先して独自にネットワーク処理を実装しており、システムプロキシのインターフェースを経由しません。
3. ゲームや音声通信:多くのゲームはリアルタイム通信にUDPを使用しますが、システムプロキシのUDP対応は総じて弱いか対応していません。この種の通信は基本的にTUNモードでしか横取りできません。
4. OSのバックグラウンドサービスや更新機能:OS自体の更新チェックやテレメトリ送信といったバックグラウンド処理は、通常ユーザーが設定したプロキシを経由しません。

このような問題に遭遇したときは、アプリごとにプロキシ設定の入り口を探すよりも、TUNモードへ切り替えてネットワーク層で一括対応してしまう方が「横取り漏れ」を効率的に解決できます。

TUNモードへ切り替えるべき場面

以上の比較を踏まえると、次のような判断基準が導けます。

• 日常的なWebブラウジングや、少数のアプリのプロキシ利用だけで十分な場合は、システムプロキシで足ります。設定の手間も少なく済みます。
• システムプロキシの約束事に従わないアプリ(コマンドラインツール、ゲーム、一部のチャットアプリなど)を多く使っている場合や、UDP通信をルールで振り分けたい場合は、TUNモードのほうが根本的な解決策になります。
• プロセス単位で細かく振り分けたい場合(特定のアプリだけ直接接続にし、それ以外はプロキシ経由にするなど)、TUNモードとClash Meta(mihomo)のプロセスルール(process-name)を組み合わせることで、アプリ層では実現できない粒度の制御が可能になります。
• 企業ネットワークやセキュリティソフトの制約が厳しい環境では、仮想アダプタがブロックされないかを事前に確認したうえでTUNモードの有効化を判断し、業務用ネットワークへの影響を避けることを推奨します。

設定ファイル上の実際の違い

設定ファイルの観点で見ると、システムプロキシはClashの設定に特別な記述を追加する必要がなく、クライアント画面上のスイッチひとつでOSのAPIを直接呼び出して完了します。一方TUNモードは、通常設定ファイル内で有効状態・スタックの種類・DNSを横取りするかどうかなどの項目を明示的に指定する必要があります。Clash Meta(mihomo)の一般的な記述例は次の通りです。

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
  auto-route: true
  auto-detect-interface: true

auto-routeは通信を仮想アダプタへ誘導するルーティングテーブルを自動設定するかどうかを決め、dns-hijackはDNSクエリを横取りして、一部のドメイン名解決がルール照合を迂回してしまうのを防ぎます。これらの項目はほとんどのGUIクライアントで画面上の簡単なスイッチとして実装されており、通常のユーザーが設定ファイルを直接編集する必要はありませんが、意味を理解しておくと稀に発生する接続不具合の調査に役立ちます。

よくある質問

TUNモードを有効にしたら、システムプロキシも必要ですか?基本的に同時に有効にする必要はありません。TUNモードはシステムプロキシが処理できる範囲をすでに包含しており、両方同時に有効にするとルーティング判定が混乱しやすいため、どちらか一方を選ぶことを推奨します。

TUNモードにすると全体の速度が遅くなりますか?封装・解析の分だけオーバーヘッドは確かに存在しますが、現行の多くの端末ではその差はほとんど感じられません。速度差の多くは接続方式そのものよりも、利用しているプロキシノードの回線品質に起因します。

スマートフォンにもTUNモードはありますか?Androidでは通常VpnServiceインターフェースを通じて同様の効果を実現しており、考え方はデスクトップの仮想アダプタと同じで、アプリ層で処理できない通信も横取りできます。iOSではNetwork Extensionフレームワークによって同種の機能が実現されています。