TUNモードとシステムプロキシはどちらを選ぶ？2つの通信取り込み方式の仕組みを比較

まず結論：ブラウザーはシステムプロキシ、全通信の取り込みにはTUN

システムプロキシとTUNモードは、異なるプロキシプロトコルではありません。どちらも端末の接続をClashまたはMihomoコアに渡す方式です。最終的に直接接続するか、どのノードを選ぶかは、設定内のルール、プロキシグループ、現在の動作モードによって決まります。実際の違いは、通信がどこからコアに入り、どのアプリが処理対象になるかです。

主な用途がWeb閲覧やシステムプロキシに対応したデスクトップアプリなら、まずシステムプロキシを有効にするのが適しています。起動が速く、必要な権限も少なく、無効化後の復旧も簡単です。コマンドラインツール、ゲームランチャー、一部のストアクライアント、システムプロキシを使わないUDPアプリには、TUNモードで取り込み範囲を広げます。

システムプロキシの仕組み：アプリが接続をローカルポートへ渡す

システムプロキシを有効にすると、ClashクライアントはOSのHTTP、HTTPS、またはSOCKSプロキシアドレスをローカルの待受ポートへ向けます。一般的な設定では mixed-port: 7890 を使い、同じポートでHTTPとSOCKS5接続を受け付けます。古い設定では port: 7890 と socks-port: 7891 を分ける場合もあります。これらは端末のアプリとプロキシコアの間の入口を示すもので、リモートノードのポートではありません。

アプリがシステムプロキシ設定を読み取り、それに従って初めて接続がClashに入ります。Chrome、Edge、Safariや、OSのネットワークフレームワークを利用する多くのデスクトップソフトがこの方式に対応しています。アプリが 127.0.0.1:7890 に接続すると、コアは宛先ドメインまたはアドレスを読み取り、DOMAIN-SUFFIX、IP-CIDR、ルールセット、最終ルールに基づいてDIRECT、REJECT、またはプロキシグループを選択します。

システムプロキシが設定されているか確認する方法

• Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」を開き、手動プロキシサーバーが 127.0.0.1 とクライアントに表示されたポートを指しているか確認します。
• macOSでは「システム設定」→「ネットワーク」→使用中のネットワーク→「詳細」→「プロキシ」を開き、WebプロキシとセキュアWebプロキシの項目を確認します。
• ClashXでは、メニューバーのアイコンから「システムプロキシに設定」の状態を確認し、現在の設定が起動していることも確認します。
• MihomoのGUIクライアントを使う場合は、「設定」→「Clash設定」にある混合ポートも確認します。クライアントのバージョンによって、メニュー名が多少異なる場合があります。

ブラウザーは通るのに、ターミナルは通らない理由

curl、Git、npm、pipなどのコマンドラインツールは、システムプロキシの扱いが統一されていません。環境変数を読むバージョンもあれば、個別設定が必要なものもあります。一時的なテストでは、現在のターミナルで HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を設定し、ローカルポートを明示します。

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

curl -I https://example.com

socks5h の h は、ドメイン名の解決をSOCKSプロキシ側で行うことを示します。ターミナルがローカルで先に名前解決することによる結果の違いを抑えられます。Windows PowerShellでは、$env:HTTPS_PROXY="http://127.0.0.1:7890" を使って現在のセッションに変数を設定できます。ターミナルを閉じれば、一時変数が新しいセッションに影響することはありません。

TUNモードの仕組み：仮想NICがIP通信を受け取る

TUNモードは仮想的なL3ネットワークインターフェースを作成し、ルーティングテーブルによって条件に一致するIPパケットをそのインターフェースへ転送します。Mihomoコアはパケット内の送信元アドレス、宛先アドレス、トランスポートプロトコルを読み取り、接続情報を復元してからプロキシルールを適用します。アプリからは通常のネットワーク接続に見えるため、HTTPやSOCKSプロキシを理解したり、システムプロキシを自動的に読み取ったりする必要がありません。

これがTUNでより多くのプログラムをカバーできる理由です。独自のネットワークスタックを使うゲームランチャー、システムプロキシを無視するコマンドラインプログラム、UDPを使うアプリも、TUNの取り込み経路に入る可能性があります。ただし、「TUNを有効にする」ことが「すべてのデータが必ずリモートノードを経由する」ことを意味するわけではありません。LANアドレス、除外ルート、DIRECTルール、プロセスルール、クライアント設定によって最終経路は変わります。

Mihomoの基本的なTUN設定

mixed-port: 7890
mode: rule

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

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

auto-route は必要なルートを自動追加し、auto-detect-interface は実際の送信インターフェースの検出を試みます。dns-hijack は、対象となる53番ポートのDNSリクエストをコアのDNSモジュールへ渡します。stack: mixed はMihomoでよく使われる選択肢で、システムスタックとユーザー空間の処理機能を組み合わせます。OS、コアのバージョン、クライアントによっては system、gvisor、mixed を利用できますが、別のコアにある同名オプションをそのまま流用してはいけません。

適用範囲の比較：TCP、UDP、LAN、プロセス識別

