Clash TUNモードの使い方：全通信を取り込む仕組みと各プラットフォームの設定

TUNモードで通信を取り込む仕組み

通常のシステムプロキシモードは、OSがアプリに公開するHTTPまたはSOCKSプロキシのアドレスに依存します。ブラウザーや一部のダウンロードツール、システムのネットワーク設定に従うソフトウェアは接続をClashへ渡しますが、ゲームクライアント、コマンドラインプログラム、独立したアップデーター、独自のネットワークスタックを実装したアプリは宛先へ直接アクセスすることがあります。そのため、クライアント画面で「システムプロキシが有効」と表示されていても、これらの接続がプロキシポートを迂回する場合があります。

TUNモードでは仮想ネットワークインターフェースを作成し、ルーティングルールによって指定した通信をそのインターフェースへ送ります。Clashのコアは仮想インターフェースからIPパケットを読み取り、接続先を復元したうえで、設定ファイルのプロキシルールに従ってDIRECT、REJECT、または指定したプロキシポリシーを選択します。応答データも同じ経路でアプリへ返されるため、アプリ側でローカルプロキシポートやHTTP・SOCKSの個別対応を意識する必要は通常ありません。

ここでいう「全通信の取り込み」は、通信がClashへ入る範囲を指しており、プロキシモードのGLOBALと同じ意味ではありません。TUNを有効にしてもRuleモードは利用できます。LANアドレスは直接接続、特定ドメインはプロキシ、広告ドメインは拒否、それ以外はフォールバックルールで処理するといった構成が可能です。処理可能な接続をすべて選択中のプロキシポリシーへ統一するには、動作モードをGlobalへ切り替えます。

TUNが主に処理するのは第3層のIP通信です。ドメイン名によるマッチングには、DNSの解決結果とコアのドメインマッピング機構も関係します。UDP、QUIC、IPv6を完全に利用できるかどうかは、使用するコア、ノードのプロトコル、システム権限、設定内容に左右されます。最新のmihomoコアは通常、充実したTUN機能を備えていますが、設定項目の見せ方はデスクトップクライアントごとに異なります。

TUNを有効にする前の確認項目

まず、現在のサブスクリプションが正常に利用できることを確認します。利用可能なノードを選び、システムプロキシだけを有効にした状態でウェブページへアクセスし、ルール一覧が想定したポリシーにマッチするか確認してください。サブスクリプションの解析失敗、ノードへの到達不能、ルール設定の誤りがある場合、TUNを有効にすると問題の範囲が広がるだけで、基本的な接続障害は解決しません。

クライアントのコアを確認：クライアントのコア情報またはバージョン情報を確認します。比較的新しいmihomoコアはTUN、自動ルート、DNSハイジャックなどのパラメータに対応していますが、古いClashコアや機能を絞ったクライアントでは一部の項目が利用できない場合があります。
現在の設定を保存：使用中の設定ファイルをエクスポートするか、サブスクリプション名、プロキシモード、DNS設定を記録しておきます。YAMLを編集するときはスペースによるインデントを統一し、タブで代用しないでください。
権限の取得方法を確認：Windowsではサービスモードまたは管理者権限で仮想ネットワークインターフェースを操作することが多く、macOSでは管理者の許可が必要になる場合があります。Linuxでは通常、root権限またはプロセスへのネットワーク管理権限の付与が必要です。
他のVPNを終了：同じシステムで複数の仮想ネットワークインターフェースツールを同時に動かすと、デフォルトルート、DNS、ファイアウォールルールが競合しやすくなります。モバイルプラットフォームでは通常、同時に有効化できるシステムVPNトンネルは1つだけです。
LAN環境を記録：プリンター、NAS、開発用デバイス、社内ネットワークへアクセスする必要がある場合は、利用しているアドレス範囲を記録し、TUN有効化後にこれらの直接接続を重点的に確認します。

mihomo TUN設定パラメータ

多くのGUIクライアントにはTUNスイッチが用意され、基本パラメータも自動生成されます。YAMLを手動で管理する場合は、まず小さな構成から始め、システムの状況に応じて厳格なルーティングやMTUなどの項目を追加します。以下は一般的な構造の例です。実際に利用できるフィールドは、クライアントに組み込まれたコアのバージョンを確認してください。

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

enable と stack

enable はTUN機能を起動するかどうかを制御します。stack はコアがネットワークデータを処理する方式を指定し、mihomoでは system、gvisor、mixed が一般的な値です。システムスタックは直接的な性能を得やすく、gVisorのユーザー空間ネットワークスタックは環境によって互換性に優れ、mixedはTCPとUDPを組み合わせて処理します。クライアントが推奨値を提示している場合は、まずデフォルト設定を維持してください。特定のアプリだけ接続できない、またはUDPに異常がある場合に、項目を1つずつ切り替えて検証します。

