上級設定 読了目安 13分

TUNモードとシステムプロキシの違い：トラフィックを取り込む仕組みと使い分け

システムプロキシとTUNモードの仕組みを、トラフィックの取り込み方から解説。システムプロキシを使わないアプリや、TUNが幅広い通信を処理できる理由、適した利用シーンを紹介します。

まず結論：違いはプロキシルールではなく、トラフィックの入口にある

システムプロキシとTUNモードはいずれも、接続をClashまたはmihomoに渡し、その後ルールによってプロキシノード、直接接続、拒否を選択できます。本当の違いはルール照合の前にあります。システムプロキシはアプリが自発的にリクエストをローカルプロキシポートへ送るのを待つのに対し、TUNモードは仮想ネットワークインターフェースとシステムルーティングを通じてトラフィックを受け取ります。

そのため、同じサブスクリプション、同じルール、同じノードでも、モードによって結果が変わることがあります。ブラウザーはシステムプロキシで正常にアクセスできるのに、ゲームランチャーだけが直接接続する場合、通常はルールの誤りではなく、ランチャーがOSのプロキシ設定を読み取っていないことが原因です。TUNに切り替えると、その接続がmihomoに入り、初めてルールで処理できるようになります。

比較項目 システムプロキシ TUNモード
トラフィックの入口 アプリがシステムプロキシ設定を読み取り、ローカルのHTTPまたはSOCKSポートへ接続 OSのルーティングによってネットワークパケットを仮想NICへ送る
主な対応範囲 ブラウザー、システムプロキシに対応したデスクトップアプリ ブラウザー、コマンドラインツール、ゲームランチャー、その他のUDPアプリ
必要な権限 通常は一般ユーザー権限のみ サービス、ネットワーク拡張機能のインストール、または管理者権限が必要
UDPの処理 アプリがSOCKS5 UDPを自発的に利用するかどうかによる ネットワーク層からUDPを受け取り、カーネルとノードの対応状況に応じて処理
障害時の影響範囲 プロキシ設定を読み取るアプリが主な影響を受ける ルーティングやDNS設定に問題があると、端末全体の通信に影響する可能性がある
適した用途 Web閲覧、ドキュメント、一般的なデスクトップ作業 システムプロキシを読み取らないアプリ、UDP通信、端末全体の統一的な振り分け

システムプロキシの仕組み：アプリがローカルポートへ自発的に接続

Clashクライアントで「システムプロキシ」を有効にすると、OSに保存されたプロキシアドレスが変更されます。一般的にはHTTPとHTTPSプロキシを 127.0.0.1:7890 に設定します。設定で mixed-port: 7890 を使用すると、同じポートでHTTPとSOCKS5のリクエストを受け付けられます。ポート番号は変更可能で、7890はクライアントでよく使われる初期値にすぎません。

アプリはリクエストを開始する前に、この設定を読み取る必要があります。その後、ブラウザーやデスクトップアプリが 127.0.0.1:7890 に接続し、宛先のドメイン名とポートをプロキシカーネルに伝えます。mihomoはリクエストを受け取ると、DOMAIN-SUFFIX、GEOIP、IP-CIDR、最終ルールなどを順に確認し、対応するポリシーグループを選択します。

通常、システムプロキシを読み取るソフトウェア

  • Chrome、Edge、Safariなど、システムのネットワーク設定を使用するブラウザー。
  • システムのHTTPネットワークAPIを利用する多くのデスクトップアプリ。
  • 「システムプロキシを使用」オプションを明示的に備えたソフトウェア。
  • 環境変数または独自設定でプロキシを指定するコマンドラインツール。

システムプロキシを迂回しやすいソフトウェア

  • 独自のネットワークスタックを実装している、または独自のプロキシ設定を内蔵しているソフトウェア。
  • 一部のゲーム、ゲームランチャー、音声通話アプリ、アップデートサービス。
  • WindowsやmacOSのシステムプロキシ設定を読み取らないコマンドラインプログラム。
  • UDPパケットを直接送信するアプリ。リアルタイム通信アプリやオンラインゲームの一部が該当します。
  • システムサービスとして動作し、独立したネットワークセッションを使用するバックグラウンドプロセス。

コマンドラインツールは特に誤判断を招きやすいものです。たとえばWindowsターミナルで curl を実行した場合、動作はcurlのビルド方式、環境変数、コマンド引数によって変わります。プロキシポートを明確にテストするには、次のコマンドを直接実行します。

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

2つ目のコマンドにある socks5h は、ドメイン名の解決もSOCKS5プロキシ側に任せることを示します。socks5 とだけ書いた場合、curlがローカルで先にドメインを解決し、そのIPへ接続することがあります。両者の違いによって、ドメインルールが適用されるかどうかが変わります。

