Clash TUNモードの設定方法：全トラフィックを取り込む仕組みと設定手順

TUNモードで全トラフィックを取り込む仕組み

通常のClashシステムプロキシモードでは、HTTPまたはSOCKSプロキシのアドレスをOSに設定します。ブラウザーやシステムプロキシに従うアプリは接続をClashへ渡しますが、一部のゲーム、コマンドラインプログラム、ストアクライアント、独自のネットワークスタックを使うソフトは、接続先へ直接アクセスすることがあります。そのため、システムプロキシを有効にしていても、これらの通信がルールエンジンを通るとは限りません。

TUNモードでは別の経路を使います。Clash Meta（現在はmihomoというコア名が一般的）はシステム上に仮想ネットワークインターフェースを作成し、ルーティングルールと組み合わせて条件に合うIP通信をそのインターフェースへ送ります。コアはパケットの宛先情報を読み取り、設定されたルール、プロキシグループ、ノードに基づいて、直接接続、プロキシ経由、拒否を判断します。アプリ側からは通常のネットワーク接続に見えるため、HTTPプロキシへの個別対応は必要ありません。

「全トラフィックの取り込み」とは、通信がコアへ入る範囲を示すもので、すべての接続を同じプロキシノード経由にするという意味ではありません。TUNは通信をClashへ渡し、最終的な経路は実行モードとルールが決めます。ルールモードでは、LANアドレス、中国国内のサイト、プロキシ対象サイト、ブロック対象ドメインをそれぞれ異なるポリシーに振り分けられます。グローバルモードでは、プロキシ可能な通信を通常グローバルプロキシグループへ渡し、直接接続モードでは、コアに入った通信もそのまま許可される場合があります。

TUN有効化前に確認するバージョン、権限、設定

まず、クライアントがTUNに対応したコアを使用しているか確認します。最新のClash Metaまたはmihomoコアは、TUN、自動ルーティング、DNS連携に対応していることが一般的です。一方、古いClashコア、メンテナンスが終了したGUIクライアント、機能を絞ったモバイル版では、一部の設定項目が使えない場合があります。設定ファイルを読み込めても、現在のコアがすべてのTUNオプションを認識するとは限りません。クライアントのコア名、コアバージョン、起動ログを合わせて確認してください。

システム権限

仮想インターフェースの作成、ルーティングテーブルの変更、DNS設定には、通常管理者権限が必要です。Windowsクライアントではサービスモードまたは管理者権限で実行することがあります。macOSではネットワーク拡張、VPN設定、補助サービスの許可を求められます。Linuxではroot、CAP_NET_ADMIN、システムサービス、および対応するルーティング権限が関係します。権限の許可に失敗すると、画面上ではTUNが有効に見えても、ログにはインターフェース作成失敗やルート追加失敗が記録されます。

権限の許可は、クライアントが提供するサービスのインストール、認証、ネットワーク拡張の入口から行ってください。管理者として何度も再起動すれば権限問題かどうかの判断には役立ちますが、常用する場合はクライアントが正式に対応するバックグラウンドサービスを使う方が適切です。

サブスクリプションとローカル上書き

サブスクリプションは主にノード、プロキシグループ、ルールを提供するもので、現在の端末に適したTUN設定が含まれているとは限りません。GUIクライアントによってはTUNパラメーターをアプリ設定に保存して実行時設定を生成しますが、別のクライアントではYAMLのtunセクションを直接読み込みます。サブスクリプションから生成されたファイルを手動編集すると、次回の更新で変更が上書きされることがあります。確実なのは、クライアントの上書き、マージ、設定パッチ機能を使い、正常に起動できる元設定を別途保存しておく方法です。

ネットワーク環境

• 現在接続しているWi-Fi、有線ネットワーク、モバイルホットスポットを記録し、他のVPNが有効になっていないことを確認します。
• 端末上で仮想マシン、コンテナネットワーク、ゲームアクセラレーター、企業向けセキュリティソフトが動作していないか確認します。
• ドメイン解決に問題が起きた場合に戻せるよう、現在のDNS設定を控えておきます。
• サブスクリプション内のノードが、通常のシステムプロキシモードで少なくとも1つ接続できることを確認します。
• 切り分け中に設定が置き換わらないよう、数分間だけ設定ファイルの自動更新を停止します。

