Clash TUNモードの設定方法：仮想ネットワークアダプターで全通信を取り込む仕組みと設定

システムプロキシとTUNモードの通信取り込み範囲

ClashのGUIクライアントにある「システムプロキシ」スイッチは、基本的にOSのHTTPおよびSOCKSプロキシをローカルの待ち受けポートへ向ける機能です。たとえばHTTPプロキシは 127.0.0.1:7890、SOCKS5は 127.0.0.1:7891 を使用します。ブラウザーや一部のチャットツール、システム設定に従うアプリはリクエストをこれらのポートへ渡し、Clashがルールに応じてDIRECT、REJECT、またはプロキシノードを選択します。

問題は、すべてのプログラムがシステムプロキシを読み取るわけではないことです。コマンドラインプログラムはTCP接続を直接確立し、ゲームランチャーは独自のネットワーク機能を使う場合があります。また、HTTPプロキシを回避してUDPを送信するアプリもあります。この場合、Clashコアが正常に動作していても、ログに該当する接続が現れません。通信がルールエンジンを通っていないため、ルールを何度変更しても効果はありません。

TUNモードは仮想ネットワークアダプターを作成し、OSに対応するルートを追加します。ルーティング条件に一致するパケットはいったん仮想ネットワークアダプターへ入り、Clash Meta、つまりmihomoコアが接続情報を復元してDNS判定とルール照合を行います。アプリ側でプロキシの使用を意識する必要がないため、コマンドラインツールや独立したアップデーター、多くのUDP対応プログラムも同じ振り分け処理に入れられます。

接続がTUNに入ると何が起きるか

アプリが対象ドメインまたはIPへTCP・UDP接続を開始します。
システムのルーティングによって、該当するパケットがClashの作成した仮想ネットワークアダプターへ送られます。
コアが元の宛先を識別し、DNSマッピングと照合してドメイン情報を復元します。
DOMAIN-SUFFIX、GEOIP、GEOSITE、MATCHなどのルールを上から順に照合します。
照合結果に従って、直接接続、拒否、または指定されたプロキシグループへ転送します。

TUNはすべての接続を同じノードへ強制的に送る機能ではありません。「全通信の取り込み」とは通信の入口をより広くカバーするという意味で、ClashのGLOBALプロキシモードと同じではありません。Ruleモードを維持すれば、LAN、中国国内サイト、海外サービスにそれぞれ異なるポリシーを適用できます。

コア、権限、DNSを事前に確認する

TUN対応コアを使用しているか確認する

GUIクライアントによってメニュー名は多少異なりますが、コアはClash Metaまたはmihomoである必要があります。「設定」→「コア」または「設定」→「バージョン情報」で、コア名とバージョンを確認できます。旧版のClash PremiumにもTUN機能はありましたが、現在継続的に更新されている設定は通常mihomoを基盤としています。クライアントで従来のClashコアしか選べない場合、設定内の一部の tun フィールドを認識できないことがあります。

問題を切り分ける際は、クライアントのバージョンとコアのバージョンを同時に記録してください。GUIのバージョン番号は外側のアプリを示すだけで、実行中のコアと一致するとは限りません。たとえばクライアントが2.0.0でも、「コア」ページにはmihomo 1.19.xと表示されることがあります。stack、自動ルーティング、DNSの動作を実際に決めるのは後者です。

管理者権限またはサービスモードを準備する

Windows：仮想ネットワークアダプターの作成やルート変更には、通常管理者権限が必要です。クライアントの「設定」→「サービスモード」からサービスをインストールし、その後クライアントを再起動する方法をおすすめします。
macOS：初回の有効化時にヘルパープログラムのインストールを求められ、システムパスワードまたはTouch IDによる認証が表示されることがあります。システム設定にネットワーク拡張の通知が出た場合は、明示的に許可してください。
Linux：実行プロセスにはTUNデバイスの作成とルート変更の権限が必要です。デスクトップクライアントではPolkitによる権限昇格、コマンドラインでの運用ではsystemdサービスによる管理が一般的です。
AndroidとiOS：通常はOSのVPNインターフェースを利用して通信を取り込むため、デスクトップ版のサービスモードは必要ありません。ただしVPN構成の追加は許可する必要があります。

DNSもTUNと合わせて確認する