TCPとUDPの違い

OSのHTTPプロキシは、主にTCPベースのHTTPとHTTPS接続を対象とします。SOCKS5自体はUDP処理を拡張できますが、アプリがSOCKS5 UDP転送を明示的にサポートしていることが前提です。OSの通常の「Webプロキシ」設定を有効にしても、すべてのUDPデータが自動的にSOCKSポートへ渡されるわけではありません。そのため、音声通信、リアルタイムゲーム、QUIC、一部のDNSリクエストはシステムプロキシを迂回する可能性があります。

TUNはIP層でTCPとUDPを認識するため、2種類のトランスポートプロトコルを一元的に処理する用途に適しています。それでも、リモートノードのプロトコルが対応するUDP転送をサポートし、プロキシグループ内の実際のノードでUDP機能が有効になっている必要があります。ログ上でUDP接続がルールに一致した後も失敗する場合は、TUNの切り替えだけを繰り返さず、ノードのプロトコル、サーバー設定、ネットワークMTUを確認してください。

LANデバイスとプライベートアドレス

プリンター、NAS、ルーターの管理画面では、192.168.0.0/16、10.0.0.0/8、172.16.0.0/12 などがよく使われます。TUNを有効にした後もLANへの直接接続ルールを残し、自動ルーティングによってこれらのネットワークが誤ったインターフェースへ送られていないか確認します。一般的なルールはプロキシルールより前に置けます。

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

企業内ネットワークでもこれらのプライベートアドレスを使っている場合、ネットワーク範囲を直接接続にするだけでは不十分です。会社VPNインターフェースのルート優先順位も正しく設定してください。「インターネットは正常なのに、社内ドメインを開けない」場合は、まずTUNの有効化前後でルーティングテーブルを比較し、プロキシノードを直接変更しないようにします。

プロセスルールの信頼性

TUNモードでは、コアが対応プラットフォーム上で接続元プロセスの識別を試み、PROCESS-NAME や PROCESS-PATH に一致させられます。ただし、プロセス識別はOSの権限、アプリのサンドボックス、子プロセスの構成、コアの実装に左右されます。ブラウザーのネットワークサービスが独立したプロセスで動作する場合や、コンテナ通信がホスト側のプロセスとしてしか表示されない場合もあります。重要な分岐はドメイン、IP、ルールセットを中心に設定し、プロセスルールは補助として使うのがおすすめです。

DNS処理の比較：ドメイン名はどの段階で解決されるか

システムプロキシでは、DNSの挙動はアプリとプロキシの種類によって異なります。ブラウザーが暗号化DNSを独自に有効にする場合もあれば、OSで先に名前解決してから解決済みIPへ接続する場合もあります。SOCKS5クライアントでは、ドメイン名の解決をプロキシへ任せることもできます。Clashに入る前にドメインがIPへ変換されていると、コアは宛先IPだけで判定することになり、ドメインルールの可視性がスニッフィングやマッピングの状態に左右されます。

TUNはMihomoのDNSモジュール、DNSハイジャック、Fake IPと組み合わせて使うことがよくあります。Fake IPモードでは、たとえば既定値としてよく使われる 198.18.0.0/16 などの予約アドレス範囲から一時アドレスを返し、マッピングに基づいて元のドメインを復元します。アプリがIP接続だけを開始する場合でもドメインルールを適用でき、ローカルの名前解決経路とプロキシ経路の不一致も抑えられます。

Fake IPはリモートDNSではない

Fake IPは、端末上のコアがドメインのマッピングを管理する仕組みです。実際に上流へ問い合わせる際は、nameserver、proxy-server-nameserver、ルール用DNS、現在のプロキシ設定が使われます。ノードサーバーのドメイン自体にも利用可能な名前解決経路が必要です。そうでなければ、「ノードへ接続するために、先にノードのアドレスを解決しなければならない」という循環依存が発生します。

• Webページで証明書のドメインエラーが表示される場合は、DNSがほかのソフトウェアに書き換えられていないか、Fake IPのマッピングが有効かを確認します。
• LANデバイスにホスト名でアクセスできない場合は、関連ドメインをFake IPのフィルターリストに追加するか、LANドメイン専用のDNSを設定します。
• アプリにDoHが組み込まれている場合、通常の53番ポートのハイジャックではその問い合わせを取り込めないことがあります。ブラウザーのセキュアDNS設定と、ルールへの一致状況を確認してください。
• スリープ復帰後に多くのドメインで一時的な失敗が発生した場合は、まず設定を再読み込みしてOSのDNSキャッシュを更新し、その後TUNインターフェースの再作成が必要か判断します。

権限、互換性、性能負荷を比較する方法

必要な権限

システムプロキシでは通常、現在のユーザーのネットワークプロキシ設定を変更するだけで済みます。TUNでは仮想NICの作成、ルーティングテーブルの変更、システムネットワーク拡張の呼び出しが必要です。そのためWindowsでは管理者の承認、macOSではネットワーク拡張や補助サービスの許可、Linuxでは通常 CAP_NET_ADMIN、root権限、またはsystemdによるプロセスへの該当権限の付与が必要になります。

