ClashのTUNモード解説｜仮想NICによる全通信の処理と各プラットフォームでの設定方法

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

システムプロキシは、アプリに設定するプロキシアドレスです。ブラウザーはこの設定を読み取り、ローカルのHTTPプロキシポートへリクエストを送信できます。一方、独自に接続するゲームやコマンドラインツール、一部のデスクトップアプリは設定を参照しない場合があります。システムプロキシを有効にしても、すべてのアプリの通信がClashを経由するとは限りません。

TUNはネットワーク層で動作する仮想インターフェースです。クライアントがインターフェースを作成し、システムルートを変更して、条件に合うIPパケットをカーネルへ送ります。カーネルはTCPやUDPなどの通信を処理し、ルールに応じて直接接続、プロキシ経由、拒否を選択します。通常、アプリ側でプロキシアドレスを個別に設定する必要はありませんが、ルートやアプリの除外設定、プラットフォームの制約が影響する場合があります。

この記事のYAML例は、Clash Metaの後継プロジェクトであるmihomoを対象としています。Clashの各派生版では、設定項目やプラットフォーム対応が異なります。まずクライアントの「バージョン情報」またはカーネル情報でカーネル名を確認し、該当するドキュメントを参照してください。画面にTUNのスイッチがあっても、古いカーネルが以下の設定項目すべてに対応しているとは限りません。

仮想NIC・ルーティングテーブル・DNSの連携

通信が処理される流れ

1. アプリがドメイン名を名前解決するか、IPアドレスへ直接接続します。
2. OSがルーティングテーブルに基づいて通信の出口を選びます。自動ルートを有効にすると、対象の通信はTUNインターフェースへ送られます。
3. カーネルが宛先を取得し、DNSの対応情報、ルール、必要に応じてスニッフィング情報を使って照合します。
4. プロキシ対象の通信は選択したノードから送信され、直接接続の通信は実際のネットワークインターフェースから送信されます。

プロキシサーバーへ接続するカーネルの通信は、実際のネットワーク出口から送信する必要があります。再び自分自身へ流れ込んではいけません。auto-detect-interfaceは送信インターフェースを自動検出し、ルーティングループの発生リスクを抑えます。Wi-Fiの切り替え、有線LANへの接続、ほかのVPNの有効・無効化後は、使用するインターフェースが変わる場合があります。ログとルートを再確認してください。

DNSハイジャックですべての暗号化DNSを遮断できるわけではない

dns-hijackを使うと、条件に合うDNS通信をカーネルのDNSモジュールへ渡せます。たとえばUDP 53やTCP 53が対象です。ブラウザーがHTTPSで外部の名前解決サービスに接続する場合、リクエストは通常443番ポートを使うため、一般的な53番ポートのDNSクエリには該当しません。any:53を1行設定しただけで、すべての名前解決を取り込めたと判断することはできません。

fake-ipを使用すると、カーネルは対応するIPアドレスを返し、後続の通信からドメイン名を復元します。例の198.18.0.1/16は、内部マッピング用の専用テストアドレス空間であり、プロキシサーバーのアドレスではありません。実際の名前解決結果を必要とするLAN機器やアプリでは、ドメインごとにfake-ip-filterを設定する必要がある場合があります。多数のドメインをまとめて除外するのは避けてください。

mihomoのTUN設定とstackの選び方

以下は既存の設定に追加する例です。ノード、プロキシグループ、ルールは含まれておらず、完全なサブスクリプション設定の代わりにはなりません。まず設定をバックアップし、クライアントが対応するオーバーライドまたはマージ機能で追加してください。サブスクリプションの更新でローカルの変更が上書きされるのを防げます。同名の項目がすでにある場合は内容を統合し、YAMLのトップレベルにdnsやtunを重複して記述しないでください。

mixed-port: 7890
mode: rule

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

• mixed-port: 7890は、この例でHTTPとSOCKSを受け付ける混合プロキシポートです。TUNがパケットを受け取るためのポートではありません。別の未使用ポートに変更しても、仮想インターフェースのルートが直接変わることはありません。
• listen: 127.0.0.1:1053は、カーネルDNSのローカル待ち受けアドレスです。システムDNSに「127.0.0.1:1053」を設定するという意味ではありません。多くのシステムのDNS設定で指定できるのはサーバーのIPアドレスで、ポート番号付きの形式は受け付けられません。
• auto-routeは関連するルートを自動追加し、auto-detect-interfaceは実際の送信インターフェースを検出します。どちらもノードの速度測定や自動選択を行う機能ではありません。
• 例に示すDNSサーバーは、設定項目の構成を説明するためのものです。実際の環境では、ネットワークからの到達性、名前解決の方針、プライバシー要件に応じて上流DNSを選んでください。例のアドレスがどのネットワークでも使える固定の正解というわけではありません。

