Clash TUNモードとシステムプロキシの違い：通信の取り込み範囲、DNS経路、適した用途

Clashクライアントの「システムプロキシ」と「TUNモード」は、2種類のルールモードではなく、最終的にどのノードへ接続するかを決めるものでもありません。解決するのは、アプリが生成した通信をClashまたはmihomoカーネルへどう取り込むかという、より手前の問題です。通信がカーネルに入った後、ドメインのスニッフィング、DNS、ルール照合、プロキシグループの選択、アウトバウンド接続へと進みます。

システムプロキシは、アプリとOSが提供するプロキシインターフェースの間で動作します。ブラウザーやシステムプロキシに対応したデスクトップアプリはプロキシアドレスを読み取り、リクエストをClashへ渡します。一方、TUNモードは仮想ネットワークインターフェースを作成し、システムルーティングによってIPパケットをカーネルへ送るため、プロキシ設定を持たないアプリもより広くカバーできます。どちらも同じサブスクリプションとルールを利用できますが、通信の取り込み範囲、DNS経路、必要な権限、障害時の挙動は異なります。

2つのモードにおけるリクエスト経路

システムプロキシ：アプリがローカルプロキシポートへ接続

システムプロキシを有効にすると、グラフィカルクライアントは通常、OSのHTTP、HTTPS、またはSOCKSプロキシアドレスを、127.0.0.1:7890などのローカル待受ポートへ向けます。ブラウザーはこの設定を読み取り、対象サイトへ直接接続せず、まずローカルのClashポートへ接続します。カーネルは対象ホスト名またはアドレスを取得し、現在のルールに従ってDIRECT、REJECT、またはプロキシグループを選択します。

この経路はアプリ側の対応に依存します。主要なブラウザーやシステムのネットワーク設定を読み取るデスクトップアプリの多くは正常にプロキシへ入りますが、次のような通信はシステムプロキシを迂回する可能性があります。

アプリが独自のネットワークスタックを実装し、OSのプロキシ設定を明示的に無視している。
ゲーム、音声通話、同期ツールなどがUDPを直接使用し、SOCKSやアプリ内プロキシに対応していない。
端末プログラムがHTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数だけを読み取る。
仮想マシン、コンテナ、サブシステムが独立したネットワーク環境を持ち、ホストのループバックアドレスを自分のプロキシアドレスとして利用できない。
アプリがハードコードされたアドレス、独自プロトコル、または独立したセキュアDNS経路を使用している。

したがって、システムプロキシを有効にしたからといって、すべてのプロセスが取り込まれるわけではありません。システム全体のデータパケットを強制的に迂回させるのではなく、アプリが読み取る接続先の指示に近い仕組みです。

TUN：システムルーティングがパケットを仮想インターフェースへ渡す

TUNモードは、仮想レイヤー3ネットワークインターフェースを作成します。システムはルーティングテーブルに従い、条件に一致するIPv4またはIPv6パケットをそのインターフェースへ送信します。mihomoなどのカーネルはユーザー空間のネットワークスタックで接続を復元し、ルールを適用してアウトバウンド接続を確立します。アプリは通常、対象アドレスへ直接アクセスしていると認識するため、HTTPやSOCKSプロキシへの個別対応は不要です。

典型的な経路は次のように整理できます：アプリが接続を開始 → OSがルートを選択 → TUN仮想インターフェース → Clashカーネル → ルールとプロキシグループ → 直接接続またはプロキシ経由のアウトバウンド。入口がIP層にあるため、TUNはUDP、コマンドラインプログラム、一部のゲームランチャー、システムプロキシを無視するアプリもより完全にカバーします。ただし、カバー範囲が広いことは、すべての通信が自動的にプロキシされることを意味しません。最終的な動作はルールによって決まります。LAN、予約アドレス、特定プロセスは直接接続として設定できます。