auto-route と auto-detect-interface

auto-route は必要なルートをコアが自動追加し、システム通信を仮想インターフェースへ向けます。auto-detect-interface は実際の出口インターフェースを識別し、プロキシサーバーへの接続が再びTUNへ入るループを防ぎます。有線、無線、モバイルホットスポットを切り替えた後にすべての接続が突然切れた場合は、まずTUNを再起動してコアに出口インターフェースを再判定させてください。

dns-hijack と DNS設定

dns-hijack の any:53 は、従来の53番ポートへのDNSクエリを取り込み、ドメイン解決をClashのルールと一致させやすくします。ただし、暗号化DNSが異なるポートとプロトコルを使うため、アプリ内蔵のDoHやDoTを直接インターセプトすることはできません。DNSハイジャックだけを設定してコアのDNSモジュールを有効にしていない場合も、クエリに失敗することがあります。設定内の dns.enable と、nameserver、fallback、ポリシーによる解決項目が有効かどうかを併せて確認してください。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

fake-ip モードでは、ドメインに対して予約済みアドレス範囲のマッピングアドレスを返します。コアはその情報を使ってドメイン名を保持し、ルールにマッチさせます。一部のLAN機器、ゲームのログインサービス、実際のDNS応答値に依存するプログラムはfake-ipに対応できない場合があります。該当ドメインをフィルターリストへ追加するか、クライアントの機能に応じて別の拡張モードを使用してください。fake-ipのアドレス範囲を不用意に変更し、LANのルーティングと同じセグメントにすると、アドレスが競合するため注意が必要です。

strict-route と MTU

strict-route はルーティング制約を強化し、一部のシステムでは通信の迂回を減らせますが、社内VPN、仮想マシンのインターフェース、特殊なルートとの競合も表面化しやすくなります。まずはクライアントのデフォルト値を使い、基本接続が安定してから有効化するのがおすすめです。MTUは1つのパケットサイズを制御します。ウェブページは開くのにアップロードだけ止まる、一部サイトが継続的にタイムアウトする、ゲームがログイン後に切断されるといった場合は、1400〜1500の範囲で値を試してください。毎回変更するのは1項目だけにし、再接続して確認します。

Windows、macOS、Linux、モバイルプラットフォームの設定

Windows：サービスモードと仮想ネットワークインターフェース

WindowsのGUIクライアントでは、通常TUNが設定ページ、サービスモードのページ、またはメイン画面のネットワークスイッチに配置されています。まずクライアントが提供するサービスコンポーネントをインストールし、管理者権限でインストールを確認します。サービスモードを使うと、バックグラウンドサービスが仮想ネットワークインターフェースの作成とルート変更を担当するため、日常的にクライアントを起動するたびに画面全体のプロセスを昇格させる必要がありません。

実行中の他のVPN、ゲーム用通信高速化ツール、ネットワークを制御する可能性のあるセキュリティツールを終了します。
クライアント設定でService Mode、サービスモード、またはシステムサービスをインストールまたは有効化します。
Ruleモードを選択し、サブスクリプションのノードが利用可能であることを確認してから、TUN Modeを有効にします。
システムの権限確認を許可し、仮想ネットワークインターフェースの作成が完了するまで待ちます。
ウェブページ、コマンドラインツール、対象アプリ、LANリソースの順にテストします。

スイッチがすぐに元へ戻る場合は、サービスが実行中かどうかを確認し、クライアントログにインターフェース作成、ルート書き込み、ドライバーへのアクセス失敗がないか確認します。WindowsのHyper-V、WSL、仮想マシンソフトウェアは仮想スイッチやネットワークインターフェースを追加しますが、これらが存在するからといって必ず競合するとは限りません。すべての仮想アダプターを削除するのではなく、ルーティングテーブルと実際の出口を基に判断してください。

macOS：許可設定とutunインターフェース

macOSのクライアントは通常、システムネットワーク拡張または権限を持つ補助プロセスを通じてTUNを構築します。初回の有効化時には、管理者パスワード、VPN構成、ネットワーク拡張の許可を求められることがあります。許可が完了すると、システムのネットワーク設定で対応するVPNの状態を確認できます。ターミナルで ifconfig を実行すると、新しい utun インターフェースが表示される場合もあります。

TUNは接続済みなのに通信がない場合は、まずシステムで別のVPNが有効になっていないか確認し、プロキシサーバー自身への接続が仮想インターフェースへ再送されていないかを確認します。企業ネットワークの構成プロファイルを使用しているMacでは、管理者ポリシーによる制限を受けることがあります。このような制限はシステム管理の範囲で対処する必要があり、クライアントを何度も再インストールしてもポリシーの結果は通常変わりません。