system・gvisor・mixedの違い

特定のstackを「常に最速のモード」と決めつけないでください。スループット、CPU使用率、互換性は、OS、カーネルのビルド、ノードのプロトコル、アプリの負荷によって変わります。切り分けでは同じノードとテスト先を使い、stackの設定だけを一度に1つ変更してください。接続を張り直してから比較します。古い接続が残っていると、以前の処理経路で結果が出る場合があります。

Windows：サービス権限と仮想NICの確認

Windows 10・Windows 11では、仮想インターフェースの作成やルートの変更に適切な権限が必要です。デスクトップクライアントは、管理者としての起動やバックグラウンドサービスを通じてカーネルを動かすことがよくあります。「スタートアップ」と「サービスモード」は別の設定です。サービスをインストールした後は、実際に起動していることも確認してください。

1. まずTUNを無効にし、設定を読み込んで利用可能なノードを選びます。システムプロキシでテストページを開き、サブスクリプションとノードが正常に動作することを確認してください。
2. クライアントの設定で「サービスモード」を探し、案内に従ってサービスをインストールして起動します。またはクライアントの説明に沿って、管理者として起動してください。Windowsのユーザーアカウント制御が表示された場合は、プログラムのパスを確認します。
3. システムプロキシを一時的にオフにしてから、「仮想NICモード」または「TUN」を有効にします。これにより、システムプロキシの効果をTUNの動作と誤認しにくくなります。
4. 「設定」→「ネットワークとインターネット」→「ネットワークの詳細設定」を開き、ネットワークアダプターに変化があるか確認します。インターフェース名はクライアントとカーネルの設定によって異なるため、Clashという名前である必要はありません。
5. クライアントの接続一覧を開き、プロキシを個別設定していないアプリを起動して、該当する接続とルールの一致が表示されることを確認します。

さらに確認が必要な場合は、PowerShellで以下の読み取り専用コマンドを実行します。タスクバーの接続アイコンだけでなく、新しく追加されたインターフェース、ルートのインターフェースインデックス、DNSサーバーを確認してください。

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
Get-DnsClientServerAddress
Get-NetTCPConnection -State Listen -LocalPort 7890

最後のコマンドで確認できるのは、この例のプロキシポートが待ち受け中かどうかだけです。TUNが正常である証明にはなりません。ログに権限不足が表示された場合は、まずサービスの権限を確認します。ポートが使用中の場合は、待ち受けているプロセスを調べてください。インターフェース作成の失敗を解決するために、システムファイアウォール全体を無効にするのは避けてください。

macOS：ヘルパーサービスとutunルートの確認

macOSのクライアントは通常、特権ヘルパーサービスを使ってTUNを作成・管理します。システムネットワーク拡張を使うクライアントもあります。許可の手順はクライアントの実装によって異なるため、特定のアプリのメニューをすべてのアプリに当てはめないでください。ダウンロードとインストールの際は、Appleシリコン版とIntel版も区別してください。

1. まずシステムプロキシでノードを確認し、クライアントの案内に従ってヘルパーサービスをインストールするか、ネットワーク拡張を許可します。管理者パスワードを入力する前に、許可を求めているのが現在インストールしたクライアントであることを確認してください。
2. TUNを有効にします。バックグラウンドコンポーネントの許可が必要と表示された場合は、案内に従って「システム設定」→「一般」→「ログイン項目と機能拡張」を開き、該当項目を確認してください。macOSのバージョンによって項目名が多少異なる場合があります。
3. システムプロキシを一時的にオフにしてテストアプリを再度開き、接続が引き続きクライアントのカーネルに取り込まれているか確認します。
4. スリープからの復帰後やネットワークの切り替え後にも再テストしてください。復帰後だけ動作しない場合は、その時点の送信インターフェースとカーネルログを記録し、TUNを再起動して確認します。

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1
scutil --dns

utunインターフェースは、ほかのシステムサービスやVPNでも使われることがあります。utun0が見えても、それが現在のクライアントのものとは限りません。番号も固定ではありません。TUNの有効化前後でインターフェースとルートを比較し、クライアントのログとあわせて判断してください。ルート検索で分かるのは対象IPの経路だけであり、すべてのDNS名前解決やIPv6通信がカーネルに取り込まれていることまでは証明できません。

Android：VPNの許可・アプリの対象範囲・バックグラウンド制限

