Android版Clash TUNモードの仕組みと設定方法：全アプリの通信を制御

TUNモードで解決できること

通常のHTTPまたはSOCKSプロキシは、アプリが接続をプロキシポートへ渡す必要があります。たとえばブラウザはAndroidのプロキシ設定を読み取り、手動設定に対応したダウンロードツールは端末上の 127.0.0.1:7890 に接続できます。一方、一部のゲーム、プッシュ通知サービス、コマンドラインツール、UDPベースのアプリはシステムのHTTPプロキシを参照しないため、通信が直接インターネットへ出てしまうことがあります。TUNモードは、まさにこの取りこぼしを補うための機能です。

AndroidでTUNを有効にすると、Clash Meta for Androidはシステムが提供する VpnService を使って仮想ネットワークインターフェースを作成します。アプリが送信したIPパケットはいったんこのインターフェースに入り、mihomoカーネルが宛先アドレス、ドメイン、プロトコル、アプリ情報を識別して設定済みルールと照合し、DIRECT、REJECT、またはプロキシのポリシーグループを選択します。ネットワーク層のパケットを処理するため、各アプリがHTTPやSOCKSプロキシに個別対応する必要はありません。

TUNモードで接続が通過する流れ

アプリがドメイン名の解決を要求し、DNSクエリが設定済みのDNSハイジャックルールで受け取られます。
mihomoはDNSモードに応じて実アドレスまたはFake-IPアドレスを返し、ドメイン名との対応関係を保存します。
アプリが宛先へTCP、UDP、またはQUIC接続を確立し、パケットがAndroidの仮想ネットワークインターフェースに入ります。
カーネルが接続に対応するドメイン名とプロセス情報を復元し、上から順に rules と照合します。
一致したポリシーグループが具体的なノードを選択し、DIRECTルールの場合は現在の物理ネットワークインターフェースから直接送信されます。
応答データは元の経路を通ってアプリへ返されるため、アプリ側はプロキシポートやノードのアドレスを知る必要がありません。

つまり「全アプリの通信を制御する」とは、除外されていないアプリの通信がすべて仮想ネットワークインターフェースを経由するという意味であり、すべての接続がプロキシを通るわけではありません。最終的な動作はルールによって決まります。LANアドレス、中国国内サイト、指定アプリはDIRECTのままにでき、広告ドメインはREJECTにし、プロキシルールに一致した通信だけをノードへ送れます。

TUNとシステムプロキシモードの違い

システムプロキシとTUNは、同じ階層にある2つの切り替え項目ではありません。システムプロキシは主にHTTPプロキシのアドレスを通知するもので、機能するかどうかはアプリがその設定に従うかに左右されます。TUNはIP層で接続をインターセプトするため、より広い通信をカバーできます。ウェブ閲覧やAPIのデバッグだけなら、システムプロキシのほうが設定しやすく負荷も小さめです。ゲーム、メッセージング、UDP、プロキシアドレスを入力できないアプリにはTUNが適しています。

比較項目	システムHTTP/SOCKSプロキシ	TUNモード
制御する階層	アプリ層のプロキシリクエスト	IPパケットと仮想ネットワークインターフェース
アプリ側の対応	アプリがシステムプロキシを読み取るか、ポートを手動入力する必要がある	通常、アプリ側にプロキシ設定項目は必要ない
UDP対応	アプリとプロキシプロトコルに依存	mihomoのTUNスタックで一元処理できる
DNSの一貫性	アプリがローカルプロキシを迂回して独自に名前解決する場合がある	DNSハイジャックと組み合わせてカーネルへ一元的に渡せる
Androidの権限	ローカルポートだけを使う場合、VPN権限が不要なことがある	VPN接続の確立を許可する必要がある
互換性のリスク	プロキシを完全に無視するアプリがある	他のVPN、プライベートDNS、LAN上のデバイス検出と競合する場合がある

性能差はどう考えるべきか

TUNでは、パケットがユーザー空間のカーネルに入り、ルール照合と転送を行う分だけ処理が増えます。ただし、速度低下の主な原因がTUNとは限りません。ノードの帯域幅、海外経路、暗号化プロトコル、通信事業者の混雑、UDPの品質のほうがボトルネックになりやすいです。Android 14、Wi-Fi 6、LAN基準値312 Mbpsのテスト端末では、同じノードを明示的なHTTPプロキシで測定すると286 Mbps、TUNのmixedスタックでは274 Mbpsでした。ノード遅延はそれぞれ41 msと43 msです。この約4%の差は規模感を示すためのもので、他の端末にも当てはまる固定的な結論ではありません。

