TUNモードとシステムプロキシの違い：トラフィックの取り込み範囲と仕組みを比較

核心となる違い：プロキシ設定と仮想NICは異なる階層にある

システムプロキシとTUNモードはいずれも通信をClash Meta（mihomo）カーネルへ送れますが、入口が異なります。システムプロキシはOSにHTTP、HTTPS、SOCKSプロキシのアドレスを登録します。たとえば 127.0.0.1:7890 です。アプリがこの設定を読み取り、リクエストをローカルのプロキシポートへ渡します。一方、TUNモードは仮想ネットワークインターフェースを作成し、ルーティングルールによって条件に合うIPパケットをカーネルへ送ります。

この違いが適用範囲を左右します。ブラウザー、OSのアップデーター、多くのデスクトップアプリは通常システムプロキシを読み取るため、これを有効にすれば十分です。一部のゲームランチャー、コマンドラインプログラム、UDPベースの通信ソフト、独自のネットワークスタックを使うアプリはシステムプロキシを無視することがあり、その場合はTUNのほうが通信を取り込みやすくなります。

比較項目	システムプロキシ	TUNモード
取り込みの入口	OSのプロキシ設定またはアプリ内のプロキシ設定	仮想NICとOSのルーティングテーブル
主なプロトコル	HTTP、HTTPS、SOCKS	IP層のTCPおよびUDP通信
アプリ側の対応	アプリがプロキシ設定を読み取る必要がある	通常、アプリがプロキシの存在を意識する必要はない
有効化に必要な権限	通常のユーザー権限で利用可能	管理者権限またはネットワーク拡張の許可が必要な場合が多い
トラブル対応の範囲	ポート、アプリのプロキシ設定、プロトコル対応	仮想NIC、ルーティング、DNS、ファイアウォール、インターフェースの競合
適した用途	ブラウザーと一般的なデスクトップアプリ	ゲーム、コマンドラインツール、UDPアプリ、通信の一括取り込み

システムプロキシがリクエストをmihomoへ渡す仕組み

アプリがプロキシアドレスを自ら読み取る必要がある

クライアントの「システムプロキシ」スイッチを有効にすると、クライアントがローカルのプロキシアドレスをOSへ書き込みます。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で現在の設定を確認できます。macOSでは「システム設定」→「ネットワーク」→使用中のネットワークインターフェース→「詳細」→「プロキシ」でHTTP、HTTPS、SOCKSの項目を確認できます。

mihomoの混合ポートが 7890 だとすると、ブラウザーはシステム設定を読み取り、リクエストを 127.0.0.1:7890 へ送ります。カーネルはドメイン、宛先アドレス、接続情報を取得し、rules を上から順に照合して、最終的に DIRECT、REJECT、または特定のポリシーグループを選びます。システムプロキシが担うのは「リクエストを受け入れる」ことだけで、ルールモード、ノード選択、DNSポリシーを変更するものではありません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH、ノード選択

mixed-port はHTTPとSOCKSのリクエストを同時に受け付けます。一般的なデフォルト値は 7890 ですが、クライアントによっては 7897、7899、その他のポートが割り当てられます。設定を確認する際は、例のポート番号ではなく、クライアントに表示される実際の待受ポートを基準にしてください。

システムプロキシを回避する可能性があるプログラム

アプリが独自に接続処理を実装し、OSのプロキシ設定を明示的に無視している。
コマンドラインツールが環境変数を読み取らず、HTTP_PROXY、HTTPS_PROXY、ALL_PROXY も設定されていない。
ゲームやリアルタイム通信プログラムが主にUDPを使用しており、OSのHTTPプロキシではその通信を処理できない。
サンドボックス、仮想マシン、コンテナ、サブシステムが独立したネットワーク環境を持ち、ホストのプロキシアドレスを直接引き継げない。
アプリがSOCKSにしか対応していないのに、OSにはHTTPプロキシしか登録されていない、またはその逆でHTTPプロキシしか読み取らない。

コマンドラインプログラムはよくある例です。システムプロキシを設定しても curl が直接接続する場合は、まずローカルプロキシを明示して確認します。

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

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890

