Clashの仮想NICで全通信を取り込む方法｜TUNの有効化・権限設定・DNSハイジャック

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

ブラウザーはネットにつながるのに、ゲームやターミナルのアプリがClashの接続一覧に表示されない。よくある原因は、アプリがシステムプロキシを参照していないことです。システムプロキシはアプリにHTTPまたはSOCKSプロキシの接続先を知らせる仕組みです。一方、TUNモードは仮想ネットワークインターフェースを作成し、ルーティングによってIPパケットをコアへ転送するため、アプリ側でプロキシプロトコルに対応する必要がありません。

この記事の設定項目は、mihomoコアを使うクライアントを主な対象としています。Clashはクライアントのエコシステムで広く使われる名称ですが、同じ名前のすべてのクライアントや旧バージョンが同じTUN機能に対応しているわけではありません。操作前に「バージョン情報」や「コア」の画面で、クライアントのバージョン、コア名、コアのバージョンを確認してください。旧版のClashコアを使っている場合は、mihomoの設定項目をそのまま適用しないでください。

「全通信」にも例外があります。対象外に設定したアプリやネットワーク、取り込み設定のないIPv6通信、ほかのVPN専用ルートなどはTUNを経由しない場合があります。LAN内アクセスやマルチキャストによる機器検出、システム用の通信も、必ずリモートプロキシを通すべきものとは限りません。スイッチの色だけで判断せず、接続記録と実際のルートを確認してください。

2. 有効化前の確認：ノード、権限、ほかのVPN

まず、既存の設定が使えることを確認します。サブスクリプションをインポートし、設定と利用可能なノードを選んで、システムプロキシ経由でアクセス可能なHTTPSページを開きます。ノード自体に接続できない場合、TUNを有効にしても解決しません。
現在の設定を保存します。設定をバックアップし、システムプロキシ、DNS、TUN、サービスモードの現在の状態を記録してください。サブスクリプションURL、アクセストークン、ノードのパスワードを公開ログに貼り付けないでください。
ほかのVPNを一時的に終了します。ゲーム用の通信サービス、企業VPN、別のプロキシクライアントなどが対象です。デフォルトルートやDNSの設定を競合して変更する可能性があります。企業管理下の端末では、事前に管理ポリシーを確認してください。
プロキシプロトコルの対応状況を確認します。TUNでUDPを受信できても、選択したノードやサーバーがUDP転送に対応しているとは限りません。ゲーム、音声通話、QUICが使えるかは、それぞれ個別に確認してください。

デスクトップでは、仮想NICの作成やルートの設定に、通常、管理者権限、root権限、または制御された特権ヘルパーが必要です。AndroidではシステムのVPN権限を使います。デスクトップの「サービスモード」とは異なり、通常は端末のroot化も必要ありません。

3. 4つのプラットフォームでの有効化手順と権限

以下のデスクトップ向け手順は、Clash Verge Revなどmihomo対応のGUIクライアントで一般的な画面構成を例にしています。ディストリビューションによって「TUNモード」が「仮想NICモード」と表記される場合があります。同じ名前の項目が見つからないときは、使用中のバージョンの設定ガイドを確認してください。出所の不明な「汎用ドライバーパッチ」はダウンロードしないでください。

Windows：サービスをインストールしてから仮想NICを有効化

「設定」→「サービスモード」を開き、インストールまたは有効化を実行します。WindowsのUAC確認画面が表示されたら、内容を確認して許可してください。このバージョンでサービスの項目が「設定」→「システム設定」にある場合は、実際の画面に従ってください。
サービスの状態が「実行中」になっていることを確認し、「設定」→「TUNモード」または「仮想NICモード」を開いて有効にします。初回の有効化後は、ネットワークインターフェースの初期化が終わるまで待ち、スイッチを何度も切り替えないでください。
ログを開き、権限拒否、インターフェース作成失敗、ルート追加失敗などのエラーがないか確認します。WindowsクライアントではWintunなどのコンポーネントを使う場合があります。ドライバーファイルの提供方法はクライアントによって異なります。
「接続」画面を開き、これまでシステムプロキシを参照していなかったアプリを起動して、新しい記録が追加されるか確認します。適用されたルールとプロキシグループも確認してください。