Clash MetaとmihomoのTUN設定手順

GUIクライアントでは、通常ネットワーク、サービスモード、TUN設定の画面から有効化できます。まずクライアントが要求するサービスコンポーネントをインストールし、TUNを有効にしてから、ログに仮想インターフェース、ルーティング、DNSリスナーに関する記録があるか確認してください。ネットワークスタックを選べる場合は、最初から複数の高度な項目を変更せず、互換性のバランスがよい選択肢から試します。

mihomoのYAML設定を直接管理する場合は、次の基本構成から始められます。対応フィールドやデフォルト値はバージョンによって変わる可能性があるため、最終的には現在のコアが出力する設定エラーとクライアントの説明を優先してください。

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

基本フィールドの説明

systemはシステムのネットワークスタックを使う傾向があり、一般に性能とOSのプロトコル互換性に優れています。gvisorはユーザー空間のネットワークスタックを使うため、環境によって分離性や互換性が異なります。mixedはプロトコルに応じて組み合わせて処理します。最適な選択は、OS、コアのバージョン、UDPアプリ、ローカルのセキュリティソフトによって変わります。Web閲覧は正常でもゲームのボイスチャット、UDPリクエスト、特定のプログラムに問題がある場合は、スタックの項目を1つずつ切り替え、コアを再起動して結果を比較してください。

順番に有効化する

1. クライアントが対応する安定版コアへ更新し、現在の設定を正常に読み込めることを確認します。
2. クライアントが必要とするシステムサービス、ネットワーク拡張、仮想ネットワークインターフェースのコンポーネントをインストールまたは有効化します。
3. TUNを有効にし、まずは自動ルーティングと出口インターフェースの自動検出を使います。
4. ルールモードを維持し、動作確認済みのノードを1つ選択します。
5. コアを再起動し、設定項目、権限、インターフェース、ルーティングのエラーが出ていないか確認します。
6. ブラウザー、ターミナルコマンド、もともとシステムプロキシに従わないアプリを個別にテストします。
7. 基本接続が安定してから、厳格なルーティングを有効にするかネットワークスタックを調整します。

設定を変更した後は、コアを完全に再読み込みしてください。テキストエディターでYAMLを保存しただけで、クライアントが古い実行時設定を使い続けることは、よくある誤認の原因です。クライアントログの設定読み込み時刻、コアの起動時刻、現在の動作モードから、新しい設定が反映されたか確認できます。

TUNモードとDNSの連携

TUNはIPパケットを取り込みますが、ルールのマッチングはドメイン名に依存することがよくあります。アプリはまずドメインを問い合わせ、返されたIPへ接続します。DNSクエリがClashを迂回すると、コアには宛先IPしか見えず、ドメインルールの判定能力が低下する可能性があります。さらに、ローカルDNSが不適切なアドレスを返し、プロキシノード側のネットワークでは別の結果を解決できる場合、ノードは使えるのに特定サイトだけ開けないという状態になります。

mihomoのDNSモジュールはクエリを一元処理し、ルール分岐、Fake-IP、Redir-Hostなどの拡張モードと連携できます。次の構成は各部分の関係を示すためのもので、DNSサーバーのアドレスは実際のネットワークと設定元に合わせて選択してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

Fake-IPモードでは、ドメインに対して予約アドレス範囲の一時アドレスを返し、コア内部にドメインとの対応を保存します。アプリがこの一時アドレスへ接続すると、コアは元のドメインを復元してドメインルールを適用できます。ルール判定に必要な情報を保ちやすい一方、実IP、LAN検出、デバイスへのキャスト、特殊な認証フローに依存する一部アプリでは、除外リストへの追加が必要です。除外項目は明確な不具合に応じて1つずつ追加し、広すぎるワイルドカードはドメインマッピングの効果を弱めるため避けてください。

dns-hijackのany:53は主に従来型の53番ポートDNSを処理します。アプリ内蔵の暗号化DNS、ブラウザーのDoH、外部DNSを固定する仕組みは、同じ経路を通るとは限りません。切り分けでは、ブラウザーのセキュアDNS機能を一時的に無効にし、システムのクエリをClashへ通して、複数のDNSが並行動作していることが原因か確認できます。

