Clash TUNモードの設定方法｜仮想NICで全通信を取り込む仕組みと手順

TUNとシステムプロキシの違い：通信の取り込み口は異なっても、ルールによる振り分けは有効

ブラウザーでは目的のサイトを開けるのに、ターミナルやゲーム、特定のデスクトップアプリが接続できない場合、システムプロキシを利用していないことがよくあります。システムプロキシはアプリにHTTPまたはSOCKSプロキシの接続先を提供しますが、この設定を参照するかどうかはアプリ次第です。一方、TUNは仮想NICを作成し、ルーティングによってIPパケットをプロキシのコアに渡します。アプリごとにプロキシ設定へ対応している必要はありません。

ここでいう「すべての通信を取り込む」とは、通信の入口となる範囲を指し、すべての接続がプロキシノードを経由するという意味ではありません。mode: ruleの場合、TUNに入った接続も引き続きrulesに照合され、DIRECT、プロキシグループ、REJECTへ振り分けられます。LAN、除外ルート、ほかのVPN、IPv6の経路によって、実際に取り込まれる範囲が変わることもあります。

比較項目	システムプロキシ	TUNモード
通信の入口	アプリからローカルのプロキシポートへ接続	システムルートから仮想NICへ転送
アプリ側の対応	アプリがプロキシに対応し、利用する必要がある	通常、プロキシアドレスを個別に設定する必要はない
UDP通信	アプリとプロキシプロトコルの対応状況に左右される	コアで処理できるが、接続先ノードもUDPに対応している必要がある
必要な権限	通常はユーザーのプロキシ設定を変更するだけ	NICの作成やルート変更に必要なシステム権限
通信の振り分け	コアに入った後、現在のモードに従って処理	コアに入った後、同様に現在のモードに従って処理

有効化前に確認すること：ノード、権限、設定の上書き

まずシステムプロキシでサブスクリプションとノードが利用できることを確認してから、TUNを有効にします。問題が起きた際に、仮想NICやルート、DNSの問題に絞って調べられ、サブスクリプションやノードの接続性まで同時に疑わずに済みます。現在のモード、プロキシグループの選択、DNS設定を記録し、正常に接続できる設定のバックアップも残しておきましょう。

基本の接続を確認：ルールモードにし、接続できることが分かっているノードを選んで、プロキシが必要なサイトを開きます。ノードの遅延テストに成功しても、テスト先へ接続できたことしか分からず、実際のWebページを開ける保証にはなりません。
コアの権限を確認：デスクトップ版ではサービスモードや補助サービスの状態を確認します。AndroidではVPNの許可を確認してください。一般ユーザー権限で起動したコアでは、仮想NICを作成できない場合があります。
ほかのVPNを一時停止：企業向けVPN、ゲーム用ネットワーク最適化ツール、別のTUNクライアントは、いずれもルートを設定する可能性があります。まずはクライアントを1つだけ起動した状態で確認し、その後に併用をテストしてください。
設定の編集場所を確認：クライアントの設定上書き機能や設定のマージ機能を使うのがおすすめです。サブスクリプションのキャッシュファイルを直接編集すると、次回の更新で変更が消えることがあります。
実際に適用された設定を確認：画面上のスイッチによって、tun.enable、stack、DNS設定が書き換えられることがあります。保存後はエディターの内容だけでなく、実行中の設定も確認してください。

ローカルのプロキシポートとTUNは、通信を取り込む別々の入口です。例のmixed-port: 7890は、アプリからHTTP/SOCKSプロキシへ接続するためのポートです。DNSの待受ポート1053はDNSサービス用です。7890を変更しても仮想NICの作成失敗は解決しません。また、DNSの待受ポートをブラウザーのプロキシ欄に入力しないでください。

Windows・macOS・Linux・Androidでの設定手順

Windows：サービスを起動してからTUNを有効化

Clash Verge Revの一般的な画面を例に説明します。「設定」→「サービスモード」を開き、案内に従ってサービスをインストールして、システムの許可を確認します。サービスが起動してから「TUNモード」を有効にしてください。バージョンによっては関連項目が設定カード内にあり、名称や分類も異なります。スイッチがオンになっているだけでなく、サービスが実際に起動していることを確認しましょう。

