ClashのTUNモードとシステムプロキシの違い｜通信の取り込み方と使い分け | Clash之家

システムプロキシとTUNの違いは、通信がカーネルに届くまでの経路

どちらを有効にするか判断するには、まず2つの問題を分けて考えましょう。アプリの通信がClashのカーネルに届くか、届いた通信がどのルールで処理されるかです。システムプロキシとTUNが主に担うのは前者です。ルールモードやグローバルモード、プロキシグループの選択が担うのは後者です。TUNを有効にしても、すべての通信がプロキシノードを経由するわけではありません。システムプロキシを有効にしても、すべてのアプリがその設定を参照するわけではありません。

この記事では、デスクトップクライアントと、Clash Metaの後継として開発が続くmihomoカーネルを主な説明対象とします。クライアントによってスイッチの名称、権限の要求、設定のマージ方法は異なります。また、旧版のClashカーネルが同じTUN設定項目に対応しているとは限りません。クライアント名だけで判断せず、カーネル情報で実際に動作中のカーネルを確認してから設定と照らし合わせるのが確実です。

システムプロキシ：アプリからローカルポートへ接続する

システムプロキシを有効にすると、通常はOSのプロキシ設定がローカルの待ち受けアドレス（例：127.0.0.1:7890）に変更されます。この設定に従うブラウザーやデスクトップアプリはそのアドレスに接続し、カーネルがHTTPプロキシのリクエストやHTTPSのCONNECTトンネルを受け取ります。その後、ルールに応じて直接接続するか、ノード経由で転送するかが決まります。

ポイントは「アプリが設定に従うか」です。Windowsのユーザープロキシ設定とWinHTTPの設定は別物です。バックグラウンドサービス、一部のアップデーター、コマンドラインツールは別の設定を使うことがあります。Linuxデスクトップ環境のプロキシ設定も、すべてのプログラムに適用される強制的な入口ではありません。そのため、ブラウザーで接続できても、ターミナルやゲーム、バックグラウンドプロセスの通信まで取り込めているとは限りません。

TUNモード：仮想NICとルーティングでIP通信を受け取る

TUNは仮想的なL3ネットワークインターフェースを提供します。クライアントやカーネルがインターフェースを作成してルートを設定すると、条件に合うIPパケットがTUNに入り、カーネルで処理されます。アプリ側でローカルプロキシのポートを意識したり、HTTPプロキシ設定に対応したりする必要は通常ありません。コマンドラインツールやゲーム、UDPを使うアプリまで対象にしやすいのはこのためです。

ただし、「より多くの通信を取り込める」ことは、無条件にすべての通信を処理できるという意味ではありません。ルートの除外、特定インターフェースにバインドされた接続、IPv6の設定、別のVPN、LAN通信などによって結果は変わります。また、TUNはイーサネットブリッジではありません。ブロードキャストによる機器検出や、すべてのL2プロトコルがプロキシノード経由で送信できると考えるのは誤りです。

対応範囲を比較：ブラウザー、コマンドライン、ゲーム、UDP

よくある用途と通信を取り込む条件
用途	システムプロキシ	TUNモード
ブラウザーでのWeb閲覧	ブラウザーがシステム設定に従うなら、通常はこれで十分です。	ルーティング対象の通信を取り込めます。DNSとQUICの動作も確認しましょう。
curl、Gitなどのコマンドラインツール	自動で有効になるとは限りません。プロキシアドレスを明示できます。	通常はツールごとの設定は不要ですが、ルートと実行環境の確認が必要です。
ゲーム、ボイスチャット	HTTPシステムプロキシを参照しないアプリが多く、対応範囲は限られます。	TUNに入ったTCP・UDP通信を処理できます。ノード側も対応している必要があります。
コンテナ、仮想マシン、WSL	それぞれの環境内でプロキシを設定する必要がある場合があります。	仮想ネットワークの構成次第です。ホスト側の設定だけですべてを取り込めるとは限りません。
LANへのアクセス	システムプロキシの例外リストでプロキシを経由しない設定にできます。	ルートの除外設定とカーネルのDIRECTルールを確認してください。

