ClashのTUNモード設定方法｜仮想NICで全通信を取り込む仕組みと設定 | Clash ダウンロードセンター

TUNが通信を取り込む仕組み

ClashのTUNモードは、仮想ネットワークインターフェースでIPパケットを受け取り、コアが接続を識別してルールに照らし、送信先を選択します。システムプロキシの設定を参照しないコマンドラインツールやゲーム、独自にネットワーク接続を行うデスクトップアプリなどに有効です。有効にする前に、クライアントのコアがTUNに対応しているか確認してください。同じ名称のクライアントでも、配布パッケージによってコアや権限の設定は異なる場合があります。

この記事の設定例は、Clash Metaの後継として開発が続くmihomoを基準にしています。オリジナル版Clashや旧Premiumコア、その他の派生版では利用できる項目が異なる場合があります。まずクライアントのコア情報や起動ログで実際に使われているコアを確認し、対応するドキュメントに沿って設定を確認してください。画面に「TUN」スイッチがあるだけで、すべての設定項目が有効になるとは限りません。

アプリが接続を開始：OSが接続先アドレスに応じてルーティングテーブルを参照します。
ルートが仮想インターフェースへ：取り込み対象のパケットは物理NICから直接送信されず、TUNに入ります。
コアが通信を振り分け：ドメイン、IPアドレス、プロセスなどのルールに基づき、プロキシ・直接接続・拒否を選択します。
出口へ接続：プロキシへの接続は実際のネットワークインターフェースを経由します。コア自身の外向き通信が再びTUNに戻らないようにする必要があります。

TUNとシステムプロキシの違い

システムプロキシは通常、HTTPまたはSOCKSの接続先を、設定に対応したアプリに通知します。ローカルの127.0.0.1:7890を例にすると、この入口を明示的に使う接続だけがコアに渡されます。一方、TUNはネットワークインターフェースとルーティングを使うため、アプリがプロキシのポートを認識する必要はありません。

比較項目	システムプロキシ	TUNモード
接続方法	アプリがローカルプロキシの待ち受けポートに接続	システムのルーティングでパケットを仮想インターフェースへ転送
アプリ側の対応	システムプロキシへの対応、または手動設定が必要	通常、プロキシ設定を参照しないアプリも対象にできる
UDP通信	一般的なHTTPシステムプロキシでは直接扱えない	取り込み可能。ただし出口のプロトコルとノードもUDPに対応している必要がある
必要な権限	通常、ネットワークインターフェース作成の権限は不要	インターフェース作成とルート変更の権限が必要
よくある競合	アプリ独自のプロキシ設定、プロキシ環境変数	他のVPN、仮想NIC、経路の重複、DNSの取り込み

「全通信」は仕組みを理解しやすくするための表現であり、すべての通信を必ず取り込めるという保証ではありません。既存の接続、取り込まれないIPv6経路、他のVPNの優先ルート、プラットフォーム固有の制限などにより、実際の対象範囲は変わります。まず対象にするアプリを決め、接続ログで確認してください。スイッチの表示だけで判断しないようにしましょう。

最初の切り分けでは、システムプロキシを無効にしてTUNだけを有効にすると、確認する要素を減らせます。両方を併用することもできますが、同時に有効にした状態でブラウザーに接続できても、TUNが正常とは限りません。ブラウザーがシステムプロキシのポートを経由している可能性があるためです。

有効化前に確認する3項目

まずプロキシの出口が使えるか確認

システムプロキシを使って通常どおりアクセスできるか確認し、サブスクリプションが読み込まれていること、プロキシグループに利用可能なノードがあること、ルールで存在しないポリシー名を参照していないことを確認します。ノードへの接続失敗、サブスクリプションの空欄、認証エラーは、TUNを有効にしても解消しません。トラブル対処では元の設定をバックアップし、一度に変更する項目を1種類に絞ってください。

サービス権限とネットワーク環境を確認

