ClashのTUNモードとは？仕組みと設定方法：全通信をカーネルで処理

TUNで通信を取り込んでも、すべての接続がプロキシ経由になるわけではありません

ClashのTUNモードは、システム上に仮想のレイヤー3ネットワークインターフェースを作成し、ルーティングによって条件に合うIPパケットをカーネルに渡します。カーネルは宛先アドレスやポート、利用可能なドメイン情報を参照し、ルールに従ってDIRECT、プロキシノード、その他のポリシーを選択します。ブラウザー以外にも、システムプロキシ設定を参照しないコマンドラインツール、ゲーム、一部のデスクトップアプリの通信を同じルールで処理できます。

タイトルの「全通信」とは、取り込みの対象範囲を指し、クライアントのGlobalモードを意味するものではありません。TUNを有効にしてもRuleモードを利用できます。LAN内の接続は直接接続し、指定したドメインはプロキシ経由にし、それ以外の接続は最後のMATCHで処理できます。ルートの除外設定、アプリ独自のVPN、別のネットワーク名前空間、一部のシステム通信は、取り込みの対象外になる場合があります。

システムプロキシとTUNの適用範囲の違い

TUNはネットワークを高速化する機能ではありません。ノードの混雑、UDPの不通、ルールの誤判定は、仮想ネットワークインターフェースに切り替えても解消しません。まず通常のプロキシ経由で同じノードに接続できることを確認し、その後に取り込み範囲を広げると、ノード側とローカルルーティング側の問題を切り分けやすくなります。

有効化する前に確認すること：カーネル、権限、設定の適用元

以下のYAMLは、これらのフィールドに対応するmihomo向けです。mihomoはClash Metaの後継カーネル名として使われています。旧世代のClashカーネル、モバイル向けのラッパーアプリ、GUIクライアントでは、設定できる内容がそれぞれ異なります。クライアント名にClashが含まれているだけで、すべての設定項目をそのまま使えるとは限りません。

1. 使用中のカーネルを確認する。クライアントの「バージョン情報」または「カーネル」画面でバージョン文字列を控えてください。unknown fieldやunsupported stackなどのエラーが出た場合は、ノードを何度も切り替えるのではなく、そのバージョンが対応する設定項目を確認します。
2. 現在の設定をバックアップする。使用中の設定ファイルを保存し、ルールモード、DNS、TUNの設定画面も記録しておきます。元に戻す際は、まずTUNを無効にしてから設定を復元してください。
3. 設定の変更箇所を確認する。サブスクリプションの設定は、更新時に上書きされることがあります。クライアントに上書き設定、設定のマージ、TUN設定パネルがある場合は、そちらを優先してください。サブスクリプションのキャッシュファイルを直接編集しても、一時的な変更にしかならないことがほとんどです。
4. ほかのVPNはいったん終了する。まずは通信経路を1つに絞ってください。企業VPN、ゲーム用アクセラレーター、別のTUNクライアントが同時にデフォルトルートを変更すると、問題の原因を特定しにくくなります。

初回のテストではシステムプロキシを無効にし、TUNだけを有効にすると、ブラウザーが古いプロキシポートを経由する影響を減らせます。これは通信の取り込みを確認するためであり、システムプロキシとTUNを必ず別々に使う必要があるという意味ではありません。テスト後、クライアントの推奨に従って併用するか判断してください。

mihomoの設定：TUN、Fake-IP、auto-route

以下は既存設定にマージするトップレベルの設定例で、サブスクリプション全体ではありません。既存のproxies、proxy-groups、rulesはそのまま残してください。元のファイルにdnsまたはtunがある場合は、該当する設定をマージし、同名のトップレベルキーを重複して追加しないでください。例ではmixed-portに7890、DNSの待ち受けに127.0.0.1:1053を使用しています。用途は異なります。

mixed-port: 7890
mode: rule

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

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

各フィールドの役割