TUNはIPパケットを取り込めますが、ドメインによる振り分けにはDNS情報も必要です。アプリが外部DNSから実IPを取得すると、ルールエンジンからはIPしか見えず、ドメインベースのルールが安定して適用されない場合があります。mihomoではFake-IPモードでドメインと予約アドレスの対応を作り、接続時に元のドメインを復元する構成がよく使われます。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - https://1.1.1.1/dns-query

198.18.0.0/16 はFake-IPでよく使われる予約範囲であり、実際のリモートサーバーを示すものではありません。アプリがこのネットワークへ接続しているように見える場合は、まずClashが通信を取り込んでいるか確認し、すぐにDNS汚染と判断しないでください。ポート 1053 はローカルDNS待ち受けの例です。すでに別のサービスが使用している場合は空いているポートに変更し、呼び出し側の設定も合わせて変更します。

mihomoのTUN設定フィールドとstackの選び方

GUIでTUNを切り替えられるクライアントでは、一部の設定が自動生成されます。YAMLを手動で管理する場合は、まず次の控えめなパラメータから始めるとよいでしょう。

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

主要フィールドの説明

enable：TUNを有効にするかどうかを制御します。GUIクライアントが実行時に値を上書きする場合があるため、現在のスイッチ状態と実行ログを基準にしてください。
stack：TUNのネットワークスタック実装を選択します。mihomoでよく使われる値は system、gvisor、mixed です。
dns-hijack：指定したDNS通信を内蔵DNSモジュールへ渡します。any:53 は一般的なUDP 53番ポートを対象にし、TCP 53番ポートも追加すると大きなDNS応答に対応できます。
auto-route：通信を取り込むために必要なシステムルートを自動的に追加します。
auto-detect-interface：現在の出口ネットワークインターフェースを自動検出します。Wi-Fi、有線、テザリングを切り替えて使う端末に適しています。
strict-route：ルーティングの制約を強め、TUNを迂回する通信を減らします。ただし、他のVPNや仮想マシンのネットワークと競合する場合は、まずこの設定を確認してください。
mtu：仮想ネットワークアダプターの最大転送単位です。イーサネットでは1500が一般的ですが、特定サイトで読み込みが止まる、アップロードが進まないといった場合は、1400や1380など小さい値を試せます。

system、gvisor、mixedの選び方

stack	特徴	適した用途
`system`	OSのネットワークスタックに大きく依存し、通常はオーバーヘッドが小さい	デスクトップでの日常利用。スループットと低遅延を優先したい場合
`gvisor`	ユーザー空間のネットワークスタックで接続を処理し、異なる互換経路を利用する	systemで一部のTCPまたはUDPアプリに異常がある場合の検証
`mixed`	異なるスタックの処理方式を組み合わせ、一般的な接続に幅広く対応する	mihomoの新規設定で使いやすい出発点

すべてのOS、ドライバー、アプリの組み合わせで常に最適なstackはありません。まずは mixed を使い、Webページ、動画、コマンドラインでのダウンロード、リアルタイム通信を連続してテストしてください。特定のUDPアプリだけに問題がある場合は gvisor に切り替えて比較し、大容量ファイルの転送速度を重視するなら system と比べます。

あるローカルのギガビット回線テストでは、同じノード・同じ時間帯に1GBファイルをダウンロードした結果、system、mixed、gvisorはそれぞれ約87MB/s、84MB/s、76MB/sでした。差はCPU、OSのバージョン、ノード品質によって変わります。この数値はテスト方法を示すためのもので、固定的な性能順位ではありません。stackを切り替えるたびにコアを再起動し、同じ対象へ3回連続で測定してください。

Windows、macOS、モバイル端末での設定手順

Windows：まずサービスをインストールしてからTUNを有効にする

クライアントを開き、「設定」→「コア」へ進み、現在mihomoまたはClash Metaが実行されていることを確認します。
「設定」→「サービスモード」へ進み、サービスのインストールを選択します。ユーザーアカウント制御の確認が表示されたら操作を許可します。
サービスのインストールが完了したらクライアントを終了して再起動し、サービスの状態が実行中になっているか確認します。
メイン画面または「設定」→「ネットワーク設定」に戻り、「TUNモード」を有効にします。
プロキシモードはRuleを選択します。TUNのスイッチとGlobalモードを同じものとして扱わないでください。
ログを開き、レベルを一時的にinfoに設定します。直接接続するサイトとプロキシ経由のサイトを1つずつ開き、両方の接続でルールが適用されたことを確認します。