プロキシを明示するとアクセスできるのに、通常のコマンド実行ではアクセスできない場合、mihomoのポートとルールはおおむね正常で、問題はプログラムがシステムプロキシを読み取っているかどうかに絞られます。この時点で、すぐにノードやサブスクリプションを変更する必要はありません。

TUNモードがTCP、UDP、DNSを取り込む仕組み

仮想インターフェースと自動ルーティング

TUNモードを起動すると、クライアントが仮想ネットワークインターフェースを作成します。mihomoは auto-route によってルートを書き込み、宛先の通信をこのインターフェースへ向けられます。アプリは宛先サーバーへ直接接続しているつもりでも、パケットはいったんmihomoに入り、カーネルが接続先を復元してルールを照合し、直接接続またはプロキシ経由で送信します。

mihomo v1.19系列で利用できるフィールドを例にすると、基本設定には次の項目を含められます。GUIクライアントは通常これらのフィールドを自動管理するため、手動編集の前に、サブスクリプション更新時にクライアントが設定を上書きしないか確認してください。

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

enable はTUNインターフェースを有効にするかどうかを制御します。
stack はネットワークスタックの実装を選択します。mixed は複数の処理方式を組み合わせるため、一般的な開始設定に適しています。
dns-hijack は、条件に一致するDNSリクエストをmihomoのDNSモジュールへ渡します。
auto-route は必要なルートを自動的に書き込み、ルーティングテーブルを手動で管理する手間を減らします。
auto-detect-interface は、現在のデフォルト出口（Wi-Fiや有線NICなど）の検出を試みます。
strict-route はルーティングの制約を強め、TUNを経由せずに通信が抜ける可能性を下げます。ただし、企業VPNや仮想マシンのネットワークとの競合が表面化することもあります。

TUNが取り込むのは、OSのルーティングによって仮想インターフェースへ送られたパケットです。どのような状況でも端末上のすべての接続を処理できるという意味ではありません。カーネル自身の接続、ローカルネットワークの予約アドレス、明示的に除外されたルート、他のVPNが先に取り込んだ通信、OSが制限する特殊なサービスは、別の経路を通る可能性があります。

TUNのトラブル対応でDNSが重要な理由

アプリは通常、接続を開始する前にドメインを解決します。DNS問い合わせがローカルネットワークを通り、その後のTCP接続だけがTUNへ入ると、解決結果とプロキシ出口の場所が一致しない、ルールからIPしか見えない、汚染された結果がキャッシュされるといった問題が起こります。TUNを有効にしたら、mihomoのDNSモジュール、dns-hijack、ルール設定が連動しているかも確認してください。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  fallback:
    - tls://8.8.8.8:853

fake-ip モードは予約アドレス帯から一時アドレスを割り当て、カーネルがマッピングをもとに元のドメインを復元します。LAN機器の検出、印刷サービス、古いゲーム、実際の名前解決結果に依存するソフトウェアの一部はfake-ipに適さない場合があります。その場合は fake-ip-filter で該当ドメインを除外するか、クライアントの対応状況に応じて別の拡張モードを使用してください。

互換性・性能・権限のバランスをどう取るか

適用範囲だけが判断基準ではない

システムプロキシの利点は動作が分かりやすいことです。アプリはローカルポートへ接続し、mihomoのログには通常、リクエストのドメイン、ヒットしたルール、ポリシーグループの結果が直接表示されます。システムプロキシを無効にすればOSは元の設定に戻り、ルーティングテーブルや仮想インターフェースへの影響も少なく済みます。日常的なWeb閲覧、コードホスティング、一般的なデスクトップソフトにはこの方式が向いています。

TUNの価値は主に互換性と一括取り込みにあります。プロキシ設定を読み取らないTCPアプリを処理でき、多くのUDP通信にも対応できます。その代わり、通信が仮想インターフェース、ネットワークスタックの変換、ルーティング判定を通るため、トラブル対応ではドライバー、権限、DNS、他のネットワークソフトも考慮する必要があります。

性能差は同じ条件で測定する