Linux：権限、ルート、フォワーディング

Linuxでは /dev/net/tun が提供され、プロセスによるインターフェース作成とルート変更が許可されている必要があります。rootでの実行は短期的な検証には使えますが、長期運用ではsystemdサービス、コンテナ権限、capabilitiesを通じて必要な権限だけを明示的に付与する方法が適しています。最小構成のシステム、コンテナ、制限付きサーバーでは、カーネルがTUNデバイスを有効にしているかも確認してください。

ls -l /dev/net/tun
ip addr show
ip route show
ip rule show

これらのコマンドで、デバイスノード、仮想インターフェース、デフォルトルート、ポリシールートを確認できます。Linuxではnftablesとiptablesのルールが併存している、Dockerブリッジのアドレス範囲が重複している、サーバーに既存のポリシールートがある、ファイアウォールがTUNインターフェースの通信を許可していない、といった問題もよくあります。トラブルシューティングでは既存のネットワークルールを先に保存し、リモートサーバー上でファイアウォールやデフォルトルートをいきなり全消去しないでください。管理用の接続を失うおそれがあります。

AndroidとiOS：システムVPNトンネル

モバイルクライアントは通常、AndroidのVPNServiceまたはAppleのNetwork Extensionを利用してローカルVPNトンネルを構築します。画面上の名称は「VPN」「拡張モード」「TUN」など、クライアントによって異なる場合があります。初回接続時にはシステムVPNの許可が必要です。Androidではクライアントの機能に応じてアプリごとのプロキシ設定や除外を指定できます。iOSとiPadOSで利用できる具体的な項目は、クライアントの実装とシステム権限によって異なります。

モバイルOSでは通常、アクティブにできる通常のVPN構成は1つだけです。そのため、Clash系クライアントと会社のVPN、他のプロキシツールが同時にトンネルを占有することはできません。省電力設定によってバックグラウンドのクライアントが停止し、画面ロック後しばらくして接続が切れることもあります。クライアントのバックグラウンド実行を許可し、DNSを重複して変更するネットワークツールを同時に有効化しないでください。

TUNが通信を取り込めているか確認する方法

スイッチの状態だけでは、通信経路が正常かどうかを判断できません。信頼できる確認には、仮想インターフェース、クライアントログ、ルールのマッチ結果、実際のアプリ接続を併せて確認する必要があります。次の順に操作するのがおすすめです。

システムに新しいTUN、utun、またはクライアントの仮想インターフェースが表示され、インターフェースが有効になっていることを確認します。
クライアントの接続一覧を開き、もともとシステムプロキシに従わないプログラムからリクエストを送り、対象アドレスやプロセスの記録が表示されるか確認します。
ルールのマッチ結果を確認します。LANアドレスはLANまたはプライベートアドレスのルールに従って直接接続され、対象サイトは想定したプロキシグループへ入るはずです。
システムプロキシを一時的に無効にし、TUNだけを有効にした状態でブラウザーとコマンドラインの接続をテストします。それでも接続がクライアントに記録されるなら、通信がシステムプロキシだけを経由してコアへ入っているわけではありません。
TCP、UDP、IPv4、IPv6、DNSを個別にテストします。すべてのノードが同じUDPやIPv6機能に対応しているとは限らないため、ノード側の制限とTUNの障害を切り分けてください。

Windowsでは route print またはPowerShellの Get-NetAdapter でインターフェースを確認できます。macOSでは route -n get default と ifconfig、Linuxでは ip route と ip rule を使用できます。診断時は有効化前後の差分を比較し、デフォルトルートが1行見えただけで設定が正しいと判断しないでください。

よくある競合と段階的な切り分け

有効化するとすべてのアプリがインターネットに接続できない

まずTUNを無効にし、システムのネットワークが復旧することを確認してから、プロキシノード自体を確認します。続いてログにインターフェース作成失敗、デフォルトインターフェースの識別エラー、ルーティングループ、DNSタイムアウトがないか確認します。有線と無線に同時接続している場合は、一時的に実際の出口を1つだけ残してTUNを再有効化してください。インターフェースの手動指定は自動検出に失敗した場合の対処とし、ネットワークインターフェース名が変わったら設定も更新します。

ウェブページは開くが、ゲームや音声通話に接続できない

この場合は通常、UDPを確認します。選択したノードとプロトコルがUDPに対応していること、プロキシグループでTCP向けの経路だけを選んでいないこと、クライアントに該当するUDPセッションが記録されていることを確認してください。アプリがQUICを使っている場合は、一時的にアプリ内のQUICを無効にして比較できます。ただし最終的には、ノードの機能、ルールのマッチ結果、TUNスタックの互換性から原因を特定します。

有効化するとNAS、プリンター、ルーターにアクセスできない