システムプロキシモードの主なメリット

  1. 有効化と無効化が速く、通常はルーティングテーブルを変更する必要がありません。
  2. LANアクセス、プリンターサービス、仮想マシンのネットワークへの影響が比較的小さい。
  3. 障害の切り分けが明確です。システムプロキシを無効にすれば、他の設定の影響を受けていないアプリは直接接続に戻せます。
  4. サブスクリプション、ノード、ルールグループ、ローカルポートが正常かを最初に確認するのに適しています。

TUNモードの仕組み：仮想NIC、ルーティング、プロトコルスタック

TUNはレイヤー3の仮想ネットワークインターフェースです。有効にするとクライアントが仮想NICを作成し、ルーティングルールによって条件に合うIPv4またはIPv6パケットをそのインターフェースへ送ります。mihomoはTUNインターフェースからIPパケットを読み取り、TCP、UDP、DNSなどの通信を識別して、宛先アドレス、ドメインマッピング、ルールを組み合わせて振り分けます。

システムプロキシが処理するのは、アプリがすでにプロキシリクエストとして組み立てた通信です。一方、TUNが受け取るのはネットワーク層に近い生のパケットです。アプリ側でローカルプロキシポートを意識したり、「プロキシを使用」設定を用意したりする必要はありません。これが、TUNがより多くのソフトウェアをカバーできる理由です。

「全トラフィックを取り込む」ことは、すべてのパケットをプロキシノード経由にするという意味ではありません。LANセグメント、mihomo自身の接続、デフォルトの出口インターフェース、明示的に除外したプロセスはTUNを迂回する必要があります。そうしないとルーティングループが発生する可能性があります。mihomoに入った通信も、ルールに従って DIRECT を選び、ローカルネットワークから直接送信できます。

読みやすいmihomo TUN設定例

mixed-port: 7890
mode: rule

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  strict-route: false
  • enable：TUNインターフェースを有効にします。
  • stack：TUNで使用するプロトコルスタックを選択します。mihomoでは通常 system、gvisor、mixed などを指定できます。利用可能な値は、使用中のカーネルバージョンのドキュメントを確認してください。
  • auto-route：必要なルートを自動設定し、ルーティングテーブルを手動で追加する手間を減らします。
  • auto-detect-interface：Wi-Fiや有線NICなど、現在のデフォルト出口を自動検出します。
  • dns-hijack：53番ポート宛ての従来型DNSクエリを受け取り、mihomoのDNSモジュールで処理します。
  • strict-route：より厳密なルーティング処理を使用します。有効にする前に、仮想マシン、LAN、複数NICの環境を確認してください。

GUIクライアントは通常、これらの項目を自動生成します。Windowsでは「設定」→「システム設定」→「サービスモード」を開き、まずシステムサービスをインストールしてから、「設定」→「ネットワーク設定」に戻ってTUNを有効にするのが一般的です。クライアントによってメニュー名は「Service Mode」「管理者サービス」「仮想NIC」など異なります。macOSクライアントでは通常、ネットワーク拡張機能の追加を求められ、システムアカウントのパスワードを一度入力します。

TUNに高い権限が必要な理由

仮想NICの作成、ルーティングテーブルの変更、DNSの取り込み設定は、いずれもシステムレベルのネットワーク操作です。Windowsクライアントはバックグラウンドサービス、macOSはネットワーク拡張機能、Linuxは CAP_NET_ADMIN またはroot権限を使うことが一般的です。権限の処理が途中までしか完了していないと、画面上はTUNが有効でも、実際のルートが仮想インターフェースを向いていない場合があります。

確認時はスイッチの状態だけを見ないでください。Windowsでは ipconfig と route print を実行し、仮想NICとデフォルトルートの存在を確認します。macOSでは ifconfig と netstat -rn、Linuxでは ip addr と ip route を使用できます。インターフェース名はクライアントとOSによって決まるため、固定名だけで判断しないでください。

DNSは2つのモードで差が出る重要なポイント

システムプロキシモードでブラウザーがドメイン名をHTTPプロキシに渡す場合、mihomoはドメイン名を直接取得し、DOMAIN や DOMAIN-SUFFIX ルールを照合できます。一方、アプリによってはローカルでDNSを先に解決し、IPへ直接接続します。この場合、カーネルに見えるのは宛先IPだけになり、ドメインルールを照合できない可能性があります。