有効化後、Windowsの「設定」→「ネットワークとインターネット」→「ネットワークの詳細設定」でアダプターを確認するか、以下のPowerShellコマンドを実行します。仮想NICの名前は設定で指定できるため、Clashの文字列が含まれるとは限りません。NICが存在することは最初の確認項目です。ログでルートとDNSの初期化が成功したかも確認してください。

Get-NetAdapter
Get-NetRoute -AddressFamily IPv4
route print

ログに権限不足やデバイス作成失敗が表示された場合は、まずサービスのインストール状態を確認してください。管理者権限での起動は診断に使えますが、普段はクライアントがサポートするサービス機能を使ってコアを実行するのがおすすめです。ファイアウォールは対象のプログラムやサービスに対して許可を設定し、システム全体のファイアウォールを無効にしたままにしないでください。

macOS：補助サービスとネットワーク権限を確認

mihomoのTUNに対応したクライアントを選び、設定画面の案内に従って補助サービスをインストールしてからTUNを有効にします。システムの許可を求められたら、アプリの提供元を確認して許可してください。サービスのインストール後もスイッチがオンのままにならない場合は、クライアントのログと「システム設定」→「ネットワーク」のネットワークサービスの状態を確認します。権限の確認画面は「システム設定」→「プライバシーとセキュリティ」に表示されることもあります。

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

macOSでよく見られる仮想インターフェース名は、数字が続くutunです。ただし、システムやほかのVPNも同じ種類のインターフェースを作成します。utunが表示されたというだけでは、現在のクライアントが通信を取り込んでいるとは判断できません。起動ログと宛先アドレスのルートをあわせて確認してください。

Linux：TUNデバイスとサービス権限を確認

Linuxでは通常、/dev/net/tunが利用可能で、インターフェース作成とルート変更に必要な権限が必要です。ディストリビューションのパッケージ、デスクトップクライアント、単独で動作するコアサービスでは、権限の設定方法が異なります。それぞれのプロジェクトが提供するサービスのインストール手順を確認してください。コンテナではデバイスのマッピングとネットワーク権限も別途必要なため、一般的なデスクトップ環境の手順をそのまま当てはめることはできません。

ls -l /dev/net/tun
ip link show
ip rule show
ip route show table all

ルートを確認するときは、ポリシールーティングとすべてのルーティングテーブルも確認してください。実装によってはメインテーブルのデフォルトルートを単純に置き換えないため、ip routeだけでは実際の通信経路を見落とすことがあります。手順を簡略化するために、常時稼働するサービスを一律に最高権限で実行しないでください。

Android・iOS：プラットフォームごとの通信取り込み方式

AndroidのGUIクライアントは通常、システムのVPNインターフェースを使って通信を取り込み、初回接続時にVPNの許可を求めます。mihomo対応クライアントを例にすると、設定をインポートしてVPN/TUN方式で起動し、システムのステータスバーにVPNアイコンが表示されていることを確認します。Androidでは通常、一般ユーザーが同時に利用できるVPNサービスは1つです。別のVPNを起動すると、現在の接続が切れる場合があります。

一部のアプリだけ接続できない場合は、クライアントのアプリ別アクセス制御やアプリごとのプロキシ設定を確認してください。除外されたアプリは通信の取り込み対象にならないことがあります。iOSクライアントはNetwork Extensionを通じて通信を取り込むものが多く、設定形式や利用できる項目はクライアントごとに異なります。デスクトップ版mihomoのYAML設定を、すべてのiOSクライアントで使える設定方法としてそのまま流用しないでください。

TUNの設定例：stack、auto-route、DNSハイジャック

以下は既存のmihomo設定に追加するトップレベル項目のマージ例であり、完全な設定ファイルではありません。ノード、サブスクリプションプロバイダー、プロキシグループ、ルールは含まれていないため、元の設定にある項目を残してください。既存のファイルにdnsやtunがある場合は、項目をマージし、同じ名前のトップレベルキーを重複して追加しないでください。

mode: rule
mixed-port: 7890

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.cloudflare.com/dns-query