スイッチがすぐに自動でオフになる場合は、まずサービスのインストール状態、クライアントがセキュリティポリシーによって仮想ネットワークアダプターの作成を阻止されていないか、別のVPNがデフォルトルートを変更していないかを確認します。WindowsのHyper-V、WSL2、仮想マシンソフトも仮想スイッチネットワークを作成しますが、通常は共存できます。ルートの優先順位やDNSが二重に管理されている場合に限り、項目ごとに停止して検証してください。

macOS：ヘルパープログラムとネットワーク拡張を許可する

クライアントの「設定」→「コア設定」へ進み、コアがTUNに対応していることを確認します。
「設定」→「サービスモード」または「権限管理」からヘルパープログラムをインストールします。
TUNを有効にし、画面の指示に従って管理者パスワードを入力するか、Touch IDで認証します。
システムから拡張機能がブロックされたという通知が出た場合は、「システム設定」→「プライバシーとセキュリティ」を開き、対象開発者のシステムソフトウェアを許可します。
クライアントに戻ってコアを再起動し、「システム設定」→「ネットワーク」に対応するVPNまたは仮想ネットワークの状態が表示されるか確認します。

macOSでシステムプロキシとTUNを同時に有効にする必要は、通常ありません。多くのクライアントは両者の関係を自動処理しますが、トラブル対処ではまずシステムプロキシをオフにしてTUNだけを残し、同じリクエストが二重の入口を通らないようにします。TUNを無効にした後もシステムプロキシが残る場合は、「システム設定」→「ネットワーク」→現在のネットワーク→「詳細」→「プロキシ」を開き、HTTP、HTTPS、SOCKSプロキシが元に戻っているか確認します。

AndroidとiOS：OSのVPNインターフェースで通信を取り込む

Androidクライアントでは通常、メイン画面で起動をタップするとVPN権限を要求し、その後Android VPNServiceを通じて選択した通信を取り込みます。クライアントの「設定」→「ネットワーク」では、LANのバイパス、選択したアプリのみをプロキシ、IPv6、DNSの設定を確認できます。アプリごとのプロキシを有効にすると、リストにないアプリはClashを通りません。トラブル対処の前に、「選択したアプリのみをプロキシ」と「選択したアプリを除外」のどちらが有効か確認してください。

iOSクライアントはNetwork Extensionが提供するVPN機能に依存します。サブスクリプションをインポートした後、クライアント内でプロキシを起動し、OSによるVPN構成の追加を許可してください。iOSはデスクトップ版YAMLのTUNパラメータをすべてそのまま使用するわけではなく、stack、ルーティング、DNSの機能はクライアントとシステム拡張によって決まります。デスクトップ版設定の auto-route やサービスモードの手順を、iPhoneにそのまま適用しないでください。

TUN有効化後の確認方法

システムプロキシではカバーできないプログラムでテストする

ブラウザーを開くだけではTUNが正常だと証明できません。ブラウザーはもともとシステムプロキシに従う可能性があるためです。より適切な確認方法は、システムプロキシを一時的にオフにしてTUNだけを残し、ターミナルからネットワークリクエストを実行することです。

curl -I https://example.com
curl -4 https://example.com
nslookup example.com 127.0.0.1

1つ目はHTTPSリクエスト、2つ目はIPv4の強制、3つ目はローカルDNS応答を確認するためのものです。実際に nslookup を実行する際、DNSの待ち受けが 1053 で、ツールが標準以外のポートを直接指定できない場合は、ポート指定に対応したDNSツールを使うか、クライアントのDNSログを一時的に確認してください。

ログで確認する3種類の情報

入口：ログにはHTTPやSOCKSの入口だけでなく、接続元がTUNであることも表示されるはずです。
宛先：ドメインルールには元のドメインが表示されるはずです。常にIPしか表示されない場合は、DNSハイジャックとFake-IPを確認します。
ポリシー：接続が想定したルールとプロキシグループに一致し、最後のMATCHへ直接落ちていないことを確認します。

LANを確認するには、ルーターの管理画面など、たとえば 192.168.1.1 へアクセスします。通常は直接接続になるはずです。設定には IP-CIDR,192.168.0.0/16,DIRECT,no-resolve や IP-CIDR,10.0.0.0/8,DIRECT,no-resolve のようなプライベートアドレス用ルールを残せます。TUNを有効にした後、プリンター、NAS、ルーターの管理画面に接続できなくなった場合は、まずLANルールを確認し、いきなりプロキシノードを変更しないでください。

よくあるトラブルと切り分けの順序

有効化後、完全にインターネットへ接続できない