同じWindows 11 24H2端末、同じノード、mihomo v1.19.x、同じルールモードとDNS設定でHTTPSリクエストを100回行うと、システムプロキシとTUNの接続時間の中央値は数ミリ秒しか違わないことがあります。あるローカルテストでは、システムプロキシが184ミリ秒、TUNが189ミリ秒でした。別の遠距離ノードに切り替えると、どちらも420ミリ秒を超えました。この結果から、遅延には取り込み方式よりノードの経路や宛先サーバーの影響が大きいことが分かります。

テストでは少なくともノード、ルール、DNS、対象URL、ネットワークインターフェースを固定し、50～100回分の結果を個別に記録してください。速度テストページを1回だけ測ってピーク値を比較すると、キャッシュ、混雑、サーバー負荷をTUNのオーバーヘッドと誤認しやすくなります。

Webページやダウンロード速度に異常がある：同じノードで、直接接続・システムプロキシ・TUNを比較する。
ゲームの遅延に異常がある：UDPが取り込まれているか、ゲームサーバーが想定したポリシーグループへ送られているかを同時に確認する。
CPU使用率に異常がある：TUNスイッチだけでなく、接続数、ログレベル、ルール規模、DNS問い合わせ数を確認する。
待機中のバッテリー消費に異常がある：バックグラウンド接続の頻度、LANブロードキャスト、クライアントが仮想インターフェースを再作成し続けていないかを確認する。

プラットフォームごとの権限の違い

Windowsで仮想NICを作成したり、ルートを書き込んだり、ネットワークコンポーネントをインストールしたりするには、通常管理者権限が必要です。macOSではネットワーク拡張またはVPN構成の許可を求められます。Linuxでは通常、CAP_NET_ADMIN 権限が必要で、TUNデバイスの作成とポリシールーティングの変更も許可しなければなりません。AndroidとiOSのGUIクライアントは、通常システムのVPNインターフェースを利用して同様の取り込みを行うため、ステータスバーにVPN表示が出ます。

権限の許可に成功しても、ルーティングが正しいとは限りません。Wi-Fiから有線へ、家庭内ネットワークからテザリングへ切り替えたとき、またはスリープ復帰後にデフォルトインターフェースが変わったときは、自動検出結果の再構築が必要になる場合があります。「起動直後は正常なのに、ネットワークを切り替えると通信できない」場合は、まずTUNを無効にして3～5秒待ち、再度有効にしてログのデフォルトインターフェースを確認してください。

用途に応じてシステムプロキシとTUNを選ぶ

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

主にブラウザー、メール、チャットツール、一般的な開発ツールを使う。
特定のリクエストがmihomoに入ったかをすぐ確認したい。
端末で企業VPNも動作しており、2つのツールがデフォルトルートを奪い合う状態を避けたい。
一部のアプリだけをプロキシ経由にし、その他のアプリは従来のネットワーク経路を維持したい。
現在のアカウントでは、仮想NICやネットワーク拡張の権限を付与しにくい。

アプリに独自のプロキシ設定がある場合は、全体のシステムプロキシを有効にせず、127.0.0.1 と実際の混合ポートだけを入力することもできます。影響範囲を1つのアプリに限定できるため、ブラウザー設定、ダウンロードツール、開発環境のデバッグに適しています。

TUNの有効化が適しているケース

アプリがシステムプロキシを明示的に無視するが、通信にはルールを適用したい。
一部のゲーム、音声通信、リアルタイム通信など、UDPを取り込みたい。
コマンドラインツール、デスクトップアプリ、バックグラウンドサービスに同じルールを一括適用したい。
アプリにHTTPまたはSOCKSプロキシのアドレスを入力できない。
本来は直接接続のIPしか見えない通信をドメインルールで処理したく、対応するDNS設定も済んでいる。

多くのクライアントでは、システムプロキシとTUNを同時に有効にできます。ただし、同じ接続の効果が倍増するわけではなく、判断経路が増えるだけです。システムプロキシに対応するアプリはまずローカルポートへ接続し、それ以外の通信をTUNが取り込みます。初回設定では一度に1つの方式だけを有効にし、安定動作を確認してから併用が必要か判断することをおすすめします。

