Clash TUNモードとシステムプロキシの違い：通信の入口・適用範囲・選び方

システムプロキシとTUNは、どちらも同じ入口の問題、つまりデバイスで発生した接続をClashまたはmihomoのコアへ送る方法を解決します。どちらを使っても、特定のWebサイトがプロキシ経由になるか直接接続になるかが自動的に決まるわけではありません。通信がコアに入った後は、現在の動作モード、ルールセット、プロキシグループ、ノードの状態に基づいて処理されます。したがって、「TUNを有効にする」ことはGlobalモードへ切り替えることではなく、「システムプロキシを有効にする」ことも、すべてのアプリが取り込まれることを意味しません。

通信の入口：システムプロキシは設定を参照し、TUNはネットワークパケットを受け取る

システムプロキシの仕組み

システムプロキシを有効にすると、Clashクライアントは通常、OSのHTTP、HTTPS、またはSOCKSプロキシアドレスをローカルループバックアドレスへ変更し、コアのリスニングポートを指定します。たとえばコアが127.0.0.1:7890で動作している場合、システムプロキシに対応したブラウザーやデスクトップアプリはこの設定を読み取り、リクエストをそのポートへ送ります。クライアントでシステムプロキシを無効にすると、以前のOS設定に戻ります。

この方式はアプリケーション層で動作します。アプリがシステムプロキシを読み取るか、OSが提供するネットワークAPIを明示的に利用して初めて、通信がClashへ入ります。一般的なブラウザー、オフィスソフト、一部のデスクトップクライアントはそのまま動作しますが、独自のネットワークスタックを実装しているプログラム、プロキシ設定を無視するプログラム、特定のプロトコルしか対応しないプログラムは直接接続を続ける場合があります。コマンドラインツールにも違いがあり、環境変数を読み取るものもあれば、HTTP_PROXY、HTTPS_PROXY、またはSOCKSアドレスを個別に指定する必要があるものもあります。

TUNモードの仕組み

TUNモードは仮想ネットワークインターフェースを作成し、システムルーティングによって条件に合うIP通信をそのインターフェースへ送ります。mihomoコアは仮想インターフェースからネットワークパケットを読み取り、宛先アドレスとプロトコルを識別したうえで、ルールに従って直接接続、拒否、またはプロキシノードへの転送を判断します。入口がOSのネットワーク層に近いため、アプリは通常HTTPやSOCKSプロキシを理解する必要がなく、システムプロキシ設定を自ら読み取る必要もありません。

そのためTUNは、ゲームランチャー、ターミナルプログラム、一部のストアアプリ、UDPを使用するプログラム、システムプロキシを無視するデスクトップソフトの取り込みに適しています。ただし、TUNの適用範囲はルーティングテーブル、除外設定、コアのプロトコル対応、OSの制限にも左右されます。LANセグメント、デフォルトNIC、仮想マシンのNIC、コンテナネットワーク、別のVPNによって実際の経路が変わる可能性があるため、スイッチの状態だけで取り込み済みと判断することはできません。

4つの重要な違い：適用範囲・プロトコル・DNS・権限

比較項目	システムプロキシ	TUNモード
動作レイヤー	アプリがOSのプロキシ設定を読み取り、ローカルプロキシポートへ接続	仮想ネットワークインターフェースが、システムルーティングを経由したIP通信を受信
アプリの適用範囲	主にシステムプロキシに従うプログラムが対象	システムプロキシを無視するプログラムも、より広く取り込める
プロトコル範囲	アプリが対応するHTTP、HTTPS、SOCKSプロキシ機能に依存	通常はTCPを一元処理し、UDPはコアと設定に応じて処理
DNS経路	アプリ、プロキシプロトコル、ClashのDNS設定に依存	DNSハイジャックや拡張モードと組み合わせて、コアへ一元的に送れる
システム権限	通常はシステムプロキシ設定の変更だけでよい	通常は管理者権限、システムサービス、またはネットワーク拡張が必要
競合の原因	ブラウザー拡張機能、手動プロキシ、古いプロキシアドレス	他のVPN、仮想NIC、セキュリティソフト、ルーティング優先順位

