Clash TUNモードの設定方法：全通信を取り込む仕組みと設定チェック

TUNモードで解決できる問題

通常のシステムプロキシは、アプリがOSのプロキシ設定を自ら読み取ることを前提とします。ブラウザー、一部のダウンロードツール、一般的なデスクトップアプリは、この方法でHTTPまたはHTTPSリクエストをClashに渡せます。一方、ゲームランチャー、コマンドラインプログラム、単独のアップデーター、独自のネットワークスタックを使うアプリは、対象アドレスへ直接接続することがあります。この場合、システムプロキシを有効にしていても、通信はClashを経由しません。

TUNモードは仮想ネットワークインターフェースを作成し、OSに対応するルートを書き込みます。ルーティング条件に一致するIPパケットはいったん仮想インターフェースへ入り、Clashまたはmihomoカーネルが接続先を識別してルールを照合し、直接接続かプロキシ出口かを選択します。ネットワーク層の入口で通信を取り込むため、通常はシステムプロキシより広い範囲をカバーできます。

「TUNによる取り込み」とClashの「グローバルモード」は同じ設定ではありません。TUNは通信をカーネルへ入れられるかを決め、ルール、グローバル、ダイレクトなどの動作モードは、カーネルに入った後の出口を決めます。TUNを有効にしたままルールモードを使い、中国本土のアドレスを直接接続にしたり、指定ドメインだけをプロキシ経由にしたりできます。切り分けのため、一時的にグローバルモードへ切り替えることも可能です。

仮想ネットワークインターフェースで通信を取り込む実際の経路

アプリが接続を開始すると、OSはまずローカルのルーティングテーブルを参照します。TUNが有効で自動ルーティングが機能している場合、クライアントは仮想インターフェースを指すルートを追加しつつ、LAN、デフォルトゲートウェイ、必要なシステムアドレスへの到達経路を保持します。パケットがTUNインターフェースに到達すると、カーネルが接続情報を復元し、対象をルールエンジンに渡します。

アプリがドメイン名の名前解決を要求すると、DNSクエリはシステムリゾルバーまたはClashのDNSモジュールに入ります。
OSはルーティングテーブルに従い、対象接続を仮想ネットワークインターフェースへ送ります。
Clashはドメイン名、対象IP、ポート、プロセス情報、ルールセットなどに基づいて照合します。
一致したプロキシグループが、具体的なプロキシノードまたは直接接続の出口を選択します。
外向きの接続は実際のネットワークインターフェースから送信され、応答データは仮想インターフェースを通ってアプリへ返されます。

この経路では、DNSとルーティングの整合性が重要です。外部DNSで直接名前解決し、ルールがドメイン分類に依存している場合、カーネルに見えるのは解決後のIPだけとなり、想定したドメインルールに一致しないことがあります。mihomoのFake-IP拡張モードでは、DNSモジュールがドメインに管理対象の仮想アドレスを返し、内部にドメインと接続の対応関係を保存します。アプリがそのアドレスへ接続すると、カーネルは元のドメインを復元してからドメインルールを適用できます。

Fake-IPは、すべての環境で固定的に選ぶものではありません。LAN機器の検出、一部のゲーム、企業内ネットワークのドメイン、実アドレスによる判定に依存するプログラムでは、除外リストへの追加が必要になる場合があります。クライアントが対応していればRedir-Hostへ変更することもできます。ドメインルールの識別が安定するか、LANサービスへ到達できるかを基準に選択してください。

有効化前にカーネル、サブスクリプション、権限を確認する

まず、クライアントが使用するカーネルがTUNに対応しているか確認します。現在よく使われるmihomoカーネルは、TUN、自動ルーティング、インターフェース自動検出、多様なプロトコル処理に対応していますが、グラフィカルクライアントによってスイッチ名は異なります。TUNを「設定」や「サービスモード」に配置しているクライアントもあれば、先にシステムサービスのインストールを求めるものもあります。更新が止まった旧クライアントでは古いカーネルが使われている可能性があり、設定項目やOSとの互換性も異なります。

1. 有効なサブスクリプションを更新して読み込む