DNSループを避ける

コアが上流DNSへ問い合わせる際、その通信も適切な出口を選ぶ必要があります。上流DNSのドメイン自体が未解決の名前解決に依存していたり、クエリがルーティングルールによって同じリスニング入口へ繰り返し戻されたりすると、起動時に名前解決ループが発生することがあります。複雑な設定では、デフォルトDNSサーバー、プロキシノードのドメイン解決、直接接続する上流DNSへの到達性を確認してください。ログに同じDNSタイムアウトが連続して出る場合、Webページのエラー画面よりも原因を示す手がかりになります。

TUNが有効になっているか確認するテスト方法

画面のスイッチが有効状態になっただけでは、まだ第一段階です。完全な確認には、仮想インターフェースの存在、ルートの追加、通信がコアへ入っていること、ルールが正しく適用されていること、DNSが迂回していないことを同時に確認する必要があります。簡単な確認から始め、各ステップで1つの疑問だけを解消する順番がおすすめです。

1. 起動ログを確認：設定の解析失敗、権限不足、仮想インターフェースの作成失敗、ルート追加失敗がないことを確認します。
2. 通常のWebページを確認：直接接続ルールとプロキシルールに対応するサイトへアクセスし、接続一覧でポリシーが適用されているか確認します。
3. システムプロキシを使わないプログラムをテスト：システムプロキシを無効にしてTUNだけを残し、ターミナルのダウンロードツールや対象アプリを実行します。
4. 接続履歴を確認：ドメイン、宛先アドレス、プロセス情報、最終ポリシーを照合し、通信が実際にコアを通っていることを確認します。
5. UDPをテスト：UDPに依存するアプリを短時間動かし、現在のネットワークスタックとの互換性を判断します。
6. LANを確認：ルーター、NAS、プリンターのアドレスを開き、プライベートネットワークが誤ってプロキシ経由になっていないことを確認します。
7. ネットワークを切り替える：Wi-Fiからホットスポットへ切り替え、デフォルトインターフェースとルーティングが自動更新されるか再確認します。

接続履歴は、「取り込みが発生していない」のか「取り込み後のルールが誤っている」のかを区別する鍵です。対象アプリの実行中に新しい接続がまったく現れない場合は、TUNインターフェース、ルーティング、アプリの除外、権限を優先して確認します。接続は現れているものの誤ったポリシーが選ばれる場合は、ルールの順序、ドメイン識別、プロキシグループを確認します。ポリシーが正しいのにタイムアウトする場合は、ノード、DNS、MTU、ファイアウォール、リモートサービスを続けて確認してください。

ルールモードでの判断

ルールは上から順に照合され、通常は一致すると以降の確認を停止します。TUNを使っても、この基本的な順序は変わりません。プロキシ経由にしたいドメインが直接接続ルールに一致した場合は、ドメイン、宛先IP、プロセス情報のどれとしてルールエンジンへ渡されたかを確認します。範囲の広いIP-CIDR、GEOIP、または先に置かれた直接接続ルールが、後続のより具体的な処理を上書きすることがあります。フォールバックルールは通常、ルール一覧の末尾に置きます。

よくある競合と段階的な切り分け

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

まずTUNを無効にし、基本ネットワークがすぐ復旧することを確認してから、コアのログを確認します。完全な通信断は、インターフェース作成後にコアが正常動作していない、デフォルトルートが誤っている、DNSが応答しない、権限設定が不完全といった原因で起こります。復旧テストでは、まずstrict-routeを無効にし、auto-routeとauto-detect-interfaceを残して、他のVPNを一時終了します。有線と無線を同時接続している場合は、コアが実際にインターネットへアクセスできるデフォルトインターフェースを認識しているか確認してください。

ブラウザーは使えるが、ゲームや音声通話が失敗する

ブラウザーは主にTCPとHTTPSを使いますが、ゲーム、リアルタイム音声、いくつかのインスタントメッセージ機能はUDPを使います。この場合は、UDP接続がコアへ入っているか、ノードが必要な通信方式に対応しているか、現在のTUNネットワークスタックがアプリに適しているかを確認します。system、gvisor、mixedを切り替える際は1項目ずつテストしてください。DNS、ノード、ルールを同時に変更すると、どの変更が改善につながったか判断できません。