項目	設定例	用途と注意点
`enable`	`true`	TUNの有効化を要求します。システム権限が必要です。
`stack`	`mixed`	TCPにはsystemスタック、UDPにはgVisorスタックを使用します。
`auto-route`	`true`	通信の取り込みに必要なルートを自動設定します。すべての接続がプロキシノードを選ぶという意味ではありません。
`auto-detect-interface`	`true`	外向きインターフェースを自動検出します。複数のNICやVPNを使う場合は検出結果を確認してください。
`dns-hijack`	`any:53`	TUNに入ったUDP 53番ポートのリクエストを取り込み、内蔵DNSへ渡します。
`enhanced-mode`	`fake-ip`	マッピングアドレスを使って、ドメイン名と後続の接続を関連付けます。

stackの選び方

system：システムのネットワークスタックを使用します。互換性を確認するときの選択肢になりますが、動作はOSや環境によって異なります。
gvisor：ユーザー空間のネットワークスタックを使用します。特定のsystemスタックの問題を切り分ける際に比較できますが、すべてのデバイスで高速になるとは限りません。
mixed：TCPにはsystem、UDPにはgVisorを使用します。まずこの設定で試し、ログやアプリの動作を見ながら調整できます。

一度に変更する項目は1つにして、再接続後に同じアプリでテストしてください。ゲームのボイスチャットが使えない場合は、ノードのプロトコル、サーバー、接続元ネットワークがUDPに対応しているかも確認します。stackを変えても、接続先ノードにない機能を補うことはできません。

default-nameserverはDNS上流サーバーのホスト名解決に、proxy-server-nameserverはプロキシサーバーのホスト名解決に使用します。この例で2種類の名前解決を分けているのは、起動時の名前解決依存ループを減らすためです。実際に使うDNSサーバーは、現在のネットワークから接続でき、プライバシー要件にも合うものを選んでください。DoH上流へのHTTPS接続がプロキシを経由するかどうかは、DNSルーティングの設定にも左右されます。URLにhttpsが含まれているだけで、通信の出口を判断することはできません。

有効化後の確認：通信の入口、ルール、DNSを個別にチェック

テスト中はTUNを有効にしたままシステムプロキシを一時的にオフにし、ブラウザーがローカルポート経由で接続して取り込みの失敗を覆い隠さないようにします。テストするアプリ独自のプロキシ設定も解除してください。まず一般的なWebページを開き、次にシステムプロキシを利用しないアプリを試します。クライアントの「接続」または「ログ」画面で、該当する通信を確認してください。

コアに通信が届いているか確認：新しい接続を発生させ、「接続」画面に宛先のドメイン名またはIPアドレスが表示されるか確認します。ブラウザーが既存の接続を再利用していると、新しい記録がすぐに表示されない場合があります。ページを閉じてから再試行してください。
ルールの適用結果を確認：一致したルールと最終的なポリシーを確認します。中国本土のサイトがDIRECT、海外のサービスがプロキシグループに振り分けられていても、TUNによる通信の取り込みとは矛盾しません。
ドメイン名の解決を確認：クライアントにDNSクエリ機能がある場合は、まずその機能を使ってください。ローカルのDNS待受ポートにクエリを送信し、内蔵DNSが応答するか確認する方法もあります。
UDPを確認：実際のボイスチャットやゲームなど、UDPを使うアプリで確認してください。HTTPのWebページを1回開けただけでは、UDPが使える証拠になりません。

# macOS / Linux：設定例のローカルDNS待受ポートをテスト
dig @127.0.0.1 -p 1053 example.com A

# ドメイン名に接続できるか確認
curl -I https://example.com

Fake-IPを使用している場合、198.18.0.0/16の範囲内のアドレスが返るのは想定どおりのマッピング結果である可能性があり、直ちにDNSエラーとは限りません。ドメインがフィルターリストに含まれている場合は、実際のIPアドレスが返ることもあります。マッピングアドレスにpingが通るかどうかだけで、Webサイトにアクセスできるかを判断しないでください。

パブリックIPやDNSの確認サイトで分かるのは、そのサイトが観測したリクエストだけです。出口IPが想定どおりでも、すべてのアプリ、DNS、IPv6通信が取り込まれている証明にはなりません。アプリの接続記録、ルールの適用結果、システムのルートをあわせて確認してください。

TUN有効化後にネットへ接続できない場合の切り分け手順