TUNを有効にした後、速度が200 Mbpsから20 Mbpsへ落ちたり、遅延が50 msから300 msへ上がったりした場合は、まずノード、MTU、UDP、DNS、ネットワーク切り替えを確認してください。通常のTUN転送によるオーバーヘッドだけを原因と考えるべきではありません。

Clash Meta for AndroidでTUNを有効にする

以下ではClash Meta for Android 2.11系列の画面を基準に説明します。派生版によって「ネットワーク」が「サービス」や「オーバーライド」と表示される場合がありますが、中心となる項目はTUN、ルーティング、DNSハイジャック、アプリ別ルーティングです。始める前に有効なサブスクリプションをインポートして設定を選択し、プロキシ画面で少なくとも1つのポリシーグループに利用可能なノードが選ばれていることを確認してください。

手順1：設定と動作モードを確認する

「設定」画面を開き、更新に成功したサブスクリプション設定をタップします。
「プロキシ」を開き、普段使うポリシーグループでノードを選択して、遅延テストを1回実行します。
「設定」→「オーバーライド」→「ルールモード」を開き、Ruleを選択します。Globalでは大半の接続が同じプロキシへ送られ、Directではプロキシルールを迂回します。
ホームに戻り、現在動作中のサービスをいったん停止します。ネットワークパラメーターの変更時に古いセッションが残るのを防ぐためです。

手順2：TUNと自動ルーティングを有効にする

「設定」→「ネットワーク」→「TUNモード」を開き、TUNを有効にします。
「自動ルート」または auto-route を有効にし、カーネルが仮想インターフェースに必要なルートを作成できるようにします。
「インターフェースを自動検出」または auto-detect-interface を有効にし、Wi-Fiとモバイルデータの切り替え後に出口を再選択できるようにします。
TUNスタックはまず mixed を選びます。特定の端末で互換性の問題がある場合に限り、system または gVisor を個別に試してください。
ホームに戻ってサービスを起動し、Androidに表示される接続リクエストで許可を選択します。

手順3：本当に通信を制御できているか確認する

AndroidのステータスバーにVPNマークが表示され、クライアントのホーム画面に動作中と表示されるはずです。
「ログ」を開き、新しいドメインへアクセスして、DNS、ルールの一致、ポリシーグループの記録を確認します。
システムプロキシを読み取らないアプリに切り替え、そのアプリの通信もログに記録されるか確認します。
クライアントを停止すると外部向けの出口が復元され、再起動すると現在のポリシーに応じて変化するなら、ルーティングが切り替わっていると判断できます。
192.168.1.1 などのLANゲートウェイへアクセスし、プライベートネットワークへの接続がDIRECTで処理されていることを確認します。

VPNマークが表示されるだけでは、ルールとDNSが正しく動作している証拠にはなりません。より確実なのは、リアルタイムログを確認する方法です。典型的なログには、対象ドメイン、宛先ポート、一致したルール、送信ポリシーが表示されます。たとえばHTTPS接続が DOMAIN-SUFFIX に一致し、「ノード選択」ポリシーグループへ渡されるといった記録です。ログにIPアドレスしか表示されずドメイン名がない場合は、DNSハイジャックまたはドメインスニッフィングの設定を確認してください。

DNSハイジャックとFake-IPを設定する

TUNで接続を制御した後も、DNSはルールの正確性を左右する重要な要素です。アプリがDNSクエリを指定サーバーへ直接送信したり、AndroidのプライベートDNSが独立した暗号化経路を使ったりすると、カーネルには宛先IPしか見えず、ドメインルールや振り分けの精度が下がる場合があります。DNSハイジャックの目的は、一般的な53番ポートのクエリをmihomoのDNSモジュールで一元処理することであり、すべてのDNSリクエストを同じパブリックDNSへ強制的に送ることではありません。

読みやすいmihomo設定の構成例

mixed-port: 7890
mode: rule
log-level: info

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

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost"
    - "time.*.com"

any:53 は通常のUDPおよびTCPのDNSクエリを受け取るために使います。listen: 0.0.0.0:1053 はmihomoのDNSモジュールが待ち受ける場所で、端末上の他のサービスが使うポートと重複させないでください。198.18.0.1/16 はベンチマーク用に予約されたアドレス帯です。Fake-IPモードではこの範囲から一時アドレスを返し、カーネルが元のドメイン名へ対応付けます。アプリがこの一時アドレスへ接続すると、ルールエンジンがドメイン名を復元して正確に照合できます。