• stack: mixed：この値に対応するmihomoでは、システムとユーザー空間のネットワークスタックを組み合わせて使用します。現在のクライアントが対応していない場合は、カーネルのドキュメントに従ってsystemまたはgvisorを選んでください。スタックの切り替えは万能なトラブル解決策ではありません。
• auto-route: true：カーネルが、TUNに通信を流すためのルートを自動設定します。管理者権限の代わりにはならず、外部VPNのすべてのルートを取り込めるとは限りません。
• auto-detect-interface: true：実際に使う送信インターフェースを検出し、プロキシの送信通信が再びTUNに入るのを防ぎます。複数のネットワークインターフェース、テザリング、企業VPNの環境では、検出結果も確認してください。
• dns-hijack：TUNに入った通信のうち、対象となる通常のポート53へのDNSリクエストをカーネルDNSに渡します。例ではUDPとTCPのポート53へのリクエストを対象にしています。
• enhanced-mode: fake-ip：仮想IPアドレスを返し、ドメインとの対応関係をカーネル内に保存します。これらのアドレスへの接続時に、カーネルがドメインを特定して通信を振り分けられます。

198.18.0.1/16はベンチマーク用途のアドレス範囲で、実際のWebサイトの接続先ではありません。名前解決でこの範囲のアドレスが返るのは、Fake-IPの想定どおりの動作です。利用中のネットワークでも同じ範囲が使われている場合は、アドレスの競合を先に確認してください。仮想アドレスを通常のグローバルIPとして固定の直接接続ルートに設定しないでください。

Fake-IPフィルターと暗号化DNSの注意点

fake-ip-filterに指定したドメインには実際のアドレスが返されますが、それだけで接続がDIRECTになるわけではありません。LAN内のサービスも、ルールで適切に振り分ける必要があります。例にある*.localも、mDNSによるマルチキャスト検出の代わりにはなりません。プリンターや画面ミラーリング機器が見つからない場合は、ローカルネットワークの権限とマルチキャストの経路も確認してください。

ブラウザー内蔵のDoHは通常443番ポート、DoTは853番ポートを使用するため、上記のポート53へのDNSハイジャックでは直接取り込めません。原因を調べる際は、ブラウザーの「セキュアDNS」とAndroidの「プライベートDNS」を一時的に無効にして、まずシステムDNSの経路を確認します。その後、長期的に使う名前解決の方式を決めてください。

OS別：TUNを有効にする手順

Windows：サービスをインストールしてから仮想ネットワークインターフェースを有効にする

1. 設定を読み込み、Ruleモードを選択します。まずシステムプロキシ経由でノードに接続できることを確認してください。
2. クライアント設定で「サービスモード」の項目を探し、サービスのインストールボタンがある場合は、案内に従って管理者権限を許可します。サービスモードがないクライアントでは、管理者としての実行が必要な場合があります。
3. 「TUNモード」または「仮想ネットワークインターフェース」と表示された設定を有効にします。メニュー名はクライアントによって異なります。「システムプロキシ」の設定をTUNと混同しないでください。
4. ログに仮想ネットワークインターフェースの作成とルート設定の成功が記録されていることを確認し、その後システムプロキシを無効にして単独で動作を確認します。

route printを実行するとルートを確認できます。インターフェース名やルートのプレフィックスは、カーネルやOSのバージョンによって変わるため、特定の名前が表示される必要はありません。ログにaccess deniedやoperation not permittedと表示された場合は、DNSアドレスを変更するのではなく、権限またはサービスの状態を先に確認してください。

macOS：補助サービスとルート設定の権限を確認する

TUN対応クライアントに必要な補助サービスをインストールしてから、TUNを有効にします。ネットワーク拡張機能やバックグラウンドサービスの許可を求められた場合は、アプリ名を確認してから許可してください。すべてのクライアントが同じ認証方式を使うわけではありません。Wi-Fi、有線LAN、テザリングを切り替えた後は、送信インターフェースが正しく認識されているか再確認してください。

ターミナルでnetstat -rnを実行するとルートを、scutil --dnsを実行するとシステムのリゾルバーを確認できます。システム上に複数のutunインターフェースが存在する場合があります。utunが表示されただけではClashによる取り込みを確認できないため、クライアントの接続ログもあわせて確認してください。

Linux：ネットワークデバイスとネットワーク管理権限を確認する

/dev/net/tunが存在することを確認してください。ルートの自動設定には、ネットワーク管理権限が必要です。たとえば、管理されたサービスを通じてCAP_NET_ADMINを付与します。起動するためだけに、デスクトップクライアントへ不要な高権限を常時与えないでください。コンテナー環境では、TUNデバイスと必要な権限も明示的に許可する必要があります。ホスト側で使えても、コンテナー内で使えるとは限りません。