サービスモードは、権限が必要な操作を制御されたバックグラウンドサービスに実行させるための機能です。サービスモードを使えばプロキシが必ず起動するわけではありません。画面に「サービスはインストール済み」と表示されても失敗する場合は、サービスが実行中か、コアのプロセスが起動しているか、セキュリティソフトがネットワークコンポーネントをブロックしていないかを確認してください。ファイアウォールを恒久的に無効化して対処しないでください。

macOS：ヘルパーサービスを許可し、utunインターフェースを確認

クライアントの「設定」→「サービスモード」でヘルパーサービスをインストールまたは修復し、システムの指示に従って管理者の認証情報を入力します。管理者パスワードをサブスクリプションのインポート画面やノード設定に入力しないでください。
「TUNモード」を有効にし、クライアントに必要なシステム権限を許可します。表示される権限確認画面は、クライアントの実装やmacOSのバージョンによって異なります。
ターミナルでifconfigを実行してインターフェースを確認し、netstat -rnでルートを確認します。macOSでは通常、utunインターフェースが使われます。

macOSでは、もともと複数のutunインターフェースが存在する場合があります。そのため、utunが表示されても、現在のClashが通信を取り込んでいるとは限りません。有効化前後のルートの変化とクライアントのログを合わせて確認してください。macOSの一般的なTUN実装はシステムインターフェースを使うため、WindowsのWintunのインストール手順を適用しないでください。

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

GUIクライアントでは、まず付属のサービスモードを使ってください。mihomoを直接実行する場合は、ディストリビューションのドキュメントに従ってsystemdサービスと権限を設定します。デバイスが存在するか、次のコマンドで確認できます。

ls -l /dev/net/tun
ip link show
ip route show
ip -6 route show

/dev/net/tunが存在しない場合は、カーネルのTUN対応状況、モジュールの読み込み、コンテナへのデバイスの割り当てを確認してください。インターフェースの作成やルートの変更には、通常CAP_NET_ADMINが必要です。コンテナ内では、プロセスがrootで実行されていても必要な権限がない場合があります。GUIクライアント全体に、範囲の広い特権を恒久的に付与しないでください。

有効化後、ip rule showとルーティングテーブルを確認し、NetworkManager、コンテナネットワーク、ほかのVPNとのルールの競合を調べます。一部のmihomoバージョンにはLinux専用のauto-redirectがありますが、この機能は本ガイドの全プラットフォーム共通の前提ではありません。すべての端末に機械的に追加しないでください。

Android：VPN接続を許可し、アプリごとの設定を確認

mihomo対応のAndroidクライアントに設定をインポートし、ホーム画面の起動または接続ボタンをタップします。
初回起動時にAndroidの「接続リクエスト」が表示されたら、VPN接続を許可します。Androidクライアントは通常、VpnServiceで仮想インターフェースを作成するため、デスクトップ用ドライバーを別途インストールする必要はありません。
クライアントの「設定」で「アクセス制御」または「アプリごとのプロキシ」を確認します。「選択したアプリのみプロキシを使用」が有効な場合、選択されていないアプリの通信は取り込まれません。
バックグラウンドに移動すると接続が切れる場合は、システムの「設定」→「アプリ」→使用中のクライアント→「バッテリー」でバックグラウンド制限を確認します。項目名はAndroidのバージョンや端末によって異なります。

同じユーザー設定では、通常、VpnServiceを使うVPNを同時に維持できるのは1つです。別のVPN、広告ブロッカー、ゲーム用の通信サービスを起動すると、現在の接続が置き換えられる場合があります。「VPNを常時ON」や「VPNを経由しない接続をブロック」はシステム全体に適用される設定です。設定を誤るとネットに接続できなくなるため、基本的な動作確認が済んでから有効にしてください。