Androidクライアントは通常、システムのVpnServiceを使って仮想インターフェースを提供するため、一般ユーザーがroot権限を取得する必要はありません。初回接続時にシステムのVPN許可ダイアログが表示されます。Androidの「VPNモード」はデスクトップ版のTUNと目的が近いものの、インターフェースやルートはアプリ側が管理することが多いため、デスクトップ向けのauto-route設定をそのまま流用しないでください。

1. サブスクリプションを読み込んでプロキシグループを選び、接続を開始します。システムのVPN許可画面でアプリ名を確認してから許可してください。
2. クライアントでアプリごとの振り分け設定を確認します。「選択したアプリのみプロキシ」を使う場合、選択していないアプリはVPNアイコンが表示されても自動的にはプロキシを経由しません。
3. Android 13では、一般的に「設定」→「ネットワークとインターネット」→「VPN」から現在のVPNを確認できます。メーカー独自のOSでは「接続と共有」などに項目がある場合があります。設定内で「VPN」を検索する方法もあります。
4. クライアントのアプリ情報を開き、「バッテリー」または「アプリのバッテリー使用量」で必要に応じてバックグラウンド実行を許可します。画面ロック後だけ切断される場合は、まず省電力設定とバックグラウンド制限を確認してください。
5. 「常時接続VPN」または「VPNなしの接続をブロック」を有効にしている場合は、まずクライアントが安定して再接続できることを確認してください。後者を有効にすると、VPNが切断された際にネットワーク接続そのものが遮断されることがあります。

同じユーザーまたは仕事用プロファイルでは、通常、VpnServiceを使うアプリを1つだけ有効にできます。別のVPNや、ローカルVPNを使うフィルタリング・パケットキャプチャアプリを起動すると、現在の接続が置き換わる場合があります。その際はサブスクリプションを何度も読み込み直すのではなく、システムで現在許可されているVPNアプリを確認してください。

TUNを有効にしたら通信できない：接続の層ごとに確認

まずノードの問題と通信取り込みの問題を切り分ける

TUNをオフにしてシステムプロキシに戻し、同じノードで同じ接続先にアクセスします。それでも失敗する場合は、ノード、サブスクリプション、プロキシグループを先に確認してください。システムプロキシでは正常でTUNだけ失敗する場合は、権限、ルート、DNS、ほかのVPNを調べます。ポート、stack、DNSを一度に変更するより、この比較のほうが原因を絞り込みやすくなります。

• ブラウザーは使えるがゲームは接続できない：ゲームの通信がクライアントに表示されるか、ノードがUDPに対応しているか、ルールが接続先を想定したプロキシグループへ振り分けているか確認します。HTTPのWebページが開けても、UDPの通信経路が使えるとは限りません。
• IPアドレスには接続できるがドメイン名では失敗する：DNSログ、システムの名前解決設定、ブラウザーのセキュアDNSを確認します。nslookup example.comで応答を確認できますが、ブラウザーが暗号化DNSを使う場合とは経路が異なる可能性があります。
• LAN内のプリンターやNASに接続できない：プライベートアドレスのルート、名前解決、ルールを確認します。LANへの通信は、正しく直接接続するか、対象から除外する必要があります。直接接続のルールを1つ追加するだけでは、誤ったシステムルートが直るとは限りません。
• 一部のWebページの読み込みに時間がかかる：IPv4とIPv6で異なる出口が使われていないか確認し、その後MTUを調べます。固定のMTU値をそのまま適用せず、トンネルの多重化や経路上のパケット分割に問題があるかを先に確認してください。
• クライアントを再起動すると復旧する：古いサービス、重複したカーネルプロセス、ほかのVPNが同時に動作していないか確認します。エラーが発生した時刻を記録し、現象だけでstackの問題と判断しないでください。

動作確認と元に戻す手順

動作確認では、次の3点をあわせて確認します。インターフェースまたはルートが想定どおり変化していること、プロキシを設定していないアプリの通信がカーネルに取り込まれていること、ルールの一致と最終的な出口が想定どおりであることです。VPNアイコン、プロキシポートの待ち受け、ノードの遅延値だけでは十分な確認になりません。

元に戻す場合は、まずクライアントからTUNをオフにし、インターフェースとルートが削除されるのを待ってから、以前の設定に合わせてシステムプロキシを戻します。AndroidでVPN以外の接続をブロックしている場合は、その設定も確認してください。まだ通信できない場合は、手動設定したDNSやプロキシアドレス、ほかのVPNが残っていないか確認します。所属を特定できないネットワークアダプターをむやみに削除しないでください。

よくある質問