TUNモードは、mihomoのDNSモジュールやFake-IPと組み合わせて使うことがよくあります。DNSクエリがまずmihomoに入り、カーネルがドメイン名に対応するアドレスを返します。アプリがそのアドレスへ接続すると、mihomoが元のドメイン名を復元してルールを適用します。これにより、もともとIPしか見えなかった接続でも、ドメインルールを利用できる範囲が広がります。

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
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

198.18.0.0/15 はベンチマーク用途に予約されたアドレス範囲で、Fake-IPのマッピングによく使われます。リモートサーバーの実IPではありません。接続一覧に 198.18.x.x が表示されても、アプリがそのパブリックアドレスへアクセスしているわけではなく、mihomoがマッピングテーブルを使ってドメイン名を復元している状態です。

Fake-IPのフィルター範囲をむやみに広げない

一部のLAN機器の検出、企業内ネットワーク、ゲームプラットフォームへのログイン、実際のDNS応答に依存するプログラムでは、fake-ip-filter への追加が必要になることがあります。ただし、除外項目が多すぎるとドメインマッピングの範囲が狭まり、再びIPだけで照合されるようになります。問題への対処では、すべての主要トップレベルドメインを除外するのではなく、対象のドメインを個別に追加してください。

60秒の比較テストでDNSがカーネルに入っているか確認する

  1. TUNを無効にし、システムプロキシだけを有効にして、クライアントの接続履歴を消去します。
  2. 対象ソフトを起動して60秒間操作し、接続画面に表示されるドメイン数、IP接続数、ルールのヒット項目を記録します。
  3. 対象ソフトを終了し、TUNを有効にしてから接続履歴を消去し、同じ操作を繰り返します。
  4. 1回目はブラウザーのドメインが少数しかなく、2回目に対象ソフトのプロセス、UDP接続、より多くのドメインが現れた場合、差はトラフィックの入口によるものだと判断できます。

Windows 11とmihomo 1.19系カーネルで比較した例では、あるランチャーはシステムプロキシ使用時、60秒間にWebログイン接続が7件記録されただけで、更新プロセスの34件のTCP接続はシステムNICに直接現れました。TUNを有効にすると、接続画面には関連接続が41件記録され、そのうち36件がドメインルールで処理されました。この数値はテスト方法を示すためのもので、実際の接続数はソフトウェアのバージョン、キャッシュの状態、ネットワーク環境によって変わります。

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

ブラウザーと一般的なデスクトップアプリだけを処理する：まずはシステムプロキシ

主な用途がWeb閲覧、コードホスティング、ドキュメント検索、プロキシ設定に対応したチャットツールなら、システムプロキシが最も手軽です。まずサブスクリプションを更新できること、ノードの遅延を測定できること、ローカルの 7890 ポートが待ち受け中であることを確認し、ルールモードが正しく適用されるかを確認します。この段階で仮想NICやDNSの取り込みを同時に導入する必要はありません。

ソフトウェアにプロキシ設定がない：TUNを使う

ゲームランチャー、ストアクライアント、システム更新コンポーネント、一部のElectronアプリはシステムプロキシを迂回することがあります。接続画面に対象プロセスがまったく表示されない場合、ルールグループを切り替えても効果はありません。その場合はTUNを有効にして通信をまずカーネルへ取り込み、ドメイン、IP、ポート、プロセスルールに基づいて振り分けます。

UDPを処理する必要がある：TUNを優先的に検討

音声通話、リアルタイム通信、オンラインゲーム、QUICベースの接続ではUDPが使われます。従来のHTTPシステムプロキシは任意のUDPパケットを直接受信できませんが、TUNはネットワーク層からUDPを取得できます。その後プロキシノード経由で転送できるかは、プロキシプロトコル、サーバー、クライアントカーネルのUDP対応状況によって決まります。

開発環境とコマンドラインツール：どちらの方式も利用可能

少数のコマンドだけをプロキシ経由にしたい場合は、環境変数を明示的に設定するほうが範囲を管理しやすくなります。

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

Windows PowerShellでは、現在のセッションに次のように設定できます。

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5h://127.0.0.1:7890"

コンテナ、パッケージマネージャー、複数の開発サービスをまとめて振り分ける場合、環境変数を個別に管理するのは複雑になります。その場合はTUNのほうが手順を減らせます。ただし、Docker、WSL、仮想マシン、ホストOSでは異なるネットワークセグメントを使うことがあるため、有効化後はコンテナのDNS、ポートマッピング、LANアクセスを確認してください。

Wi-Fi、有線、テザリングを頻繁に切り替える：自動出口をまず確認

TUNは正しいデフォルト出口に依存します。ネットワークを切り替えた後に通信が途切れた場合は、クライアントの「設定」→「ネットワーク設定」→「インターフェースを自動検出」を有効にするか、設定で auto-detect-interface: true を使用してください。複数NICの端末で自動検出が不安定なら、インターフェースを明示的に指定し、ネットワークが変わるたびにルートを確認します。