Windows：クライアントが提供するサービスモードの利用をおすすめします。管理者権限でサービスをインストールした後は、サービス経由でコアを実行できます。普段使うすべてのアプリを管理者として起動する必要はありません。
macOS：クライアントによっては、補助プログラムを通じてネットワーク管理権限を取得します。システムの案内に従って許可し、セキュリティソフトがインターフェースの作成を妨げていないか確認してください。
Linux：TUNデバイスの作成やルートの変更には、通常root権限または適切なネットワーク管理権限が必要です。コンテナでは/dev/net/tunへのアクセスも必要です。プロセスの権限を上げるだけでは不十分な場合があります。

他のトンネルを一時停止

他のVPN、ゲーム向け通信最適化ツール、同種のプロキシクライアントをいったん切断してください。企業VPNや仮想マシンのネットワークは必ずしも停止する必要はありませんが、最初の動作確認では環境をできるだけ単純にするのがおすすめです。併用が必要な場合は、複数のクライアントにデフォルトルートを奪い合わせるのではなく、ルートのプレフィックスと優先度を確認してください。

mihomoのTUN設定例

以下は既存の設定に追加するための抜粋で、ノードを含む完全なサブスクリプションではありません。既存のproxies、proxy-groups、rulesは残してください。元のファイルにtunまたはdnsがすでにある場合は、その設定を編集し、同じ階層に同名のキーを重複して追加しないでください。

mixed-port: 7890
mode: rule
log-level: info

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:
    - 1.1.1.1

stack：パケット処理方式を選ぶ

mihomoでよく使われる値はsystem、gvisor、mixedです。systemはシステムのネットワークスタックに関連する実装を使い、gvisorはユーザー空間のネットワークスタックを使います。mixedでは通常、TCPにsystem、UDPにgVisorを使います。対応状況はプラットフォームやコアのビルドによって異なります。

初回設定ではクライアントの既定値から始め、例ではmixedを使用しています。特定の接続障害を再現できた場合に限りスタックを切り替え、コアを再起動して再テストしてください。各スタックは性能の順位を示すものではなく、すべての端末で特定の方式が速いとは限りません。

auto-routeと出口インターフェース

auto-route: trueを設定すると、コアが通信の取り込みに必要なルートを自動で作成しますが、管理者権限の代わりにはなりません。auto-detect-interface: trueは外向き通信に使うインターフェースを自動判別し、プロキシの外向き通信が自分自身のトンネルに戻るのを防ぐために使います。Wi-Fi、有線LAN、VPNを同時に使用する場合は、判別結果も確認してください。

スリープからの復帰後やWi-Fiの切り替え後に通信できなくなった場合は、まずコアを再起動して出口を再判別させ、ルートを確認してください。すぐに物理NICのアドレスを設定に固定するのは避けましょう。ネットワークを切り替えると、固定したインターフェース名が使えなくなる場合があります。

dns-hijackとDNSの待ち受けポート

any:53はTUNに入る通常のUDP DNSリクエストを取り込む設定で、tcp://any:53は対応するTCP DNSリクエストを対象にします。どちらも一致したリクエストをコアのDNSモジュールに渡します。システムのDNSサーバーアドレスを127.0.0.1:1053に設定する必要はありません。

listen: 127.0.0.1:1053は、DNSモジュールが追加で提供するローカルの待ち受け先です。mixed-port: 7890とは用途が異なり、7890をDNSポートとして使うことはできません。アプリ内蔵のDoHやDoTは通常の53番ポートを使うDNSではないため、この2つの取り込みルールだけでは直接捕捉できません。

Windows・macOS・Linuxでの有効化手順

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