手順1：TUNをオフにして、基本のネットワーク接続を確認

TUNをオフにしても接続できない場合は、Wi-Fi、ゲートウェイ、サブスクリプション、ノードの問題を先に解決してください。オフにするとすぐに復旧する場合は、現在の設定をバックアップし、TUNの起動ログにある権限、インターフェース、ルート、DNSのエラーを中心に確認します。一時的にログレベルをlog-level: debugにして一度だけ問題を再現し、確認後は通常のレベルに戻してください。接続情報を過剰に記録しないよう、debugを常用しないでください。

手順2：NICの作成とルートの出口を確認

ログにpermission deniedやoperation not permittedなどが表示された場合は、サービスの権限を確認してください。複数のNICがある環境では、自動検出された外向きインターフェースも確認します。実際にインターネットへ接続できるNICを指している必要があり、別のVPNや現在の仮想NICを指していてはいけません。自動検出の誤りを確認できた場合に限り、現在のコアがサポートする方法で出口インターフェースを指定してください。

手順3：DNSの問題と接続の問題を切り分ける

内蔵DNSのクエリがタイムアウトする場合は、dns.enable、1053番ポートの競合、上流DNSへの接続、設定の適用状況を確認してください。クエリに成功してサイトへ接続できない場合は、プロキシノード、ルール、TLS接続のログを確認します。「IPアドレスでは開けるが、ドメイン名では開けない」という比較は手がかりにはなりますが、それだけでは判断できません。多くのサイトでは正しいHostとTLS SNIが必要で、IPアドレスへ直接接続すると正常に失敗することもあります。

手順4：VPN、IPv6、特殊なルートとの競合を確認

ほかのVPNを終了してから、もう一度テストしてください。IPv6接続だけで問題が起きる場合は、IPv6で返されるDNS情報、システムルート、ノードの出口がIPv6に対応しているかを確認します。切り分けのためにIPv6を一時的に制限することはできますが、説明なしに恒久的な対処として使わず、診断目的であることを記録してください。社内ネットワークやLAN上のデバイスに接続できない場合は、該当するサブネットが取り込み対象になっているか、既存のルールでDIRECTが選ばれているかを確認します。

手順5：最後にstackとMTUを調整

接続は確立するものの、大きなファイルの転送が止まる、一部のWebページが読み込み中のままになる、特定のUDPアプリに問題が起きる場合は、stackを1種類ずつ変えてテストします。パスMTUが原因と思われる場合は、元の設定を残したうえでtun.mtu: 1400を試し、改善するか記録してください。1400は切り分けの出発点であり、すべてのネットワークに最適な値ではありません。DNS、MTU、ルール、ノードを同時に変更すると、何が改善につながったのか分からなくなります。

接続の復旧と普段の利用：確認できる切り戻し手段を用意する

切り戻すときは、まずTUNをオフにし、コアの終了または再読み込みが完了したことを確認してから、必要に応じてシステムプロキシを有効にします。通常は終了時に自動作成されたルートも削除されます。クライアントが異常終了してネットワークが復旧しない場合は、まず該当するサービスまたはクライアントを再起動し、残ったインターフェースとルートを確認してください。ルーティングテーブルの扱いに慣れていない場合、システムルートをまとめて削除しないでください。

ブラウザーだけでプロキシを使う：通常はシステムプロキシで十分です。設定範囲が狭く、問題の切り分けも簡単です。
ターミナルやデスクトップアプリの通信も取り込む：TUNが適しています。権限、DNS、ルールの3点が正常に動作することを確認してください。
ゲームやボイスチャットを使う：TUNだけでなく、ノードのUDP対応、出口ネットワーク、実際のアプリの接続も確認してください。
企業向けVPNをよく使う：起動順、外向きインターフェース、LANへのアクセスを個別にテストしてください。一度接続できただけで、常に併用できるとは限りません。

設定完了後は、クライアント名、コア情報、OSのバージョン、有効にした設定項目、再現手順を記録しておきましょう。クライアントの変更やサブスクリプションの更新後には、上書き設定が実行中の設定に反映されているか再確認してください。プロキシの接続方法やよく使う設定項目は使い方ガイドを、ポートや設定ファイルの構成は応用マニュアルのポート解説を参照してください。