アプリ互換性は単純な「ブラウザーか、それ以外か」ではない

ブラウザーは通常システムプロキシに従いますが、実際の動作はセキュアDNS、QUIC、ブラウザー拡張機能、企業ポリシーの影響も受けます。Chromiumベースのアプリにはシステムのネットワーク設定を共有するものがある一方、独自のプロキシ設定を備えるものもあります。ゲームプラットフォームはランチャー、アップデーター、ログインコンポーネント、ゲーム本体のプロセスで構成される場合があり、すべてのコンポーネントがシステムプロキシを読み取るとは限りません。Webページを開けても、ダウンロード、ログイン、リアルタイム通信まで同じ経路を通っているとは限りません。

TUNモードはより低いレイヤーでこれらの接続を受け取れるため、一般に適用範囲が広くなります。UDP通信を正常に転送できるかどうかは、ノードのプロトコル、プロキシサーバー、ルール、コアの設定にも左右されます。TUNを有効にしても、上流ノードが対応していない機能まで自動的に追加されるわけではありません。

DNS処理はドメインルールを安定して適用できるかどうかを左右する

システムプロキシ環境では、DNSをアプリがローカルで解決する場合もあれば、プロキシプロトコル経由でコアに処理させる場合もあります。プログラムによって挙動は異なります。Clashへ入る前にドメインがIPアドレスへ解決されていると、コアが取得できる情報はドメインのリクエストを直接受け取る場合と異なり、ルールのマッチ結果も変わる可能性があります。ブラウザー独自の暗号化DNS設定によって、OSのDNS経路が迂回されることもあります。

TUNはmihomoのDNSモジュール、dns-hijack、Fake-IP、またはRedir-Hostモードと組み合わせて使われることが多いです。DNSリクエストを先にコアへ入れることで、コアはドメインと後続の接続を関連付けてから、ドメインルールを適用できます。Fake-IPが返すのはローカルマッピング用の仮想アドレスであり、実際の宛先解決とプロキシ選択はコアが引き続き処理します。LAN内のデバイス検出、ゲームプラットフォーム、特殊なDNS応答に依存するアプリでは、Fake-IPの除外リストへの追加、または環境に適した別のDNS拡張モードへの変更が必要になる場合があります。

権限とシステム変更の範囲は異なる

システムプロキシは主にOSに保存されたプロキシアドレスを変更するため、必要な権限は比較的少なくて済みます。TUNでは仮想インターフェースの作成とルーティングの変更が必要です。そのためWindowsクライアントでは管理者権限やバックグラウンドサービスを使うことが多く、macOSではネットワーク拡張の承認が求められる場合があります。AndroidとiOSでは通常、システムVPNインターフェースを利用して通信を取り込みます。初回有効化時に権限確認が表示されるのは、ネットワークの入口を構築するための正常な手順です。

権限の許可後も、サービスが実際に起動しているか確認する必要があります。クライアント画面でTUNが有効と表示されても、ルートの追加、DNSハイジャック、デフォルトインターフェースの認識がすべて成功しているとは限りません。mihomoのログにあるインターフェース作成、ルーティング設定、リスニングエラーの情報は、スイッチだけを見るより判断材料になります。

選び方：デバイスとアプリの対象範囲で判断する

日常のブラウジングと仕事：まずはシステムプロキシ

主な用途がブラウザー、ドキュメント同期、システムプロキシに従うデスクトップアプリであれば、システムプロキシが通常は最も手軽です。ルーティングテーブルへの影響が小さく、オン・オフの経路も明確で、アプリがプロキシを自発的に使っているか確認しやすくなります。問題が起きたときも、仮想NICやルーティング競合を同時に扱う必要はなく、まずローカルポート、OSのプロキシアドレス、プロキシグループを確認できます。

ゲーム、コマンドライン、独自ネットワークスタック：まずTUNを確認