権限は、提供元とバージョンを確認できるクライアントにのみ付与してください。TUNをクリックした直後にスイッチが戻る場合は、まずクライアントサービスの状態とコアのログを確認します。インターフェース作成に失敗したという表示があれば、システム権限を確認してください。設定ファイルを何度も再インストールしても、ドライバー、サービス、権限付与の問題は通常解決しません。

VPN、仮想マシン、コンテナとの共存

企業VPNとTUNは、どちらも仮想インターフェースを作成してデフォルトルートを書き換える可能性があります。後から起動したソフトウェアがルートの優先順位を変更し、接続ループ、社内ネットワークの切断、誤ったNICからの通信を引き起こすことがあります。一般的には、先に企業VPNへ接続し、その後Clash TUNを起動します。auto-detect-interface またはクライアントのインターフェース設定で実際の出口を確認してください。会社のポリシーでルート変更が許可されていない場合は、システムプロキシのほうが安全です。

WSL2、Docker Desktop、Parallels、VMwareは独自の仮想ネットワークを管理します。ホストのTUNが仮想マシン内部のすべての通信を自動的にカバーするとは限らず、仮想マシンがホストをゲートウェイとして扱う場合もあります。ホストOS、仮想NIC、ゲストOSそれぞれのデフォルトルートを確認し、ホストのブラウザー結果だけで判断しないでください。

性能負荷は環境によって異なる

TUNでは仮想インターフェースによる送受信、プロトコルスタック処理、ルール判定が加わります。理論上は、アプリがローカルのプロキシポートへ直接接続するより経路が長くなりますが、日常的なWeb閲覧での差は通常、リモートノードの遅延より小さい範囲です。以下は固定環境での比較例であり、すべての端末に当てはまるものではありません。Windows 11 24H2、Mihomo 1.19.8、Ryzen 7 7840U、有線ギガビット回線、同じノードとルールで10回連続測定しました。

この例では、TUNによって最初のパケットが約0.8ms増加し、ダウンロードスループットが約4.2%低下しました。ただし、リモートノードの負荷、暗号化プロトコル、NICオフロード、MTUによって、さらに大きな変動が生じることがあります。低消費電力デバイスでは、1回の速度テストのピーク値だけでなく、連続転送時のCPU使用率と温度を重視してください。

手順に沿って選択・切り分ける：複数の設定を同時に変更しない

方法1：まずシステムプロキシを検証する

1. クライアントを起動して設定を読み込み、ローカルの混合ポートが 7890 または画面に表示された実際の値になっていることを確認します。
2. ルールモードを選び、テスト対象のドメインに対応するプロキシグループを、利用可能なノードに固定します。
3. システムプロキシを有効にし、ブラウザーでテストページへアクセスします。同時に接続ログにドメイン名とポリシー名が表示されるか確認します。
4. ブラウザーが正常なら、ターミナル、ストアクライアント、対象アプリを順番にテストし、どのプログラムがログに現れないかを記録します。
5. 取り込み範囲に明確な不足がある場合だけ、システムプロキシのテストを無効にしてTUNを有効にします。2つの経路を同時に動かして判断を難しくしないようにします。

方法2：TUN有効化後に確認する4つのポイント

1. ログでTUNインターフェースの作成に成功しているか、権限、ルート、デバイス使用中のエラーが出ていないか確認します。
2. デフォルトルートと実際の出口インターフェースを確認し、プロキシサーバーへの接続が再びTUNへ送られてループしていないことを確認します。
3. DNSログを確認し、問い合わせがMihomoのDNSモジュールに入り、想定したドメインルールに一致していることを確認します。
4. TCP、UDP、LANアドレス、スリープ復帰をそれぞれテストします。1つのWebページが開くだけで完了と判断しないでください。

よくある現象と対処方法

最終的な選択：モードの強弱ではなく、アプリの範囲で決める

システムプロキシは、プロキシ設定に明確に対応したブラウザーやデスクトップアプリに適しています。ルーティングテーブルへの影響が小さく、日常の標準設定として使いやすいうえ、ノードとルールが正常かどうかも素早く判断できます。ターミナルツールをたまに使うだけなら、環境変数を個別に設定すればよく、そのためにTUNを常時有効にする必要はありません。

TUNは、UDP、システムプロキシを無視するプログラム、複雑なDNS分岐、複数種類のアプリを一元的に取り込みたい場面に適しています。ノードの速度を向上させるものではなく、通信の入口をより広くする仕組みです。その分、権限、仮想NIC、DNS、ルートの競合にも対処する必要があります。

実際の設定は「システムプロキシを常時有効、TUNは必要時のみ」という運用ができます。初回導入では、まずシステムプロキシ、ノード選択、ルール一致を確認してから、TUNで適用範囲を広げます。問題が起きた場合は、通信の入口、DNS、ルート、ルール、ノードの機能という順に段階的に確認すると、グローバルモード、ルールモード、複数のスイッチを切り替え続けるより原因を見つけやすくなります。