比較項目	システムプロキシ	TUNモード
通信の入口	HTTP、HTTPS、またはSOCKSのローカル待受ポート	仮想ネットワークインターフェースとシステムルーティング
アプリ側の対応	アプリがシステムプロキシを読み取るか、プロキシを手動指定する必要がある	ほとんどのアプリで個別設定が不要
UDPのカバー範囲	アプリとプロキシプロトコルの対応次第	通常は仮想インターフェースが一括で取り込む
必要な権限	一般に低い	インターフェースの作成、ルートの追加、またはシステムサービスのインストールが必要
トラブルシューティングの難易度	入口が明確で、変数が少ない	ルーティング、DNS、ネットワークアダプター、ファイアウォール、権限が関係する

DNS経路によって結果が変わる理由

「ノードには接続できるのにサイトが開かない」「ドメインルールに一致しない」「Clashを終了すると名前解決できない」といった問題は、実際にはDNS経路で発生していることが少なくありません。DNSがClashを経由しているか判断するには、画面上のDNSスイッチだけでなく、アプリがどこへクエリを送るのか、システムがどのリゾルバーを使うのか、53番ポートがリダイレクトされていないか、ブラウザーが独自の暗号化DNSを有効にしていないかを確認する必要があります。

システムプロキシではローカル名前解決が発生する場合がある

アプリがHTTP CONNECTまたはSOCKS経由でドメイン名を渡す場合、Clashは対象ホスト名を認識してドメインルールを適用できます。ただし、すべての接続でドメイン名が保持されるわけではありません。システムDNSでIPアドレスを取得してから、そのIPをプロキシへ渡すプログラムもあれば、ブラウザー内蔵のDNS over HTTPSを直接使うプログラムもあります。そのため、システムのリゾルバー、ブラウザーのリゾルバー、Clash DNSが同時に存在することがあります。

カーネルへ入る前にリクエストがIPアドレスへ解決されていると、ドメインルールの一致精度に影響します。カーネルはスニッフィングによって一部のHTTP、TLS、QUICのホスト情報を復元できる場合がありますが、すべてのプロトコルで有効とは限らず、誤ったDNS設定の代替と考えるべきではありません。

TUNでは通常DNSリダイレクトを併用する

TUN設定では、通常のUDPまたはTCPによる53番ポートへのクエリを、カーネルのDNSモジュールへ送る構成にすることがよくあります。mihomoの具体的なフィールドはバージョンやクライアントの実装によって異なるため、一般的な構成は参考とし、実際には現在のクライアントが生成した設定を確認してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

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

fake-ipは、予約アドレス範囲のマッピングアドレスをアプリへ返し、カーネルがドメインと接続の対応関係を保持できるようにします。パケットがTUNへ入ると、カーネルは元のドメイン名でルールを照合し、実際の対象へ接続します。一部のLAN機器、接続確認、ゲームプラットフォーム、実アドレスの応答値に依存するサービスではfake-ipが適さないため、除外リストへ追加するか、クライアントの機能に応じて別の拡張モードを使います。

DNSリダイレクトは主に従来の53番ポートへのクエリを対象とします。アプリがDoHまたはDoTサービスへ直接アクセスする場合、そのクエリは通常のHTTPSまたは暗号化接続として扱われ、dns-hijackと記述しただけで自動的にClash DNSへ変換されるわけではありません。既知の名前解決サービスのアウトバウンドをルールで制御するか、アプリ内のセキュアDNSを無効にして、名前解決をシステムとカーネルへ統一する方法があります。

権限、ルーティング、プラットフォームごとの差異

システムプロキシは通常、現在のユーザーのネットワークプロキシ設定だけを変更し、無効化すれば元の値へ戻せます。TUNでは仮想インターフェースの作成、ルートの追加、DNSの変更、システムサービスの呼び出しが必要になるため、より高い権限が求められます。クライアントによっては、管理者としての起動、特権ヘルパーサービス、ネットワーク拡張のインストールによってこれらの処理を行います。

Windows

WindowsクライアントでTUNを有効にする場合、通常は管理者権限、または事前にインストールして実行しておく権限付きサービスが必要です。画面ではTUNが有効なのに通信が元のネットワークを通る場合は、仮想ネットワークアダプターが作成されているか、デフォルトルートが追加されているか、セキュリティソフトやファイアウォールがカーネルプロセスを遮断していないかを確認します。スリープ復帰、ネットワーク切り替え、異常終了の後は、システムDNSとルーティングが復元されているかも確認してください。