UDPが使えるかどうかは、TUNのスイッチだけでは決まりません

一般的なHTTPシステムプロキシでは、任意のアプリのUDP通信を自動的にノード経由にできません。SOCKS5にはUDP転送の仕組みがありますが、アプリとローカルの接続先の両方が対応し、実際に利用する必要があります。システムにHTTPプロキシアドレスを設定しただけでは、この経路は使えません。

TUNはルーティング条件に合うUDPパケットをカーネルに渡せますが、その後の通信は出力プロトコル、ノード設定、接続先サーバー、ファイアウォールにも左右されます。udp: trueを設定しても、もともとUDPに対応していない出力経路に機能が加わるわけではありません。ゲームにはログインできるのにボイスチャットが使えない場合は、Webページだけで確認せず、音声通信を個別に調べてください。

用途に合わせて選ぶ：まずシステムプロキシ、足りない分をTUNで補う

Web閲覧や一般的なデスクトップアプリ：まずはシステムプロキシ

主な用途がWeb閲覧で、ブラウザーがシステムプロキシ設定に従うなら、まずTUNをオフにしてシステムプロキシとルールモードを使ってみましょう。変更範囲を抑えられ、問題が起きた場合も、ローカルポート、ルール、ノードのどこに原因があるか切り分けやすくなります。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」でプロキシサーバーを確認できます。macOSでは「システム設定」→「ネットワーク」→現在のネットワーク接続→「詳細」→「プロキシ」を確認してください。項目名はOSのバージョンによって多少異なります。

ローカルアドレスは通常127.0.0.1ですが、ポート番号はクライアントの実際の設定を確認してください。この記事では例として7890を使っていますが、すべてのクライアントで共通の既定値ではありません。クライアントが別のポートで待ち受けている場合は、システムプロキシ、ターミナルの環境変数、アプリ内の手動設定も合わせて変更してください。

ターミナルや開発ツール：必要な通信だけ明示的にプロキシを指定

1回のダウンロードだけをプロキシ経由にしたい場合は、コマンドに接続先を指定すれば、すぐに端末全体の通信を取り込む必要はありません。次のコマンドは、ローカルHTTPプロキシを経由してHTTPSトンネルを確立できるか確認するものです。Windows PowerShellではcurl.exeと入力すると、旧環境で同名のエイリアスが使われる問題を避けられます。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

この方法で確認できるのは、指定したプロキシ入口でそのリクエストを送れることだけです。ゲームやほかのターミナル上の処理まで取り込まれていることは確認できません。HTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を使う場合は、ツールが該当する変数に対応しているか、またNO_PROXYで接続先が除外されていないかも確認してください。変数名のHTTPSは通常、接続先へのリクエスト種別を表します。ローカルプロキシのアドレスを必ずhttps://にする必要はありません。

ゲーム、ボイスチャット、プロキシ非対応アプリ：必要に応じてTUNを検討

アプリがシステムプロキシを参照せず、使えるプロキシ設定もない場合は、TUNで通信の取り込み範囲を補うのが適しています。有効にする前に、仮想NICの作成やルート変更に必要な権限をクライアントが取得できるか確認してください。Windowsではサービスモードや昇格した権限で処理する場合があります。macOSやLinuxでは補助プログラムと権限の仕組みによって異なります。どのOSでも、画面全体を常に管理者権限で実行しなければならないとは限りません。

2つの入口を同時に有効にすることもできますが、最初の切り分けでは個別にテストするのがおすすめです。システムプロキシが有効だと、TUNで通信を取り込めていなくてもブラウザーはローカルポート経由で動作し、「Webは使える」状態になることがあります。TUNの動作を確認する場合は、いったんシステムプロキシをオフにし、テストするアプリ自身のプロキシ設定も解除してから、接続ログを確認してください。

mihomoのTUN設定：ルーティング、DNS、ルールの役割