クライアントの設定で、TUNに対応したmihomoコアが使われていることを確認し、サブスクリプションの接続テストを行います。
サービスモードまたはサービス管理の項目を開き、案内に従ってサービスをインストールして起動します。メニュー名はクライアントによって異なるため、実際の画面表示を確認してください。
TUNを有効にし、権限、インターフェースの作成、ルートの追加に関するエラーがログに出ていないか確認します。
「設定」→「ネットワークとインターネット」→「プロキシ」を開き、ブラウザーがシステムプロキシを経由する影響を除くため、手動プロキシを一時的に無効にします。
PowerShellでネットワークインターフェースとIPv4ルートを確認してから、新しい接続を試します。

Get-NetAdapter -IncludeHidden
Get-NetRoute -AddressFamily IPv4 |
  Sort-Object DestinationPrefix, RouteMetric
curl.exe --noproxy "*" -I https://example.com/

--noproxy "*"を指定すると、このcurlリクエストでは明示的なプロキシを使いませんが、TUN経由のルーティングは回避されません。例のアドレスは接続確認用です。アクセスできたら、クライアントの接続一覧で該当リクエストのルールと出口も確認してください。トンネルインターフェースがネットワークアダプター一覧に完全な形で表示されない場合もあるため、ルートとログをあわせて判断します。

macOS：権限を許可してルートを確認

クライアントの設定画面から必要な補助プログラムをインストールまたは有効にし、システム権限の確認を完了します。
他のVPNを切断してからTUNを有効にします。「システム設定」→「ネットワーク」を開き、同時に有効になっているネットワークトンネルがないか確認してください。
システムプロキシの影響を除外するには、現在のネットワークサービスの「詳細」→「プロキシ」で、HTTP・HTTPS・SOCKSの設定を確認します。
ターミナルでインターフェースとルートを確認し、クライアントの接続ログと照らし合わせてテストします。

ifconfig
netstat -rn -f inet
route -n get 1.1.1.1
curl --noproxy '*' -I https://example.com/

macOSでは仮想インターフェース名にutunがよく使われますが、他のシステムサービスも同種のインターフェースを作成します。utunが1つ見つかっただけでは、現在のクライアントのものとは判断できません。有効化前後の変化と、テスト対象が実際に使っているルートを比較してください。

Linux：デバイス・権限・ポリシールーティングを確認

GUIクライアントには通常、権限昇格やサービスのインストール手順が用意されています。コアを直接起動する場合は、まず設定の構文を確認し、設定済みのシステムサービスから起動してください。手早く試すために、一般ユーザーのアプリやホームディレクトリ全体へ過剰な権限を与えるのは避けましょう。

mihomo -t -f config.yaml
test -c /dev/net/tun && echo "TUN device available"
ip link show
ip rule show
ip route show table all
curl --noproxy '*' -I https://example.com/

mihomo -tで確認できるのは主に設定を解析できるかどうかであり、実行時にルート設定の権限を得られることまでは証明できません。Linuxではポリシールーティングテーブルが使われる場合もあります。メインのルーティングテーブルだけでは取り込み用のルールを見落とすことがあるため、ip ruleとすべてのルーティングテーブルをあわせて確認してください。

通信の取り込み・DNS・UDPを検証

適切な動作確認には段階的な検証が必要です。Webページを開けても、ある経路でアクセスできることしか分かりません。DNS、UDP、IPv6、すべてのアプリが想定どおり動作している証拠にはなりません。次の順番で確認しましょう。

インターフェース：有効化の前後で仮想インターフェースとルートを比較し、継続的なエラーがないことを確認します。すべてのプラットフォームでインターフェース名やデフォルトルートが同じになるとは限りません。
接続：システムプロキシを無効にし、--noproxyを付けたcurlで新しい接続を作成して、クライアントの接続一覧に該当リクエストが記録されているか確認します。
ルール：一致したルールとプロキシグループを確認します。DIRECTに一致した場合は通信の振り分け結果であり、TUNが自動的に無効になったわけではありません。
DNS：DNSログを確認し、通常の53番ポートへのリクエスト、アプリ独自の暗号化DNS、キャッシュが使われたリクエストを区別します。
UDP：実際にUDP通信を行うアプリでテストし、選択したノードとプロトコルがUDP転送に対応していることを確認します。TCPのテストが成功しても、UDPの動作確認にはなりません。