TUNは通信の入口を変えるだけで、無効なノードを修復するものではありません。有効化する前にサブスクリプションを手動更新し、現在の設定が読み込まれていることを確認して、プロキシグループで接続可能なノードを選びます。まずシステムプロキシでブラウザーへの接続をテストしてください。通常のプロキシでも接続できない場合は、サブスクリプションURL、ノードの状態、プロキシグループの選択、本機のネットワークを先に確認します。

2. システム権限を準備する

仮想ネットワークインターフェースの作成やルートの変更には、通常より高い権限が必要です。Windowsクライアントではサービスコンポーネントのインストールや、初回設定時の管理者権限が必要になることがあります。macOSではネットワーク拡張機能またはVPN構成の許可が表示され、Androidクライアントでは通常、システムVPNインターフェースで通信を取り込み、VPN接続の確認画面が表示されます。許可した後は、システムのポップアップだけで判断せず、クライアントに戻ってTUNの状態を確認してください。

3. 既存のネットワーク設定を記録する

有効化する前に、使用中のVPN、仮想マシンのネットワークインターフェース、会社のセキュリティクライアント、DNSツール、デフォルトゲートウェイを記録します。複数のプログラムがデフォルトルートやDNSを同時に変更すると、後から起動したものが先に起動したものを上書きすることがあります。切り分けでは、一度に通信を取り込むツールを1つだけ残し、基本経路を確認してから他のプログラムを順番に戻します。

Clash TUNモードを有効にする手順

クライアントによって画面上の名称は異なりますが、基本的な流れはほぼ同じです。以下の順序は、mihomoカーネルを使う一般的なデスクトップクライアントに適用できます。グラフィカルなスイッチがある場合は、まず画面から変更してください。YAMLを直接編集する前に、クライアントが設定保存時に該当部分を上書きしないことを確認します。

クライアントを起動して現在のサブスクリプションを更新し、設定ファイルに解析エラーがないことを確認します。
プロキシまたはプロキシグループの画面で接続可能なノードを選び、動作モードを「ルール」にします。
設定画面を開き、TUN、仮想ネットワークインターフェース、または通信取り込みに関する項目を探します。
画面でサービスモード、補助サービス、ネットワーク拡張機能のインストールを求められた場合は、先にインストールとシステムの許可を完了します。
TUNを有効にして自動ルーティングをオンにします。インターフェース自動検出に対応している場合は、同時に有効にして構いません。
クライアントのステータス欄を確認し、TUNが実行中であることを確認します。「許可待ち」や「起動失敗」のままではいけません。
システムプロキシを無効にしてカバレッジテストを行い、これまでプロキシを読み取らなかったアプリでもルールに従って接続できるか確認します。

以下は、mihomo設定の項目間の関係を説明するための断片です。実際に使用できる項目は、クライアントに組み込まれたカーネルのバージョンによって異なります。グラフィカルクライアントが生成する設定は、画面表示とログを優先してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

enable はTUNを起動するかどうかを制御します。auto-route はカーネルに必要なルートを自動追加させ、auto-detect-interface は現在の実際の外向きインターフェースを識別します。stack はTUNパケットで使用するネットワークスタックの実装を決めます。クライアントによってはsystem、gVisor、mixedなどを選べますが、対応状況はプラットフォームとカーネルのバージョンによって変わります。通常はクライアントのデフォルト値を使い、特定のUDP、性能、互換性の問題がある場合だけ切り替えます。

例に示したパブリックDNSは、項目の構造を示すためだけのものです。実際の環境では、ローカルネットワークからアクセスできる名前解決サービスを使うか、サブスクリプションとクライアントの説明に従ってDoHやDoTを設定します。重要なのは、DNSリクエストが安定してリゾルバーへ届き、ルールの照合経路と整合していることです。

DNS、ルーティング、ルールで通信の取り込み結果を確認する

スイッチが有効になっていても、すべての経路が正常とは限りません。クライアントのログ、DNSとルーティング、具体的なアプリの順に段階的に確認します。これにより、仮想ネットワークインターフェースが起動していないのか、ルールが誤った出口を選んだのか、対象アプリ自身に制限があるのかを切り分けられます。