以下は設定項目を理解するための一部抜粋です。該当項目に対応したmihomoカーネル向けであり、単独で動作する完全な設定ファイルではありません。クライアントの画面上のスイッチが同名の項目を生成または上書きすることがあります。変更前に設定をバックアップし、変更後は最終的に適用された設定を確認して、サブスクリプションの更新で手動設定が上書きされないようにしてください。

mixed-port: 7890
mode: rule

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

mixed-port：1つの待ち受けポートでHTTPとSOCKSの接続を受け付けます。明示的にプロキシを指定した接続に使うもので、TUNの仮想NIC用ポートではありません。
stack: mixed：カーネルが対応するTUNのプロトコルスタック実装を選びます。ルールモードの「グローバル」とは関係ありません。利用できる値とプラットフォームごとの動作は、使用中のカーネルのドキュメントで確認してください。
auto-route：TUNのルートを自動設定するよう要求します。インターフェースが作成されても、ルートが正しく登録されたとは限りません。ログとシステムのルーティングテーブルも確認してください。
auto-detect-interface：外向き通信に使うネットワークインターフェースの自動検出を試みます。複数のNIC、別のVPN、特殊な仮想ネットワーク環境では、意図しないインターフェースが選ばれることがあります。
dns-hijack：指定した接続経路に入ったDNS通信をカーネルのDNS処理に渡します。例では一般的なUDP 53とTCP 53を対象にしていますが、すべての名前解決を捕捉するわけではありません。

DNSは別途設定が必要

上記の抜粋には、完全なdns設定が含まれていません。実際に使う際は、カーネルDNSが有効になっているか、上流のDNSリゾルバーに接続できるか、fake-ipやredir-hostなどの名前解決モードが既存の設定と互換性があるかを確認してください。fake-ipでよく使われるアドレス帯は198.18.0.0/16です。これは接続を紐付けるためのアドレスであり、接続先Webサイトの実サーバーのアドレスではありません。

ブラウザーのセキュアDNS、アプリ内のDoHやDoTは、53番ポートを監視しているだけで通常のDNSクエリとして自動処理されるわけではありません。ドメインルールが適用されない、または名前解決の結果がおかしい場合は、まずどこで名前解決が行われているか確認してください。そのうえでブラウザー設定やカーネルのDNSルールを調整しましょう。名前解決の問題を隠すためにノードを何度も切り替えるのは避けてください。

通信を直結するかプロキシ経由にするかは、引き続きルールで決まる

通信がカーネルに入った後も、ルールモードでは設定に従ってポリシーが適用されます。ドメインルール、IPルール、末尾のフォールバック用MATCHによって接続先が決まります。TUNがこの処理を迂回することはありません。ドメインをルール判定に使えるかどうかは、DNSマッピングやスニッフィングなどの仕組みにも左右されます。宛先IPしか分からない通信でも、必ず元のドメインを復元できるとは限りません。

LANプリンター、NAS、社内ネットワークでは、通常、直接接続できる経路を残しておく必要があります。たとえば192.168.1.10に接続する場合、正しく除外されているか、DIRECTルールに一致しているかを確認してください。自動ルートの影響でパケットがカーネルに届いていない場合、カーネル内のルールを変更しても接続は変わりません。まず問題が発生している層を特定してください。

再現性のある切り分け：入口の問題、ルールの誤り、ノードの問題を区別する

基本情報を記録する。ローカルポート、稼働中のカーネル、使用中のプロキシグループ、接続先ドメインを書き留めます。まず固定した接続先をブラウザーで開き、テストのたびにノード、DNS、通信の取り込み方式を同時に変更しないでください。
システムプロキシだけをテストする。TUNをオフにし、システムプロキシを有効にして、前述のプロキシ指定コマンドでも確認します。コマンドでは接続できるのにブラウザーで失敗する場合は、ブラウザー独自のプロキシ設定、システムの例外リスト、拡張機能の設定を優先して確認してください。
TUNだけをテストする。システムプロキシをオフにし、テストするアプリ内のプロキシ設定を解除してからTUNを有効にし、新しい接続を開始します。ログに接続先、ネットワーク種別、一致したルール、出力先ポリシーが記録されるか確認してください。
ルートと名前解決を確認する。Windowsではroute print、Linuxではip routeとip rule、macOSではnetstat -rnを確認できます。仮想NICのアイコンだけで通信の取り込みに成功したと判断しないでください。
UDPは個別に確認する。実際のゲームやボイスチャットで接続し、クライアントの接続一覧から該当するUDPセッションを探してください。Webページの表示やICMPのping結果は、プロキシ経由のUDP通信のテストにはなりません。