4. stackの選び方：system・gvisor・mixed

stackはTUN内でネットワーク通信を処理するプロトコルスタックの設定であり、プロキシプロトコルやノードの種類ではありません。mihomoでよく使われる値はsystem、gvisor、mixedですが、利用できる値はコアのビルドやプラットフォームによって異なります。

設定値	主な違い	設定の目安
`system`	システムのプロトコルスタックを利用して通信を処理	クライアントの初期設定で正常に接続できるなら、そのまま使います。
`gvisor`	ユーザー空間のネットワークプロトコルスタックを利用	互換性の問題がある場合に、比較用として試します。
`mixed`	mihomoでTCPにはsystem、UDPにはgvisorを使用	TCPとUDPの動作をそれぞれ確認します。Webページの表示だけでは判断できません。

特定のstackを「ゲームに最適な設定」と決めつけないでください。まずはクライアントの初期値を維持します。特定のアプリで接続に問題が出た場合は、一度に1つの設定だけを変更し、TUNを再起動して確認してください。MTUも同様に、まずは初期値を使います。大きなパケットの転送が止まる、トンネルのカプセル化が関係しているなど、原因を示す情報がある場合に限って調整してください。遅延が一度高かっただけで、安易に9000へ変更しないでください。

5. DNSハイジャックの設定：53番ポートの問い合わせを取り込む

アプリはドメイン名をIPアドレスに変換してから接続します。DNS問い合わせが想定した名前解決経路を通らないと、ドメインルールが期待どおりに動作しない、解決結果が不正になる、接続がタイムアウトするといった問題が起きる場合があります。TUNのdns-hijackは、条件に一致する従来型DNSの問い合わせをmihomoのDNSモジュールに転送する機能です。ここでいう「ハイジャック」は端末内での転送を指し、リモートサイトを書き換えるものではありません。

mihomoの設定例

以下の例では、IPv4 TUN、自動ルート、UDP/TCPの53番ポートの取り込みを有効にします。設定ファイル全体ではなく、既存のサブスクリプションを置き換えるものではありません。まずバックアップを取り、クライアントが対応する上書きまたはマージ機能で適用してください。すでにtunまたはdnsフィールドがある場合は、その内容にマージし、YAMLのトップレベルに同じキーを重複して追加しないでください。

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

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
    - 119.29.29.29

auto-route：通信の取り込みに必要なルートをコアが自動設定します。除外対象のルートや、ほかのソフトに優先されたルートまで取り込めるとは限りません。
auto-detect-interface：送信インターフェースを自動選択します。複数のNIC、テザリング、企業VPNを使う環境では、選択結果を確認してください。
any:53とtcp://any:53：従来型のUDPおよびTCPのDNS問い合わせにそれぞれ一致します。実際に一致するかどうかは、通信がTUNに取り込まれるかにも左右されます。
127.0.0.1:1053：ローカルDNSの待ち受けアドレスです。通常、システムのDNS設定には1053番ポート付きのアドレスを直接指定できません。この例ではTUNを使って問い合わせを転送します。
nameserver：この例では、従来型DNSの上流サーバーを2つ指定しています。実際にはネットワークからの到達性、プライバシー要件、通信の振り分け方に応じて選んでください。すべてのネットワークで使えるとは限りません。

Fake-IPが予約済みアドレスを返すのは、アドレスを対応付ける仕組み

上記の設定では、DNSが198.18.0.0/16の範囲にあるマッピング用アドレスを返し、コアが接続先を元のドメイン名に対応付ける場合があります。これは接続先サイトの実際のグローバルIPアドレスではありません。LAN機器の検出、特定のゲーム、社内ドメインなどで問題が起きる場合は、対象のドメインをfake-ip-filterに追加するか、クライアントが対応する別のDNSモードを使ってください。DNS設定全体を削除しないでください。