Fake-IPを使用している場合、取り込まれたドメインの一部で198.18.0.0/16の範囲にあるマッピング用アドレスが返されることがあります。これは設定上の想定された動作であり、Webサイトの実際のグローバルIPアドレスではありません。フィルタリング対象のドメイン、独自の暗号化DNSを使うアプリ、キャッシュが使われたリクエストでは挙動が異なる場合があります。

TUN有効化後に通信できない場合の切り分け手順

症状	優先して確認する項目	対処方法
有効化直後にスイッチが戻る	サービスの状態、インターフェース作成権限、設定解析ログ	まず権限または構文のエラーを修正し、コアを再起動する
ドメインにアクセスできない	DNS上流への到達性、DNSモジュール、取り込みログ	53番ポートのリクエストがコアに入っているか確認し、到達可能な上流DNSに変更する
ブラウザーは使えるが、他のアプリは失敗する	ブラウザーがシステムプロキシを使い続けていないか	システムプロキシを無効にして再テストし、対象アプリの接続記録を確認する
Webページは開くが、ゲームに接続できない	UDPの出口対応状況、プロキシグループ、アプリのエラーコード	UDP対応を確認したノードに切り替え、項目ごとに原因を特定する
接続が何度もタイムアウトする	他のVPNのルート、出口インターフェース、プロキシのループ	競合するトンネルを停止し、出口を再判別してコアを再起動する
スリープ復帰後やネットワーク切り替え後に使えなくなる	古いインターフェースやルートが引き続き使われていないか	コアを再起動し、復旧前後のルートとログを比較する

LAN内のプリンター、NAS、ルーターの管理画面に接続できなくなった場合は、まず接続先のプライベートIPアドレスに一致したルールを確認してください。プロキシ経由になっている場合は、実際のネットワーク範囲に合わせて直接接続のルールを追加します。すでに直接接続になっている場合は、LAN内のルートとファイアウォールを確認してください。LANの問題をすぐにFake-IPのせいにしないようにしましょう。

ルールの変更で解決できるのは出口の選択に関する問題だけです。パケットがコアに入っていない場合、ドメインルールを追加しても効果はありません。プロキシノード自体に接続できない場合、stackを何度切り替えても解決しません。次の変更に進む前に、「対象アプリ、接続先、一致したルール、エラーログ、他のVPNの使用状況」の5項目を記録してください。

サブスクリプション更新時と終了時の復元

TUNのスイッチ状態をローカル設定として保存するクライアントもあれば、画面上の設定を実行用設定に反映するクライアントもあります。サブスクリプションのファイルを編集すると、リモート更新によって変更が上書きされる場合があります。クライアントが対応する上書き、マージ、永続化の機能を使い、更新後はエディターに保存した抜粋だけでなく、実際に適用された設定を確認してください。

使用を終了するときは、まずTUNを無効にしてからクライアントを通常の手順で終了し、コアに自動作成したルートを削除させてください。プロセスの異常終了後も通信が不安定な場合は、クライアントを再起動してからTUNを無効にし、ルートを整理します。システムプロキシの設定が残っていないかも確認してください。出所が分からないまま、システムルートをまとめて削除するのは避けましょう。

ブラウザーだけをプロキシ経由にする場合：システムプロキシのほうが設定もトラブル対処も簡単です。
プロキシに対応していないアプリも対象にする場合：TUNを有効にし、ルートと接続記録を確認します。
複数のVPNを併用する場合：それぞれが取り込むアドレス範囲を整理してから、ルールとルーティングを設計します。
さらにトラブル対処を進める場合はトラブル対処をご覧ください。基本的なインポート方法とモード設定はClash設定ガイドで解説しています。