アプリがシステムプロキシを明確に無視する場合や、UDP、アップデーター、子プロセス、独立したログインコンポーネントを含む場合は、TUNを主な取り込み入口として使えます。よくある例は、ターミナルのパッケージマネージャーがプロキシ変数を読み取らない、ゲームプラットフォームではダウンロードできるのにゲーム本体は直接接続する、ストアアプリがシステムプロキシを利用できない、同じプログラム内でもコンポーネントごとに経路が異なる、といったケースです。

モバイルデバイス：通常はシステムVPNインターフェースがTUNの役割を担う

モバイルOSのWi-Fi手動プロキシは通常、現在接続している無線ネットワークにだけ適用され、アプリがその設定に従うかどうかもアプリ側の実装に依存します。モバイル通信では、このWi-Fiプロキシ設定は使用されません。デバイス全体の通信を取り込む必要がある場合、Clashまたはmihomoに対応したクライアントは一般にシステムVPNインターフェースでトンネルを構築します。ステータスバーにVPNが表示された後も、実際に接続がルールで処理されているかクライアントのログで確認してください。

開発環境、仮想マシン、コンテナ：まずルーティング境界を確認

仮想マシンやコンテナには、独立したNIC、ゲートウェイ、またはネットワーク名前空間があるのが一般的です。ホスト側でTUNを有効にしても、ゲストの通信がそのインターフェースに入るかどうかは、ブリッジ、NAT、デフォルトルートの関係によって決まります。コンテナからホストのループバックアドレスへ接続する場合、127.0.0.1はコンテナ自身を指し、ホスト上のClashポートを意味するわけではありません。このような環境では、まずホスト、仮想NIC、コンテナブリッジ、出口NICの間の経路を図にしてから、TUN、LANリスニング、アプリケーション単位のプロキシのどれを使うか決めてください。

システムプロキシとTUNは同時に有効にすべきか

多くの場合、主な入口を1つに絞ったほうが切り分けやすくなります。TUNで対象アプリを安定して取り込めているなら、システムプロキシは必須ではありません。ブラウザーと一般的なデスクトップアプリだけを使う場合も、適用範囲を広げるためにTUNを常時有効にする必要はありません。一部のクライアントでは両方を同時に動かせますが、コアがローカル接続やルート除外を処理する一方、複雑な環境では通信の迂回、ループ、実際の入口を判断しにくい問題が起こることがあります。

同時に有効にする場合は、システムプロキシが現在のコアのポートを指していること、TUNで必要なローカルアドレスが除外されていることを確認し、同じ接続がログ上で一度だけ受信されているか確認してください。取り込み方式を切り替えてテストするときは、古い入口を先に無効にしてから新しい入口を起動し、残ったシステムプロキシや古いルートが結果に影響しないようにするのがおすすめです。

設定の順序：まず設定を検証し、取り込み範囲を広げる

サブスクリプションを更新する。設定が正常に読み込まれ、プロキシノードとプロキシグループが表示されていることを確認します。サブスクリプションのエラーを、通信の取り込み失敗と取り違えないようにしてください。
ルールモードを選ぶ。日常利用ではまずRuleに設定し、デフォルトのプロキシグループに利用可能なノードがあることを確認します。GlobalとDirectは一時的な問題の切り分けには使えますが、TUNの動作確認だけを判断する唯一の基準には適しません。
まずシステムプロキシをテストする。システム設定に従うブラウザーでシステムプロキシを有効にし、対象サイトへアクセスします。Clashの接続履歴にドメイン、ルール、プロキシグループが表示されるか確認してください。
取り込まれていないアプリを特定する。特定のプログラムに接続履歴がまったくない場合は、独自のプロキシ設定を備えているか、環境変数が必要か、UDPや独自のネットワークスタックを使用しているか確認します。
次にTUNを有効にする。システム権限の確認を完了し、仮想インターフェース、自動ルーティング、デフォルトNICの認識、DNS設定を確認します。
他のネットワークツールを1つずつ戻す。まず単一のネットワーク環境で検証し、その後に他のVPN、仮想マシン、セキュリティソフトを起動して、ルーティング競合の原因を特定しやすくします。