クライアントのログを確認する

TUNを起動した後、ログに権限不足、インターフェース作成失敗、ルート書き込み失敗、ポート競合がないか確認します。続いて対象アプリを開き、対応する接続記録が現れるか確認します。記録がまったくない場合は、通信がTUNに入っていないことが多いです。記録はあるのに接続できない場合は、ルールの一致、ノードの状態、DNSを引き続き確認します。

ドメイン名の名前解決を確認する

システムDNSクエリを1回実行し、結果が返るか確認します。Fake-IPモードでは、一部の一般的なドメインが設定範囲内の仮想アドレスを返すことがあります。これはマッピング処理の一部であり、対象サーバーの実アドレスが変わったことを意味しません。すべてのドメインがタイムアウトする場合は、DNSの待受、上流リゾルバー、ファイアウォール、他のDNSソフトを確認します。

ルールの一致を確認する

接続一覧またはログでテスト対象のドメインを見つけ、想定したルールとプロキシグループに一致しているか確認します。ルールモードでは、最終ルールが、それ以前のルールに一致しなかった接続を処理することが一般的です。最終ルールが直接接続を指している場合、TUNが通信を取り込んでいても、その接続はローカルネットワークから直接送信されます。

TCP、UDP、LANを個別にテストする

ブラウザーのアクセスで確認できるのは主にTCPとDNSで、すべてのケースを網羅できません。UDPを必要とするアプリもテストし、ルーターの管理アドレス、プリンター、LANサービスにもアクセスします。外部接続は正常なのにLANへ到達できない場合は、LANアドレスが自動ルーティングに誤って取り込まれていないか、クライアントにプライベートアドレスをバイパスする設定があるか確認します。

結果を確認する	優先して確認する項目	対処の方向性
TUN起動直後に停止する	権限、サービスコンポーネント、仮想ネットワークインターフェース	権限を再付与し、起動ログを確認する
アプリの接続ログがない	自動ルーティング、デフォルトインターフェース、他のVPN	通信取り込みツールを1つに戻し、ルートを再構築する
ログには接続があるがドメインがタイムアウトする	DNSの待受と上流リゾルバー	DNS設定とファイアウォールルールを確認する
ブラウザーは正常だがゲームに接続できない	UDP、ネットワークスタック、ゲームプロセスのルール	UDPログを確認し、別のスタックでもテストする
外部ネットワークは正常だがLANに接続できない	プライベートアドレスのルーティング、インターフェース選択	LANバイパスと自動ルーティングを調整する

よくある競合と復旧の順序

TUNの異常は、権限、DNS、ルーティング、アプリ競合の4つの層で発生することが多いです。対処時は決めた順序を守り、いきなりクライアントを再インストールしないでください。各手順の後に再テストし、ログに変化があるか確認します。

TUNを有効にすると端末がインターネットへ接続できない

まずTUNを無効にし、基本ネットワークが復旧するか確認します。次に選択中のプロキシノードと最終ルールを確認します。直接接続とプロキシ接続の両方が失敗する場合は、DNSが現在到達できないアドレスに設定されていないか確認します。基本ネットワークが復旧したら、クライアントを再起動して自動ルーティングを有効にします。それでも失敗する場合は、他のVPN、仮想マシンのネットワーク管理ツール、独立したDNSプログラムを一時的に終了します。

再起動やネットワーク切り替え後に動作しない

有線ネットワークからWi-Fiへ切り替えたり、テザリングに接続したり、端末をスリープから復帰させたりすると、デフォルトの外向きインターフェースが変わることがあります。インターフェース自動検出を有効にすると手動設定を減らせますが、クライアント側でTUNの再構築が必要になる場合もあります。いったんTUNを無効にして再度有効にし、新しいデフォルトゲートウェイが認識されているか確認します。ネットワークを頻繁に切り替える端末では、存在しなくなったインターフェース名を設定に固定しないでください。

LAN機器にアクセスできない