TUN有効化後にインターネットへ接続できない場合の対処手順

TUNの障害時に、ノード一覧から何度も切り替えて試すのは効率的ではありません。まず仮想インターフェースとDNSを確認し、その後にルールとノードを確認すると、ローカルネットワークの問題かリモート接続の問題かを早く切り分けられます。

手順1：カーネル、サービス、仮想NICを確認する

  1. クライアントのカーネルがTUNに対応したmihomoバージョンであること、カーネルが正常に起動していることを確認します。
  2. クライアントの「設定」→「システム設定」で、サービスモードまたは管理者サービスがインストール済みか確認します。
  3. TUNを無効にして3秒待ってから再度有効にし、ログに権限、ルーティング、インターフェース作成のエラーが出ていないか確認します。
  4. システムのネットワークインターフェース一覧を確認し、有効化の前後で仮想インターフェースが実際に追加されたか確認します。

手順2：ノードだけを変更せずDNSを確認する

  • nslookup example.com を実行し、名前解決の結果が返ることを確認します。
  • Fake-IPモードで 198.18.x.x が返るのはよくある動作です。
  • DNSがタイムアウトする場合は、53番ポートの取り込み、クライアントのDNS設定、上流DNSアドレスを確認します。
  • ドメイン名では失敗するのにIPアドレスへ直接アクセスできる場合、問題は通常DNS経路にあります。

手順3：ルーティングループを除外する

mihomo自身がプロキシサーバーへ接続する通信は、実際の物理NICから送信されなければなりません。この接続が再びTUNへ送られると、ルーティングループが発生します。auto-detect-interface は多くのシングルNIC環境で利用できますが、VPN、仮想マシン、複数回線、複数のデフォルトルートがある場合は、実際の出口とルートの優先順位を確認してください。

手順4：LANと予約済みアドレスを確認する

ルーターの管理画面、NAS、プリンター、キャスト機器は通常、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 のいずれかにあります。これらの接続は通常、直接接続にします。ルールには明示的に次を追加できます。

- 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

手順5：一時的に変数を減らす

切り分け中は、動作確認済みのノードを1つだけ残し、追加スクリプトや複雑なオーバーライドを無効にして、単純なルールでTCP、UDP、DNSを確認します。基本経路が復旧したら、ルールセット、プロセスルール、DNSフィルターを1項目ずつ戻してください。複数のスイッチを一度に変更すると、どの設定が変化をもたらしたのか判断しにくくなります。

システムプロキシとTUNは同時に有効にできる？

多くのクライアントでは2つのスイッチを同時に有効にできますが、通常は必要ありません。TUNを有効にすると、ブラウザーの通信はすでに仮想NICからmihomoへ入ります。さらにシステムプロキシを有効にすると、ブラウザーはまずローカルプロキシポートへ接続し、そのローカル接続と後続の出口通信がTUNのループを正しく回避しなければなりません。成熟したクライアントはこうした処理を行いますが、入口が2つあるとトラブルの切り分けは難しくなります。

より分かりやすい方法は、段階的に有効にすることです。普段のWeb閲覧ではシステムプロキシだけを使用し、システムプロキシを読み取らないソフトウェアに遭遇したら、システムプロキシを無効にしてTUNだけをテストします。TUNが安定したことを確認してから、クライアントの説明に従ってシステムプロキシを残すか判断してください。切り替え時は接続画面を確認し、同じリクエストが異常な再試行を起こしていないことを確認します。

実際に使える選択チェックリスト

  • ブラウザーの利用が中心：システムプロキシ。
  • 特定のコマンドだけにプロキシを使う：コマンド引数または環境変数。
  • 対象ソフトが接続画面に表示されない：TUN。
  • UDPが必要、または複数アプリを一括処理したい：TUN。
  • 仮想マシン、企業内ネットワーク、複数NICの環境：まずシステムプロキシを使い、その後TUNを小規模に検証。
  • TUN有効化後に通信が切れた：仮想NIC、DNS、ルーティングループ、LANルールの順に確認。

最終的な判断基準は、どのスイッチがより広い範囲をカバーするかではありません。対象の通信が安定してカーネルへ入り、ルールが想定どおり適用され、直接接続が必要なリソースも利用できるかどうかです。システムプロキシは変更の少ないアプリ層での接続に向き、TUNはネットワーク層での一括取り込みに向いています。まず処理したいアプリとプロトコルを明確にして入口を選ぶほうが、ノードを何度も切り替えるより効果的です。

Clash最新版をダウンロード