mihomoの設定でよく使われるTUNの基本構成は次のとおりです。クライアントによってはGUIからこれらの項目が生成されます。実際に利用できる項目は、クライアントに組み込まれたコアのバージョンに依存します。

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
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

auto-routeは必要なルートを自動的に追加し、auto-detect-interfaceは現在のデフォルト出口を検出します。dns-hijackは対象のDNSリクエストをコアへ送ります。stackで利用できる値や実装は、コアのバージョン、OS、クライアントのラッパー方式によって変わります。現在のバージョンを確認せず、クライアントが生成した設定を丸ごとコピーして上書きしないでください。

システムプロキシ側では、主にリスニングポートを確認します。設定でmixed-portを使用すると、同じポートで一般的なHTTPとSOCKSプロキシ接続を受け付けられます。クライアントがシステム設定に書き込むポートは、コアが実際に待ち受けている値と一致していなければなりません。設定のポートを変更したのにOS側に古いポートが残っていると、システムプロキシに従うアプリは突然すべて接続できなくなり、TUNで取り込まれているプログラムだけが使える状態になることがあります。

トラブルチェック：入口・DNS・ルール・出口の4層で切り分ける

第1層：通信がコアへ入っているか

クライアントの接続一覧またはリアルタイムログを開き、対象アプリを起動します。新しい接続がまったくない場合は、まずシステムプロキシアドレス、TUNサービスの状態、アプリ独自のプロキシ、ルーティングテーブル、ファイアウォールを確認します。この段階でノードを交換する必要はありません。ノードが影響するのは、すでにコアへ入り、プロキシポリシーが割り当てられた接続だからです。

第2層：ドメインが正しく解決されているか

接続履歴にIPアドレスしか表示されない、ドメインルールがマッチしない、またはドメイン解決時にアプリがタイムアウトする場合は、DNSモジュールが有効か、TUNのDNSハイジャックが機能しているか、ブラウザーが独自のセキュアDNSを使っていないか、Fake-IPの除外ルールが広すぎないか確認します。LAN内のドメインやデバイス検出プロトコルでは、ローカルの名前解決経路も残す必要があります。

第3層：ルールとプロキシグループが正しく選ばれているか

通信は表示されているのに想定と異なる経路を通る場合は、最終的にマッチしたルール、プロキシグループ、ノードを確認します。ルールは通常、設定に記載された順番で適用されるため、広すぎるルールを前に置くと後続の精密なルールが上書きされることがあります。サブスクリプションの更新でプロキシグループの選択が再構成される場合もあるため、現在グループ内で選択されているノードを再確認してください。

第4層：ノードと物理ネットワークに到達できるか

ルールがプロキシにマッチしているのに接続がタイムアウトする場合は、出口側を確認します。ノードの状態、ノードプロトコルのTCP・UDP対応、現在のネットワークによる対象ポートの制限、デフォルト出口NICが正しいかを順番に確認してください。有線ネットワークからWi-Fiへ、またはWi-Fiからモバイルホットスポットへ切り替えた後は、TUNがデフォルトインターフェースを再検出する必要がある場合があります。

まとめ：現在のデバイスに必要な最小限の範囲で取り込む

システムプロキシはアプリがOS設定を自発的に読み取る方式で、構成がシンプルなため、ブラウザーや一般的なデスクトップソフトに適しています。TUNは仮想インターフェースでネットワークパケットを受け取るため適用範囲が広く、システムプロキシを無視するアプリ、UDPを使うアプリ、複数のネットワークコンポーネントを含むアプリに適しています。一方で、権限、ルーティング、DNS、仮想NICの競合に関する確認項目は増えます。

どちらか一方のモードを常に選ぶ必要はありません。まずシステムプロキシでサブスクリプション、ノード、ルールの経路を検証し、対象アプリがコアへ入っていないことを確認してからTUNを有効にし、取り込み範囲を広げます。どちらの入口を使う場合も、接続ログで通信がコアへ入っていることを確認し、DNS、ルール、プロキシグループ、実際の出口を引き続き確認してください。この4層に沿って調べるほうが、スイッチを切り替えるだけより具体的な故障箇所を見つけやすくなります。