有効化後にLANへアクセスできない

プライベートアドレス帯が直接接続で処理されているか確認し、厳格なルーティングによってローカルネットワークの出口が変わっていないか調べます。代表的なプライベートネットワークには10.0.0.0/8、172.16.0.0/12、192.168.0.0/16がありますが、実際の機器ではリンクローカルアドレス、IPv6のLANアドレス、特定のマルチキャストプロトコルも使われます。機器のIPアドレスは直接開けるのに機器名ではアクセスできない場合、原因はローカルDNS、mDNS、Fake-IPの除外設定にある可能性が高いです。

他のVPN、仮想マシン、コンテナと競合する

複数のネットワークツールが仮想インターフェースを作成し、デフォルトルートを変更することがあります。企業VPN、ゲームアクセラレーター、仮想マシンのブリッジ、Docker、コンテナサブネットは、TUNの自動ルーティングと重複する可能性があります。切り分けではまず他の通信取り込みツールを終了し、Clash TUN単独で正常に動作することを確認してから、1つずつ戻します。2つのツールを併用する必要がある場合は、どのネットワーク帯をどのインターフェースが処理するか明確にし、双方が相手の仮想ネットワークをデフォルト出口にしないようにします。

スリープ復帰やネットワーク切り替え後に使えなくなる

ノートパソコンのスリープ復帰、Wi-Fiローミング、ホットスポットへの切り替え後は、デフォルトインターフェースとゲートウェイが変わることがあります。auto-detect-interfaceは出口を検出するための機能ですが、すべてのOSイベント後にクライアントがすぐルートを再構築するとは限りません。まずクライアントを再インストールするのではなく、コアを再起動してみてください。コアの再起動だけで復旧するなら、クライアントのネットワーク変化監視、バックグラウンド実行権限、サービス状態を確認します。

サブスクリプション更新後にTUN設定が消える

これは通常、パラメーターがサブスクリプション生成ファイルに書かれており、更新時にクライアントがファイルを再ダウンロードして置き換えたことを示します。TUNとDNSのパラメーターは、クライアントが対応する上書きレイヤー、マージ設定、独立した全体設定へ移してください。変更後にサブスクリプションを手動更新してコアを再起動し、パラメーターが残っていることを確認して初めて、保存場所が正しいと判断できます。

階層ごとに問題を絞り込む

段階的な切り分けで重要なのは、比較できる結果を残すことです。毎回1つの変数だけを変更し、変更後にコアを再起動して、ログに出る最初の明確なエラーを記録します。クライアントをすぐ再インストールすると、現場の情報が一部消えるうえ、原因が権限、ルーティング、DNS、ノードのどこにあるのか説明できません。

TUNを日常利用するための設定のコツ

基本設定が完了したら、パラメーターを増やし続ける必要はありません。自動ルーティング、明確なDNS方針、理解しやすいルール、安定したノードの方が、多数の実験的オプションより保守しやすいのが一般的です。ブラウザーと一般的なデスクトップソフトだけを使う端末なら、システムプロキシで主要な用途をカバーできます。コマンドラインプログラム、ゲーム、特定アプリがシステムプロキシに従わない場合に、TUNを有効にする方が目的に合っています。

TUNを長期利用する端末では、コアのアップデート後にフィールドが変わっていないか定期的に確認し、アップデート前に動作する設定を保存しておきます。問題が起きたら、まずアップデート前後のコアバージョン、ネットワークスタック、DNSの挙動を比較してください。クライアント画面の設定名は異なる場合がありますが、基盤はインターフェース、ルーティング、DNS、ルール、ノードの5要素として理解できます。

最終的な設定目標は、すべての通信を機械的にプロキシへ通すことではありません。取り込む必要のある接続を確実にルールエンジンへ送り、用途に応じて直接接続、プロキシ、拒否を選べる状態にすることです。これを理解すれば、TUN、グローバルモード、ルールモードの違いが明確になり、ノード障害を仮想ネットワークインターフェースの問題と誤認することも避けられます。