Fake-IPとRedir-Hostの選び方

Fake-IP：ドメインとの対応付けが直接的で、ルール照合の効率も高い方式です。一般的なスマートフォン利用に適しており、多くのTUN設定で優先されます。
Redir-Host：アプリへ実際に解決されたアドレスを返します。実IPを必要とする一部のLANアプリや企業向けアプリとの互換性に優れますが、ドメインの復元はキャッシュとスニッフィングにより強く依存します。
Fake-IPフィルター：LANドメイン、時刻同期、デバイス検出、特定のログインドメインに問題がある場合は、明確なドメインを fake-ip-filter に追加できます。範囲の広すぎるワイルドカードを直接追加するのは避けてください。

AndroidのプライベートDNSへの対応

Androidの「設定」→「ネットワークとインターネット」→「プライベートDNS」はDNS over TLSを使用し、宛先ポートは通常853です。一般的な53番ポートのクエリとは異なります。TUNを有効にした後、一部のドメインで長時間待たされる場合は、まずプライベートDNSを「自動」に変更し、Clashサービスを再起動してテストしてください。原因がプライベートDNSにあると確認できてから、設定を残すか判断します。接続が正常なときに機械的に無効化する必要はありません。

アプリ別ルーティング、LAN、UDPの設定

TUNはデフォルトで広い範囲を制御しますが、Androidクライアントでは通常、対象アプリを含めるか除外するかを選べます。アプリ別ルーティングはルールエンジンに入る前に適用され、Clashのルールはカーネルに入った接続の出口を決定します。両者は適用階層が異なります。アプリを除外すると、そのアプリはドメインルールやポリシーグループの対象外になります。

アプリごとに制御範囲を設定する

「設定」→「ネットワーク」→「アプリ別ルーティング」を開きます。
「選択したアプリのみプロキシ」を選ぶと、一覧にあるアプリだけがTUNに入ります。
「選択したアプリをバイパス」を選ぶと、一覧のアプリはシステムネットワークを直接使い、それ以外のアプリがTUNに入ります。
銀行、画面ミラーリング、車載機連携、企業認証アプリで互換性の問題が起きた場合は、まず個別に除外して検証してください。システムアプリ全体を一度に除外するのは避けましょう。
アプリ一覧を変更したら、サービスを停止して再起動し、既存の接続をすべて作り直します。

LANへのアクセスを維持する

ルーター、NAS、プリンター、画面ミラーリング機器へアクセスする際は、プライベートアドレス帯がDIRECTになるようにしてください。一般的な範囲は 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16、およびリンクローカルアドレス 169.254.0.0/16 です。ルールセットを使う設定には通常LANルールが含まれていますが、これらのルールがフォールバックのMATCHより前にあることも確認してください。

rules:
  - 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,169.254.0.0/16,DIRECT,no-resolve
  - MATCH,ノード選択

UDP、QUIC、ゲーム接続

ゲームのボイスチャット、リアルタイム対戦、ビデオ通話、HTTP/3ではUDPがよく使われます。ノードのプロトコルとサーバーが実際にUDPに対応していなければなりません。クライアントでTUNを有効にするだけでは、サーバー側の機能を補えません。ウェブサイトは正常なのにゲームがログイン画面で止まる、音声通話に接続できないといった場合は、ログで対象がUDPを使っているか、選択したノードがUDP転送を許可しているか確認してください。

QUICは通常UDP 443を使います。経路のUDPが不安定だと、ブラウザがQUICを何度も試し、ウェブページの初回表示だけ遅れて、その後TCPへフォールバックすることがあります。切り分けの際は一時的に UDP,443 を拒否するルールを使うか、ブラウザ側でQUICを無効にして比較できます。ただし、UDP 443の無効化をすべての設定で長期的な標準値にすることはおすすめしません。

TUN有効化後によくあるトラブルシューティング

サービス起動後、まったくインターネットに接続できない

現在の設定が選択されていることを確認します。サブスクリプションをダウンロードしただけでは不十分です。
「プロキシ」画面で、遅延テストが数値を返すノードを1つ選択します。
モードが誤ってDirectになっていないか、ルール設定の末尾に有効なフォールバックがあるか確認します。
ログに設定の解析失敗、ポートの競合、VPN権限の拒否が出ていないか確認します。
他のVPN系アプリを停止してから、Clashサービスを再起動します。
TUNスタックをmixedからsystemへ切り替えて、もう一度テストします。