ip rule、ip route show table all、resolvectl statusを使い、ポリシールーティング、すべてのルートテーブル、名前解決の状態をそれぞれ確認します。メインのルートテーブルだけを見ると、カーネルが作成したポリシールートを見落とす場合があります。

Android・iOS：システムVPNの許可を使う

Androidでは、この機能に対応したクライアントは通常、VpnServiceを通じて通信を取り込みます。接続時にシステムのVPNリクエストを許可し、「アプリごとのプロキシ」でテスト対象のアプリが除外されていないか確認してください。バッテリーのバックグラウンド制限により、画面ロック後に接続が切れることがあります。「常時接続VPN」と「VPNを使用しない接続をブロック」は追加のシステム設定です。通常の接続が安定してから有効にしてください。

iOSとiPadOSでは、使用する設定形式に対応したクライアントを選び、システムのVPN構成を許可してネットワーク拡張機能を起動します。デスクトップ版のドライバーをインストールする手順や管理者権限を取得する手順は使えません。モバイルアプリによってはルートとDNSを独自に管理し、デスクトップ向けのtunフィールドを無視する場合もあります。クライアントが対応する設定範囲を確認してください。システムVPNが接続済みでも、サブスクリプション内のすべてのルールが使えるとは限りません。

通信の取り込みを確認する：入口、DNS、出口を個別にテスト

Webページが1つ開けただけでは、TUN、DNS、ルールがすべて想定どおり動作しているとは判断できません。以下の順でテストし、一度に変更する条件は1つに絞ってください。アプリ、対象ドメイン、適用ルール、実際の接続先を記録します。

1. プロキシ設定を使わないアプリでテストする。システムプロキシを無効にし、ターミナルのHTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を削除してから、以下のコマンドを実行します。接続がクライアントのログに表示されることを確認してください。
2. カーネルDNSをテストする。ローカルの1053番ポートに問い合わせ、応答を確認します。フィルター対象外の通常のドメインは、Fake-IPモードでは通常198.18のアドレス範囲が返されます。
3. システムDNSをテストする。OSの標準設定で名前解決を実行し、ログからカーネルを経由しているか確認します。1053番ポートへの直接問い合わせが成功しても、システムからのリクエストがハイジャックされているとは限りません。
4. ルールの出口を確認する。直接接続される想定の宛先とプロキシ経由になる想定の宛先にそれぞれ接続し、接続ログのルールとポリシーグループを確認します。「カーネルに取り込まれた」ことと「プロキシノードを使用した」ことを混同しないでください。

# Windows PowerShell：現在のセッションにプロキシ環境変数がないことを確認
Get-ChildItem Env: | Where-Object Name -Match 'proxy'
curl.exe --noproxy "*" -I https://example.com
nslookup example.com

# macOS / Linux：curlの--noproxyは明示的なプロキシを迂回しますが、TUNは迂回しません
curl --noproxy '*' -I https://example.com
dig @127.0.0.1 -p 1053 example.com A
nslookup example.com

ツールがインストールされていない場合、コマンドを実行するためにシステムを変更する必要はありません。代わりにクライアントのDNS検索機能を使えます。UDPをテストする際は、UDP対応を確認済みのノードとアプリを選んでください。一般的なHTTPSページが開けても、ゲームのUDP通信やQUICが使えるとは限りません。

よくあるトラブル：権限、ルート、DNSの順に確認

strict-routeは、最初からむやみに追加しない

一部のmihomo設定ではstrict-routeを利用でき、ルートの制約を強められます。プラットフォームによってはDNSの経路にも影響します。LAN、仮想マシン、ほかのVPNへの接続性が変わる可能性があります。まず最小限の設定で動作を確認し、使用中のカーネルのドキュメントと実際の要件に応じて追加してください。「プロキシをより徹底する」ための万能設定ではありません。

終了後もネットワークに接続できない場合の復旧方法

まずクライアント内でTUNを無効にし、カーネルにルートを正常に解除させてから、クライアントを終了します。システムプロキシが、停止済みの127.0.0.1:7890を参照したままになっていないか、DNSに手動設定が残っていないか確認してください。その後、ネットワークに再接続します。必要に応じてクライアントのサービス修復機能を使ってください。企業管理下のデバイスでは、業務ネットワークに必要な設定を削除するおそれがあるため、ルートテーブル全体を消去しないでください。