通信できない・プロキシ漏れ・接続失敗が起きたときの確認方法

システムプロキシの確認手順

mihomoカーネルが動作中で、クライアントの状態が「カーネル停止」になっていないことを確認する。
ローカルの待受ポートを確認し、たとえば 127.0.0.1:7890 がシステムプロキシに入力した値と一致しているか確認する。
Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」でアドレスとポートを確認し、macOSのネットワークプロキシ画面で有効なプロトコルを確認する。
curl --proxy でプロキシを明示してリクエストし、「ローカルポートの障害」と「アプリがプロキシを読み取っていない状態」を切り分ける。
クライアントのログレベルを一時的に info または debug に設定し、リクエストが現れるか、どのルールに一致したかを確認する。
ルールモードに切り替え、確実に利用できるポリシーグループを選択して、モードの問題をポートの問題と取り違えないようにする。

クライアント終了後にWebページを開けない場合、システムプロキシのアドレスが停止済みのローカルポートを指したままになっていることがよくあります。まずOSの手動プロキシを無効にしてから、クライアントを再起動してください。GUIクライアントの「システムプロキシを復元」機能で残った設定を消去することもできます。

TUNモードの確認手順

システムプロキシを無効にし、TUNだけを残して経路上の変数を減らす。
クライアントが管理者権限、ネットワーク拡張の許可、またはLinuxのネットワーク管理権限を取得していることを確認する。
仮想インターフェースが正常に作成されたか、ログにルート書き込み失敗が出ていないかを確認する。
デフォルト出口が、現在使用中のWi-Fi、有線NIC、モバイルホットスポットとして認識されているか確認する。
他のVPN、ゲームアクセラレーター、ルートを変更する仮想ネットワークソフトを一時的に終了する。
IPアドレスとドメインを分けてテストし、IPには接続できるのにドメインで失敗する場合は、まずDNSを確認する。
ルーターの管理画面などLANアドレスをテストする。到達できない場合は、プライベートネットワーク帯のルールと厳格なルーティング設定を確認する。
TUNを無効にしてルートが戻るまで待ってから再度有効にし、短時間だけ残る古いインターフェース状態を避ける。

ログに接続記録があるのに宛先へ到達できない場合は、ルール結果、ノード状態、DNSを重点的に確認します。アプリの接続がログにまったくない場合は、OSのルーティング、インターフェース競合、アプリが別のネットワーク環境を使っていないかを確認します。この切り分けは、設定をすぐ削除するより多くの情報を与えてくれます。

現象	優先して確認する項目	確認方法
ブラウザーは使えるが、ゲームは使えない	UDPの取り込みとゲームルール	システムプロキシを無効にしてTUNだけを有効にする
IPにはアクセスできるが、ドメインで失敗する	DNSハイジャックとnameserver	DNS問い合わせと応答結果をログで確認する
TUNを有効にするとLANへ接続できない	プライベートネットワーク帯のルートとstrict-route	ゲートウェイアドレスをテストし、DIRECTルールを確認する
Wi-Fiを切り替えると通信が途切れる	デフォルトインターフェースの検出	TUNを再構築し、出口インターフェースを確認する
クライアントを終了するとインターネットに接続できない	残ったシステムプロキシまたはルート	手動プロキシを無効にし、デフォルトルートを復元する

結論：最小限の取り込み範囲から設定する

システムプロキシは、ほとんどのブラウザーやデスクトップアプリに適しています。設定箇所が明確で必要な権限も少なく、問題が起きても「アプリ設定—ローカルポート—ルール—ノード」の順に確認できます。TUNモードは、UDP、コマンドラインプログラム、プロキシ設定に従わないソフトウェアを対象にしたい場合に適しています。仮想NICとルーティングでより広い通信を取り込める一方、DNS、インターフェース選択、ルート競合もトラブル対応の範囲に入ります。

実際の利用では、まずルールモードでシステムプロキシを有効にし、サブスクリプション、ノード、ポリシーグループ、DNSが動作することを確認します。その後、システムプロキシを実際に回避するアプリに対してTUNを有効にしてください。取り込み範囲を広げるほど、設定の境界と確認手順を明確に保つことが重要です。