明示的なプロキシ設定を除外したい場合は、次のコマンドを使えます。ただし、--noproxy "*"が無効にするのはcurlの明示的なプロキシ経路だけです。TUNが有効なら、システムのルーティングによって通信がカーネルに入る可能性があります。「直接接続を保証する」コマンドではありません。

curl --noproxy "*" --connect-timeout 10 -I https://example.com

古い接続を明示的に切断してから、もう一度テストしてください。ブラウザーの接続プール、ゲームの持続接続、DNSキャッシュには、切り替え前の状態が残っていることがあります。スイッチを切り替えた後も既存の接続が続いているからといって、新しい接続も同じ経路を通るとは限りません。

よくある問題：権限、VPNとの併用、終了後のネットワーク復旧

TUNを有効にしたら、端末全体がインターネットに接続できなくなったのはなぜ？

まずTUNをオフにして元の状態に戻し、カーネルログ、DNSの上流サーバー、ルーティングを個別に確認してください。仮想インターフェースは作成されていてもカーネルが通信を正常に処理できない場合や、誤った出力インターフェースにルートが向いている場合、通信が途切れることがあります。既知のIPアドレスには応答するのにドメイン名で接続できない場合は、まずDNSを調べてください。これは原因を絞る手がかりであり、すべてのサービスで使える接続テストではありません。

TUNと会社のVPNは同時に使えますか？

ルーティング、DNS、セキュリティポリシーによって異なり、併用できるとは限りません。両方のプログラムがデフォルトルートを書き換えると、設定が上書きされたり、通信経路に問題が起きたりすることがあります。まずそれぞれ単独で動作を確認し、社内ネットワークのアドレス帯、デフォルトルート、DNSが変更されていないか調べてください。組織管理の端末では定められたネットワークポリシーに従い、ルートの削除やセキュリティ設定の変更を安易に行わないでください。

クライアントを終了したのに、ブラウザーでプロキシ接続エラーが出るのはなぜ？

システムプロキシが、停止済みの127.0.0.1:7890を指したままになっている可能性があります。システムプロキシ設定にそのアドレスが残っていないか、ブラウザー独自のプロキシ設定がないか確認してください。TUNが原因の場合は、クライアントを再起動してTUNを正常にオフにし、ルートをクリーンアップさせてください。ネットワーク構成を把握しないまま、仮想NICやシステムルートをまとめて削除するのは避けましょう。

TUNモードはシステムプロキシより必ず速い？

必ず速くなるわけではありません。両者の主な違いは通信を取り込む範囲です。実際の速度はノードの帯域、経路の混雑、パケットロス、DNS、MTU、端末の処理性能にも左右されます。接続先、ノード、時間帯、通信種別をできるだけ揃えた場合にのみ、有意な比較ができます。TUNによって、これまでカーネルに届かなかったアプリにプロキシ経路が加わるのは、対応範囲の変化です。同じ通信経路が高速化したことを意味するわけではありません。

使い分けはシンプルです。Web閲覧にはシステムプロキシ、少数のコマンドライン処理にはプロキシの明示設定を使い、プロキシ非対応アプリやUDP通信も対象にする場合はTUNを有効にします。一度に変更するのは1項目だけにし、接続ログで入口とルールを確認してからノードの品質を判断しましょう。すべてのスイッチを同時に有効にするより、原因を特定しやすくなります。