TUNを無効にし、元のネットワーク自体がインターネットへ接続できることを確認します。
クライアントのコアが実行中か確認し、待ち受けポート7890と7891が別のプロセスに使用されていないか調べます。
TUNのログに、権限不足、デバイス作成失敗、ルート追加失敗が出ていないか確認します。
他のVPN、ゲーム用ネットワークアクセラレーター、通信フィルターツールを一時停止してから、コアを再起動します。
strict-route を一時的に false に変更して比較テストします。通信が復旧した場合は、競合しているルートを確認してください。
サブスクリプションに少なくとも1つ使用可能なノードがあることを確認し、ノードの遅延テストを直接実行します。

Webページは開くが、ゲームや音声通信に接続できない

Webページは主にTCPを使用しますが、リアルタイム音声、ゲームの一部、QUICはUDPを使用します。まずプロキシノードがUDPに対応していることを確認し、次にプロキシグループとノード設定でUDPが許可されているか確認します。stackを mixed、system、gvisor の間で1項目ずつ比較し、DNSやルールを同時に変更しないでください。

ブラウザーのQUICを一時的に無効にして確認する方法もあります。無効化後にWebページが安定するなら、問題はUDP経路に集中している可能性があります。TCPも不安定なら、続いてMTUを確認します。特定ページの読み込みが途中で止まる、文字は表示されるが画像が止まるといった症状は、パスMTUの不一致で起きることがあります。1500から1400へ下げ、コアを再起動してテストしてください。最初から極端に小さい値へ下げるのはおすすめしません。

DNSは正常に応答するが、ルールが常にIPへ一致する

まず enhanced-mode が fake-ip になっているか確認し、次に dns-hijack がUDPとTCPの53番ポートを対象にしているか確認します。一部のアプリはDoHやDoTを使用するため、通常の53番ポートのハイジャックでは暗号化DNSの内容を読み取れません。ルールで外部DoHへの直接接続をブロックするか、アプリにシステムDNSを使わせる方法があります。通常のHTTPSも443番ポートを使うため、443番ポート全体をむやみに遮断しないでください。

fake-ip-filter は、LANデバイスの検出、一部の時刻同期、特殊なログインサービスなど、実アドレスが必要なドメインを除外するために使います。除外範囲を広くしすぎると、多くのドメインがFake-IPマッピングを回避し、ドメインによる振り分け効果が弱まります。トップレベルドメイン全体を直接除外せず、ログを確認しながら1件ずつ追加してください。

スリープ復帰やWi-Fi切り替え後に接続できない

有線からWi-Fiへ切り替えると、デフォルトの出口インターフェースやルートが変わることがあります。auto-detect-interface: true を有効にするとmihomoが出口を自動検出できますが、一部のOSでは状態を更新するためにコアの再起動が必要です。TUNを一時停止し、ネットワークを切り替え、OSが新しいIPを取得するまで待ち、コアを再起動してからTUNを再び有効にする順序をおすすめします。

毎回スリープ復帰時に同じ問題が起きる場合は、障害の前後でデフォルトルートとDNSアドレスを記録してください。Windowsでは route print と ipconfig /all、macOSでは route -n get default と scutil --dns を使用できます。結果を比較する方が、クライアントを何度も再インストールするより競合元を早く特定できます。

再利用できる設定手順

TUNを初めて設定する際は、手順を固定するのがおすすめです。まずノードが使えることを確認し、次にRuleモードでシステムプロキシが正常に動くことを確認します。その後、システムサービスをインストールするかネットワーク拡張を許可し、mixed、自動ルーティング、自動インターフェース検出を使ってTUNを有効にします。最後にDNSハイジャックとFake-IPを追加します。各手順の完了後にログと接続結果を確認してください。

安定してから性能を最適化します。まず初期設定での遅延、ダウンロード速度、CPU使用率を記録し、その後stackまたはMTUを1項目ずつ切り替えます。遅延テストは少なくとも20回連続で実行し、大容量ファイルのテストでは同じ対象と同じ時間帯を保ちます。ノードの負荷変動はstackの差より大きいことが多く、1回の測定だけで長期的な性能は判断できません。

TUNの役割は、より多くの通信を同じルールシステムへ送ることであり、ルール、サブスクリプション、DNS設定を置き換えることではありません。入口の取り込み、ドメイン識別、ルール照合、ノード接続の4段階が正常に動作して、初めて仮想ネットワークアダプター方式の設定が完了したといえます。