プライベートアドレス範囲が誤ってプロキシへ送られていないか確認します。一般的なLANセグメントには 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 がありますが、企業内ネットワークでは別のアドレスが使われることもあります。LANルートを直接接続できる設定になっていること、fake-ipのアドレス範囲が実ネットワークと重複していないことを確認してください。ドメイン名では接続できずIPアドレスなら接続できる場合は、ローカルDNS解決とfake-ipフィルターを重点的に確認します。

スリープやWi-Fi切り替え後に接続できなくなる

ネットワーク復旧後は、実際の出口インターフェースとデフォルトルートが変わっているのに、TUNが古い状態を保持していることがあります。まずTUNを停止し、システムが新しいIPアドレスとDNSを取得するまで待ってから再有効化してください。頻繁に起きる場合は、クライアントが対応する安定したコアバージョンへ更新し、自動インターフェース検出が有効か確認します。モバイル端末ではバックグラウンド実行と省電力制限も確認が必要です。

Docker、仮想マシン、会社のVPNと競合する

まず各仮想ネットワークインターフェースが使用するアドレス範囲とルートの優先度を比較します。Dockerブリッジ、仮想マシンのNAT、会社のVPN、TUNが同じセグメントを宣言していると、システムが通信を誤ったインターフェースへ送ることがあります。対処方法には、ローカルの仮想ネットワーク範囲を変更する、社内ネットワークへ明示的な直接接続ルートを追加する、使用していないネットワークコンポーネントを無効にする、同時実行できない場合は用途に応じて切り替える、といった方法があります。DNS、ルート、MTU、ファイアウォールを一度に広範囲変更すると、どの調整が有効だったか判断しにくくなるため避けてください。

TUNモードに関するよくある質問

TUNを有効にした後もシステムプロキシを有効にする必要がありますか？

通常はシステムプロキシに同時依存する必要はありません。TUNが仮想インターフェースを通じて、ルーティング条件に合う通信を取り込むためです。一部のクライアントでは特定のアプリとの互換性のため両方を有効にしますが、TUNが動作しているか判断する必須条件ではありません。トラブルシューティングでは、システムプロキシを無効にしてTUNだけを残し、接続一覧を確認できます。

TUNモードではすべての通信がプロキシノードを経由しますか？

ルールモードが自動的に変わることはありません。TUNは通信がClashへ入る方法を決め、Rule、Global、Directは入った後の処理方法を決めます。Ruleモードでは、接続は設定ファイルを上から順に照合され、直接接続、拒否、プロキシポリシーへ個別に振り分けられます。

有効化後、クライアントにTUNデバイスの作成失敗と表示されるのはなぜですか？

よくある原因は、システム権限の不足、サービスコンポーネントの未インストール、TUNデバイスの利用不可、既存VPNによるインターフェースの占有、セキュリティポリシーによるネットワーク変更の阻止などです。まずログに記録された具体的なエラーを確認し、サービスの状態とシステムの許可設定を調べてください。スイッチを繰り返しクリックするだけでは解決しません。

system、gvisor、mixedのどれを選べばよいですか？

現在のプラットフォーム向けにクライアントが推奨するデフォルト値を優先してください。基本ネットワークは正常なのに特定のTCP・UDPアプリで問題がある場合は、別のスタックへ切り替えて比較します。コアのバージョンとOSによって結果が異なるため、すべての端末に共通する固定の正解はありません。

TUNモードでアプリ内蔵の暗号化DNSを取り込めますか？

従来の53番ポートのDNSはdns-hijackで取り込めますが、アプリ内蔵のDoHやDoTは暗号化接続を使うため、any:53だけで直接インターセプトすることはできません。アプリ側で独自のセキュアDNSを無効にするか、ドメインルール、ポリシー、システムレベルの管理機能を使って対処します。

安定して有効化するための手順

まずシステムプロキシ環境でサブスクリプション、ノード、Ruleモードが正常に動作することを確認し、必要なサービスをインストールしてからTUNを有効にします。初回テストでは自動ルート、自動インターフェース検出、基本DNS設定だけを使い、ブラウザー、コマンドライン、UDPアプリ、LANリソースがすべてルールどおり接続できるか確認します。その後、実際の問題に応じてstack、strict-route、MTU、fake-ipのフィルター項目を調整してください。

TUNの最大の利点は、通常ならプロキシを自発的に使わないアプリの接続も、統一したルールで処理できることです。安定性はルーティング、DNS、権限、プロキシノードが連携して決まります。トラブルシューティングでは、「仮想インターフェースが作成されたか」「通信がコアへ入ったか」「ルールにマッチしたか」「ノードが転送できるか」の4層に分けて確認してください。すべての項目を何度も切り替えるより、層ごとに確認するほうが問題箇所を見つけやすくなります。