macOS

macOSでは、システムネットワーク拡張、仮想インターフェース、認証済みヘルパープログラムなどを使って実装される場合があります。初回有効化時には、通常システムの許可ダイアログが表示されます。会社管理の端末では、ネットワーク拡張のインストールが制限されることがあります。ブラウザーだけ使えて端末やUDPアプリが使えない場合は、ノードをすぐ交換するのではなく、現在有効なのがシステムプロキシかTUNかを確認します。

Linux

LinuxでTUNインターフェースを作成してルートを書き込むには、root権限または対応する権限が必要です。たとえばサービスにネットワーク管理権限を付与します。コマンドラインで導入する場合は、デフォルト出口の識別、ポリシールーティング、systemdの起動順序、DNS管理サービス間の関係も扱う必要があります。NetworkManager、systemd-resolved、コンテナネットワークが同時にルーティングや名前解決設定を変更することもあるため、最終状態をどのコンポーネントが管理するのか明確にします。

コンテナと仮想マシンは、よくある境界の一つです。ホストでTUNを有効にしても、ゲストの通信がそのインターフェースを通るかどうかは、ブリッジ、NAT、転送ルール、ルーティング設計によって決まります。ホストのブラウザーで確認した結果だけから、コンテナの通信もClashへ入っていると判断することはできません。

用途に応じた選び方

システムプロキシを優先するケース

主にブラウザー、コードエディター、システムプロキシに対応したデスクトップアプリを使う。
ネットワークへの変更を抑え、いつでも切り替えやすく、障害箇所を特定しやすくしたい。
現在のアカウントに仮想インターフェースのインストールやルート変更の権限がない。
LAN、VPN、仮想マシン、企業ネットワークが複雑で、追加のルート競合を避けたい。
一部のアプリだけをプロキシ経由にし、アプリ内でHTTPまたはSOCKSアドレスを明示設定できる。

開発ツールは個別に確認が必要です。Git、パッケージマネージャー、Dockerクライアント、端末のダウンロードツールは、グラフィカル画面のシステムプロキシを必ずしも読み取りません。各ツールのドキュメントに従ってプロキシ環境変数を設定するか、ローカルのSOCKS/HTTP待受アドレスを直接指定します。システムプロキシモードは、取り込み範囲を見通しやすく制御しやすいアプリ層に保ちたい場合に適しています。

TUNを優先するケース

アプリがシステムプロキシを無視する、またはプロキシ設定の入口を提供していない。
UDP、ゲーム接続、コマンドラインプログラム、複数プロトコルが混在する通信を扱う必要がある。
ドメイン解決、ルール照合、アプリの接続経路をできるだけ統一したい。
プロセス、対象ネットワーク、複雑なルールに基づいて広範なネットワーク通信を処理する必要があり、クライアントのカーネルが対応している。
管理者権限、システムサービス、ルート復元、LANバイパスルールを管理できる。

TUNは「アプリを制御できないが、システムネットワークは制御できる」環境に適しています。速度を向上させるスイッチではありません。遅延やスループットは主に、ノードの回線、混雑、転送プロトコル、MTU、DNS応答、対象サービスの影響を受けます。TUNを有効にして速度が低下した場合は、仮想ネットワークアダプター自体の問題と決めつけず、ルーティングループ、誤ったIPv6経路、MTUの不一致、DNSフォールバックによる待機が発生していないか確認します。

両方を同時に有効にできるか

多くのクライアントでは、システムプロキシとTUNを同時に有効にできます。これにより、プロキシ設定を明示的に読み取るアプリと、それ以外の通信を両立できますが、トラブルシューティングの変数は増えます。接続がいったんローカルプロキシポートへ入り、そのポートからのアウトバウンドがTUNルーティングの影響を受ける場合もあります。成熟した実装では通常、インターフェース除外やプロセスバイパスを設定してループを防ぎますが、クライアントサービスの異常、手動ルート、外部VPNによって条件が崩れることがあります。

日常利用で「より広くカバーする」ために、常に両方を有効にする必要はありません。まずアプリの種類に応じて入口を1つ選びます。システムプロキシで要件を満たせるなら、単一の入口にした方が管理しやすくなります。プロキシを読み取らないアプリが実際にある場合に、TUNを試してください。