プリンター、NAS、ルーターの管理画面は、通常プライベートアドレスまたはローカルドメインを使用します。ルールでこれらのアドレスが直接接続になっているか確認し、ルーティングによってLAN通信が誤ってプロキシ出口へ送られていないか確認します。LANサービスのドメインは、ローカルDNSやマルチキャスト検出に依存することもあります。必要に応じて対象ドメインをFake-IPの除外項目へ追加し、ローカル名前解決の経路を維持します。

一部のアプリで接続がループしたりログインに失敗したりする

まず接続ログで対象ドメインと出口を確認します。アプリが実IP、LAN内のループバック、特殊なUDP動作に依存している場合は、そのドメインまたはプロセスに対して、より具体的な直接接続ルールを作成します。ルールは広範なルールより前に置き、先に評価されるドメインサフィックスやルールセットに一致しないようにします。変更後は接続を再確立してください。既存の接続には新しいポリシーが自動適用されない場合があります。

クライアント終了後もネットワークが復旧しない

まずクライアントのプロセスとサービスがすべて終了していることを確認し、その後システムプロキシまたはVPN設定を無効にします。OSは通常、クライアントが作成した一時ルートを削除します。異常終了後も問題が残る場合は、実際のネットワークインターフェースを無効にしてから再度有効にするか、システムを再起動してネットワーク状態を再構築します。基本ネットワークが復旧してからクライアントを起動し、残った状態で複数の通信取り込みツールを連続して切り替えないでください。

TUN、システムプロキシ、動作モードの組み合わせ方

ブラウザーと、プロキシ設定に明確に対応するデスクトッププログラムだけを使う場合は、システムプロキシの設定が簡単で、切り分ける範囲も小さくなります。ゲーム、ターミナルツール、ストアアプリ、その他システムプロキシを読み取らないソフトウェアまで取り込む必要がある場合に、TUNを有効にします。クライアントによってはシステムプロキシとTUNを同時に有効にできますが、必ず併用する必要はありません。テスト中はシステムプロキシを無効にし、TUNだけでカバレッジを確認できます。

日常利用では通常、「TUNによる取り込み＋ルールモード」を選びます。TUNが通信をカーネルへ送り、ルールモードがドメイン、アドレス、ルールセットに従って振り分けます。グローバルモードは、失敗の原因がルールにあるか短時間で確認するのに適していますが、長期間使うと細かな振り分けの仕組みを飛ばしてしまいます。直接接続モードは、アプリがローカルネットワークから対象へアクセスできるか確認するために使えます。

モバイル端末のTUNは、システムVPNインターフェースを通じて実装されることが多く、通常は同時に1つのシステムVPN接続しか維持できません。そのため、Clash系クライアントを有効にすると、別のVPNアプリが切断されることがあります。デスクトップOSでは複数の仮想インターフェースが同時に存在する場合でも、デフォルトルート、DNS、インターフェースの優先順位が互いに影響します。安定させるには、主要な通信取り込みツールを1つに明確化するのが一般的です。

有効化後の完全チェックリスト

サブスクリプションが更新され、現在の設定を正常に読み込める。
プロキシグループで利用可能なノードが選択され、ルールモードの最終ルールも想定どおりになっている。
システムサービス、ネットワーク拡張機能、またはVPN権限の許可が完了している。
TUNの状態が実行中になっており、ログにインターフェース作成やルート書き込みのエラーがない。
DNSクエリが完了し、ドメインルールを識別して一致させられる。
システムプロキシを無効にしても、プロキシ設定を読み取らないアプリに接続ログが記録される。
TCP、UDP、LANアクセスをそれぞれテストできている。
ネットワーク切り替えや端末の復帰後も、デフォルトの外向きインターフェースが正しく認識される。
他のVPN、仮想マシン、DNSツールが現在のルートを重複して変更しない。
TUNを無効にしてクライアントを終了した後、基本ネットワークが復旧する。

以上を確認すると、TUNの経路は明確な4段階に分けられます。システム権限が仮想インターフェースを作成し、ルーティングがパケットをカーネルへ送り、DNSがルールで識別できる対象情報を提供し、プロキシグループが最終出口を決めます。問題が起きたときは、この4段階を順番に切り分けるほうが、設定の再インストールやノードの連続切り替えより効果的です。