Androidでは「プライベートDNS」も個別に確認してください。アプリがコアのDNSを経由せず、別の名前解決経路を使う場合は、そのアプリの接続と通信の振り分け結果を確認します。IPv6も経路全体を通して設定する必要があります。この例にはIPv6の取り込み設定がないため、IPv6も取り込まれるとは言えません。デュアルスタックを有効にする前に、コア、ルート、DNSの応答、ノードの対応状況を確認してください。

6. 3段階で確認：インターフェース・接続記録・DNS

インターフェースとルートを確認します。ログでTUNの起動成功を確認してください。リトライが繰り返されている場合は正常に起動していません。Windowsではroute print、macOSではnetstat -rn、Linuxではip route showを実行して変化を確認します。実装によっては分割ルートやポリシールートを作成するため、デフォルトルートが直接置き換わるとは限りません。
システムプロキシを使わないアプリがコアに届いているか確認します。そのアプリ独自のプロキシ設定を無効にして接続し直し、Clashの「接続」画面を確認してください。デスクトップでは比較のためにシステムプロキシを一時的に無効にし、TUNだけを使って確認できます。企業管理下の端末では、管理対象の設定を勝手に変更しないでください。
DNSの応答とルールの適用結果を確認します。キャッシュされていないドメインを検索し、ログ、DNSの応答、その後の接続が一致しているか確認してください。Fake-IPモードでマッピング用アドレスが返ること自体はエラーではありません。接続できるか、想定したポリシーが適用されているかを確認しましょう。

たとえば、次のコマンドでHTTPSリクエストを1回実行できます。これは通信経路の確認用であり、速度測定や実測性能の結果を示すものではありません。

curl --noproxy "*" -I --connect-timeout 10 https://example.com

--noproxy "*"はcurlの通常のプロキシ設定を迂回し、TUN経由の通信を確認しやすくするオプションです。Windows PowerShellではコマンドのエイリアスによる違いを避けるため、curl.exeを明示して実行してください。実行後は接続一覧で対象ドメイン、適用ルール、送信先ポリシーを確認します。コマンドが成功しただけでは、リモートプロキシ経由だとは証明できません。

7. よくあるトラブルと安全な復旧方法

TUNを有効にしたら、すべてのWebページが開けなくなった

まずTUNを無効にし、基本のネットワーク接続が戻るか確認します。そのうえでサービス権限、現在の設定、DNS上流への到達性、ほかのVPNを確認してください。無効にしても名前解決できない場合は、手動設定したDNSやシステムプロキシが残っていないか確認し、操作前に記録した状態へ戻します。クライアントを再インストールしながらノード、stack、DNSも同時に変更すると、原因を特定しにくくなります。

Webページは開けるのに、ゲームや音声通話が使えない

まず対象のプロセスが接続一覧に表示されるか確認し、次にUDPがノードでサポートされているか確認します。ブラウザーでWebページが開けても、確認できるのは通常、一部のTCPまたはHTTPS通信だけです。Androidではゲームがアプリごとの振り分け設定で除外されていないか、デスクトップではゲームが特定のNICにバインドされていないか、ほかのゲーム用通信サービスのルートがないかを確認してください。

LANプリンター、NAS、社内ドメインに接続できない

まず、接続先に必要なのが直接接続か企業VPNのルートかを確認します。そのうえで該当するルール、DNSの名前解決方法、TUNのルート除外を調整してください。ルールのDIRECTとルート除外は異なります。DIRECTはコアで処理したうえで直接接続しますが、ルート除外では指定した通信をTUNに入れません。社内DNSに依存するドメインは、通常、パブリックDNSでは代替できません。

クライアントを終了した後もネットワークが復旧しない

まずクライアントを再度起動し、TUNを正常に無効化してから終了してください。これにより、クライアントが後処理を実行できます。続いてシステムプロキシ、DNS、サービスの状態を確認します。リモートサーバーを操作する場合は特に注意してください。デフォルトルートの変更でSSH接続が切れることがあります。事前にコンソールやアウトオブバンド接続を用意し、唯一の管理接続上で直接試さないでください。