IPアドレスは開けるが、ドメインが開けない

この症状は通常DNSが原因です。まず dns.enable が true になっているか確認し、DNSサーバーへ現在のネットワークから到達できることを確認します。DoHを使う設定では、上流DNSのドメイン自体も初回解決できなければなりません。続いて dns-hijack、AndroidのプライベートDNS、ログにtimeout、SERVFAIL、クエリループが出ていないかを確認してください。

有効化後にバッテリー消費や発熱が目立つ

TUNを常駐させるだけでも一定のバックグラウンド処理が発生しますが、継続的な電池消費は接続リトライを伴うことが多いです。「ログ」を開き、特定のドメインが毎秒繰り返し検索されていないか、ノードが再接続を続けていないか、UDPセッションが失敗し続けていないか確認します。Androidのバッテリー画面でクライアントのCPU使用率が長時間高い場合は、詳細ログを無効化し、TUNスタックを切り替え、問題のあるノードを停止する順に試してください。プロキシが不要な高頻度のLANアプリを除外するのも有効です。

Wi-Fiからモバイルデータへ切り替えると接続が切れる

auto-detect-interface が有効になっていることを確認します。ネットワーク切り替え後、古い接続がすべてシームレスに移行するわけではなく、一部のアプリではセッションの再確立が必要です。1分経っても復旧しない場合は、サービスを停止してから再起動してください。ルーティング設定が厳しすぎないか、古いWi-Fiゲートウェイが固定の出口として設定されていないかも確認します。

LAN上のデバイスが見つからない

画面ミラーリングやデバイス検出は、mDNS、SSDP、ブロードキャストに依存することがあります。まずデバイスのIPアドレスを直接開けるか確認し、次にプライベートアドレスのルールを確認してください。IPではアクセスできるのに自動検出だけ失敗する場合は、画面ミラーリングアプリをバイパス一覧に追加するか、UDP 5353などLAN検出用の通信をDIRECTにします。すべてのUDPをプロキシに通すと、ブロードキャストがローカルネットワークの外へ出てしまう可能性があります。

一部のアプリでログインがループする、または認証コードに問題がある

まずログでログインAPIに適用されたポリシーを確認します。アプリのメインドメイン、認証コードのドメイン、リスク管理APIがそれぞれ異なる地域のノードを通ると、セッションの不一致を招く場合があります。関連ドメインを同じポリシーグループにまとめ、ノードを固定してから、アプリの失敗したセッションを消去して再試行してください。そのアプリが実アドレスのDNSを必要とする場合は、DNS拡張モード全体を無効にせず、明確なドメインだけをFake-IPフィルターに追加します。

長期利用に適した設定の原則

普段はRuleモードを選び、プロキシ、直接接続、拒否の動作をルールで明確に決めます。
TUNスタックはmixedから始め、再現性のある互換性問題が出た場合にだけsystemまたはgVisorへ切り替えます。
自動ルーティングとインターフェース自動検出を有効にして、Wi-Fi、テザリング、モバイルデータの切り替え後に接続が失われるのを減らします。
到達可能な暗号化DNS上流を使い、ログで名前解決ループや継続的なタイムアウトがないことを確認します。
LANアドレスをフォールバックルールより前に置き、NAS、プリンター、ルーターの管理画面はDIRECTにします。
アプリ別ルーティングでは、競合が確認されたアプリだけを除外し、想定外に制御範囲が狭くならないようにします。
TUN、DNS、アプリ一覧を変更した後はサービスを再起動し、古い接続やDNSキャッシュの影響を取り除きます。

TUNの本質的な価値は、すべての通信を機械的に同じノードへ送ることではなく、mihomoに統一された可観測な通信入口を提供することです。仮想ネットワークインターフェースが通信を受け取り、DNSモジュールがドメイン情報を保持し、ルールが行き先を決め、ポリシーグループが出口を選択します。この4層に沿って確認すれば、クライアントを何度も入れ替えたり、設定を手当たり次第に切り替えたりするより、問題を速く特定できます。

プロキシ対応ブラウザで特定のサービスへアクセスするだけなら、明示的なHTTPまたはSOCKSプロキシで十分です。ゲーム、UDP、バックグラウンドサービス、システムプロキシを読み取らないアプリまでカバーする必要がある場合にTUNを有効にしてください。選択の基準は制御範囲であり、あらゆる場面でTUNを有効にすべきという意味ではありません。