入口、名前解決、ルール、アウトバウンドの層に分けて切り分ける

プロキシモードを切り替えた後に障害が発生した場合は、ノードを次々と交換するのではなく、データ経路に沿って層ごとに確認します。次の順序で調べると、問題の範囲を絞り込めます。

カーネルが動作していることを確認する。クライアントの状態、ローカル待受ポート、直近のログを確認します。カーネルが起動していなければ、システムプロキシもTUNも有効な転送を行いません。
通信がカーネルへ入っていることを確認する。テストサイトへアクセスするか、対象を明確にしたリクエストを1回実行し、接続一覧に対象が表示されるか確認します。記録がない場合は、アプリがシステムプロキシを読み取っていないか、TUNルートが有効になっていない可能性があります。
DNSリクエストの経路を確認する。システムの名前解決結果、クライアントのDNSログ、ブラウザーのセキュアDNS設定を比較します。1つのWebページのテストだけで結論を出さないでください。
ルールの一致を確認する。対象接続がどのルールに一致し、どのプロキシグループへ入ったかを確認します。ルールは通常上から順に評価され、最初に一致したルールが動作を決めます。
プロキシグループの実際の選択を確認する。プロキシグループ名に「プロキシ」と表示されていても、内部のノードが利用可能とは限りません。現在選択されているノード、遅延テスト、失敗ログを確認します。
アウトバウンドインターフェースを確認する。TUNを有効にしている場合は特に、カーネルが正しい物理ネットワークアダプターを選択しているか確認し、プロキシサーバーへの接続が再びTUNへ送られないようにします。

システムプロキシモードでは、「プロキシを使わない場合」と「ローカルプロキシを明示指定した場合」を分けてテストできます。以下のポートは一般的な例にすぎないため、現在クライアントに表示されている待受ポートへ置き換えてください。

curl https://example.com
curl --proxy http://127.0.0.1:7890 https://example.com
curl --proxy socks5h://127.0.0.1:7890 https://example.com

socks5hではホスト名の解決をSOCKSプロキシ側に任せるため、ローカルでの名前解決結果との比較に適しています。プロキシを明示指定すれば使えるのに通常のリクエストが使えない場合、問題はシステムプロキシの読み取りまたは環境変数にある可能性が高いです。どちらもカーネルへ入っているのにルールが異なる場合は、リクエストがドメイン名を含むのか、解決済みのIPアドレスなのかを確認します。

TUNモードでは、まずシステムに対応する仮想インターフェースとルートが存在するか確認し、1回のリクエストがClashの接続記録に現れるかを確認します。TCPは使えるのにUDPが通らない場合は、カーネル、ノードのプロトコル、ルール、対象サービスがそのUDP経路に対応しているかを確認します。LANプリンターやルーターの管理画面へ接続できなくなった場合は、プライベートネットワークが直接接続のままになっているか、自動ルーティングがローカルネットワークを覆っていないかを確認します。

選択の結論：最小限の取り込みから始め、必要に応じて範囲を広げる

ブラウザーと一般的なデスクトップアプリだけを扱う場合、システムプロキシがより直接的な出発点です。必要な権限が少なく、接続の入口が明確で、アプリがプロキシ設定を読み取っているか確認しやすいからです。コマンドラインプログラムでは、環境変数やツール独自のプロキシ設定を追加できます。

アプリがプロキシ設定を無視する、UDPが必要、DNS経路をより統一したい、またはルーティングでより多くのプロセスを取り込みたい場合は、TUNを有効にします。有効化後は、管理者権限、仮想インターフェース、自動ルーティング、物理出口の識別、DNSリダイレクト、LANバイパス、IPv6の挙動も確認してください。

どちらのモードも、最終的には同じClashまたはmihomoのルール体系へ接続を渡します。システムプロキシは「アプリがカーネルへ渡すか」を解決し、TUNは「システムがパケットをカーネルへ送るか」を解決します。障害が入口、DNS、ルール、アウトバウンドのどこにあるかを先に特定してから対応する設定を調整すれば、すべての接続問題をノードやサブスクリプションのせいにせずに済みます。