TUNモードとシステムプロキシ：通信を取り込む仕組みの違い

ClashのシステムプロキシとTUNモードは、どちらもアプリの通信をカーネルに渡すための仕組みです。システムプロキシは、ローカルのHTTPまたはSOCKSプロキシのアドレスをアプリに設定します。一方、TUNはレイヤー3の仮想ネットワークインターフェースを作成し、OSのルーティングを利用して条件に合うIPパケットをカーネルに送ります。どちらもノードのプロトコルではなく、サブスクリプション内のプロキシサーバーに代わるものでもありません。

通常、ブラウザーはシステムプロキシの設定に従いますが、一部のゲームやコマンドラインツール、独自のネットワークスタックを使うアプリは設定を参照しません。そのため、ブラウザーがプロキシ経由でも、ほかのアプリは直接接続することがあります。TUNならアプリ側でHTTPプロキシに対応する必要はありませんが、適用範囲はルート、除外設定、権限、プロトコルの対応状況に左右されます。

比較項目システムプロキシTUNモード
接続方法アプリがローカルのプロキシポートに接続システムのルーティングがIPパケットを仮想NICに転送
主な接続先例：ローカルの混合ポート7890TUNインターフェースと対応するルート。アプリ側でプロキシポートを指定する必要はありません
UDP通信通常、システムのHTTPプロキシでは処理できない取り込み可能。ただし、接続先ノードがUDPに対応している必要があります
必要な権限通常はユーザーのプロキシ設定を変更するだけデスクトップでは対応するシステム権限、AndroidではVPNの許可が必要
よくある影響設定に従わないアプリはプロキシを迂回するほかのVPN、仮想NIC、ルーティングルールと競合することがある

仮想NICからルーティング、外部接続までの流れ

WebサイトへのTCP接続を例に見てみましょう。アプリが接続先IPアドレスを取得すると、OSはルーティングテーブルを参照します。自動ルーティングが有効で、取り込み条件を満たすパケットはTUNインターフェースに送られます。カーネルは接続先アドレスや利用可能なドメイン情報を読み取り、ルールを順に照合した後、直接接続またはプロキシ経由の接続を確立します。

  1. アプリから送信：アプリは通常どおりネットワーク接続を行い、127.0.0.1:7890を設定する必要はありません。
  2. ルートの選択：カーネルが設定したルートに基づき、どのアドレスを仮想NICに送るかが決まります。物理インターフェース、LAN内のルート、除外ルールも判定に関わります。
  3. プロトコル処理：TUNのプロトコルスタックが受信したIP通信を処理し、ルールと出力先の選択へ渡します。
  4. 出力先の選択：一致したポリシーに応じて、DIRECT、拒否、プロキシグループなどが選ばれます。特定のノードが常に使われるわけではありません。
  5. 応答データ：カーネルは応答をアプリに返します。また、プロキシサーバーへの接続は実際のネットワーク出口から送信し、TUNに再び入り込むループを防ぎます。

つまり、「TUNが有効」と表示されても、通信の入口に関する設定の一部が反映されたことしか分かりません。ノードの停止、プロキシグループの選択ミス、DNSのタイムアウト、出口インターフェースの誤選択などが原因で、アプリがエラーになることがあります。トラブル時は、仮想NICが作成されたか、接続がカーネルに届いているか、最終的にどの出力先が選ばれたかを分けて確認しましょう。スイッチの表示だけで判断しないことが大切です。

DNSハイジャックとfake-ip：ドメイン名によるルール判定

多くのアプリは、ドメイン名をIPアドレスに変換してから接続します。DNSクエリがカーネルを完全に迂回すると、カーネルが接続先IPしか認識できず、ドメイン名ルールを直接照合できない場合があります。DNSを取り込んでカーネルの名前解決モジュールに渡せば、キャッシュによる対応付けなどを通じて、振り分けに必要な情報を保持できます。

ポート53を取り込む際の制限

mihomoのTUN設定では、dns-hijackで宛先ポート53のDNS通信を取り込めます。any:53は通常UDP DNSに、tcp://any:53はTCP DNSに使います。ただし、あらゆる暗号化DNSを汎用的に遮断する設定ではありません。アプリ内蔵のDoHは通常HTTPSの443番ポート、DoTは通常853番ポートを使うため、53番ポートを設定しても自動的にカーネルのDNSクエリへ切り替わるわけではありません。

fake-ipは実際のサーバーアドレスではない

fake-ipモードでは、条件に合うドメイン名に対し、予約済みアドレス範囲内のIPアドレス（例：198.18.0.0/16）を返します。アプリがそのアドレスに接続すると、カーネルが対応表からドメイン名を特定し、ルール判定と実際の通信処理を行います。これはローカルでのアドレス対応付けであり、接続先Webサイトの実アドレスがその範囲に変更されたわけではありません。

mihomoの設定例：カーネルを確認してから項目を統合

以下は、該当する項目に対応したmihomoカーネル向けの設定例です。Clashはクライアントのエコシステムで広く使われる名称ですが、各クライアントに同梱されるカーネルは異なります。また、Clashのビルドによっても対応状況は異なるため、この設定をそのまま適用できるとは限りません。まずクライアントの「バージョン情報」または実行ログでカーネル名を確認し、GUIの設定が該当項目を上書きしないかも確認してください。

この設定例はDNSとTUNのみを示しており、ノード、プロキシグループ、ルールは含まれていません。サブスクリプションとしてそのままインポートできる完全な設定ではありません。既存の設定にある対応するトップレベル項目へ統合し、dns:やtun:が重複しないようにしてください。

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
  nameserver:
    - https://dns.alidns.com/dns-query

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53
項目用途と確認ポイント
listen: 127.0.0.1:1053ローカルDNSの待ち受けアドレスです。1053はプロキシポートではなく、システムが自動的にこのポートを使うという意味でもありません。
stack: mixed対応するmihomoビルドでは、TCPとUDPの処理に異なるネットワークスタックを組み合わせます。互換性に問題がある場合は、使用中のカーネルのドキュメントを確認し、別のスタックも試してください。
auto-routeルートを自動設定して通信を取り込みます。無効にすると通常はルートを手動で管理する必要があるため、最初のトラブルシューティングで安易に無効にするのは避けてください。
auto-detect-interface出力インターフェースを自動検出します。複数のネットワークインターフェースが有効な場合は、実際の出口を確認してください。
default-nameserverDNS上流のドメイン名を名前解決するための設定です。例に記載された上流サーバーへ現在のネットワークから接続できる必要があります。例のアドレスがあらゆるネットワークで使えるとは限りません。

Windows・macOS・Androidでの設定手順

Windows：サービスまたは管理者権限を設定する

  1. まずTUNを無効にした状態で、システムプロキシ経由で目的のサイトにアクセスできるか確認します。この段階で失敗する場合は、先にノードやサブスクリプションの問題を解決してください。
  2. クライアントでサービスモード、サービスのインストール、権限関連の設定を探します。バックグラウンドサービスに対応したクライアントでは、通常、最初に管理者権限での認証が必要です。別の方式ではクライアントの権限昇格が必要な場合もあるため、クライアントの説明に従ってください。
  3. ほかのVPNの自動接続を無効にして、クライアントの「TUNモード」を有効にします。ログにインターフェースの作成、ルートの追加、DNS待ち受けのエラーがないか確認してください。
  4. システムプロキシを一時的に無効にして、通常のアプリと、もともとシステムプロキシに従わないアプリの両方をテストします。システムプロキシが機能していることを、TUNの動作と取り違えないためです。

Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」でシステムプロキシを確認できます。トラブル時はroute printでルートを、PowerShellのGet-NetAdapterでネットワークアダプターを確認できます。仮想NICの名前はクライアントによって異なるため、特定の名前だけで成功を判断しないでください。

macOS：ヘルパーサービスの許可とネットワーク出口を確認

  1. クライアントとカーネルがTUNに対応しているか確認します。案内に従って必要な特権ヘルパーサービスをインストールまたは許可してください。システムプロキシのスイッチをTUNのスイッチと混同しないようにしましょう。
  2. TUNを有効にした後、クライアントのログとシステムルートを確認します。ターミナルでifconfigを実行するとインターフェースを、netstat -rnを実行するとルートを確認できます。
  3. Wi-Fi、有線LAN、スマートフォンのテザリングを切り替えて再テストします。以前の出口が選ばれたままの場合は、まずカーネルを再起動するかTUNを再度有効にしてから、インターフェースの認識状態を確認してください。

システムプロキシは通常、「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」から確認できます。システムにutunインターフェースが表示されても、現在のクライアントが作成したものとは限りません。ほかのネットワークサービスも同種のインターフェースを作成することがあるため、有効化した時刻とログをあわせて判断してください。

Android：VPNの許可が通信を取り込む入口

Androidのクライアントは通常、システムのVpnServiceを使って仮想ネットワークインターフェースを作成します。初回接続時にはシステムのVPN許可画面が表示されます。許可されていないと、必要な通信経路を確立できません。これはクライアントにroot権限を付与することでも、サブスクリプションへの接続が成功したことを意味するものでもありません。

  1. サブスクリプションをインポートして利用可能なポリシーを選び、クライアントの接続ボタンを押して、システムのVPN接続を許可します。
  2. アプリごとの振り分け設定や除外リストを確認し、対象アプリが除外されていないことを確認します。クライアントによっては、「選択したアプリのみプロキシ」と「選択したアプリを除外」を切り替える設定があります。
  3. システム設定で「常時接続VPN」や「VPNなしの接続をブロック」といった項目を確認します。名称はメーカーによって異なりますが、これらの設定によって別のクライアントが接続できない場合があります。
  4. 画面消灯後に切断される場合は、バックグラウンド実行やバッテリー最適化の制限を確認してください。OSがプロセスを停止している問題を、DNSの変更を繰り返してごまかさないようにしましょう。

同じAndroidユーザーまたは仕事用プロファイルでは、通常、有効にできるVPNサービスは1つです。VPNインターフェースを使うファイアウォール、フィルタリングツール、プロキシクライアントは、互いに接続先を切り替えることがあります。デスクトップ版YAMLのTUN項目がAndroidクライアントで有効とは限らないため、まずクライアント側の設定を使ってください。

TUNを有効にするとネットに接続できない：通信経路を順に確認

一度に変更する設定は1つにし、変更前の設定を保存しておきましょう。まず、すべてのアプリで失敗するのか、特定のドメインだけ失敗するのか、UDP通信だけ失敗するのかを切り分けます。それぞれ確認すべき箇所が異なります。

症状優先して確認する項目具体的な対処
スイッチがすぐ戻る、またはインターフェースを作成できない権限、サービスの状態、インターフェースの競合最初に出たエラーログを確認し、サービスが起動しているかを調べます。ほかのVPNを一時停止して再試行してください。
ドメイン名でアクセスできないDNS上流と通信の取り込み経路DNSタイムアウトのログを確認します。nslookup example.comでシステムの問い合わせ結果を確認できますが、ブラウザーの名前解決経路を証明するものではありません。
Webページは表示できるが、音声通話やゲームが動かないUDPの出力対応、ルール、MTUノードのプロトコルとサーバー側がUDPに対応しているか確認します。まず接続ログを確認し、その後、使用中のカーネルのドキュメントに従ってMTUを調整してください。
プリンター、NAS、LAN内のドメインに接続できないLAN内のルートと内部DNS実際のネットワーク範囲、直接接続ルール、TUNのルート除外を確認し、LAN全体をリモートノードに送らないようにしてください。
接続は発生するが、出口が想定と異なるモード、一致したルール、プロキシグループ接続ログでルールとポリシーの経路全体を確認し、DIRECTや意図しないフォールバックポリシーに一致していないか調べてください。
TUNを無効にしてもネットに接続できないプロキシ設定の残留、DNSキャッシュ、ルートクライアントを終了してシステムプロキシを確認します。影響を受けたアプリを再起動し、ルートが元に戻っているかも確認してください。

LANの除外とDIRECTは別の層で行う設定

ルールでLAN内アドレスにDIRECTを指定すると、通信がカーネルに入った後、直接接続が選ばれます。一方、TUNのルーティング層でネットワーク範囲を除外すると、通信自体がカーネルに入らない場合があります。用途が異なる設定です。社内VPNを使う場合は、会社のネットワーク範囲やDNSの配布方法を先に確認してください。すべてのプライベートアドレスを除外する設定を、そのまま流用するのは避けましょう。

MTUとVPN同士の競合は最後に確認

大きな応答の一部、アップロード、特定のUDP通信だけが止まる場合に限り、経路MTUを確認します。MTUを下げても、DNSに到達できない問題やノードの停止は解決しません。2つのVPNが同時にデフォルトルートを変更すると、ループや出口の切り替わりが起こることもあります。まず各VPNを個別に検証し、問題なく動作することを確認してから、高度なルーティングの組み合わせを検討してください。

有効化後の確認項目と元に戻す方法

プロキシが必要なのがブラウザーやシステムプロキシに従うアプリだけなら、システムプロキシのほうが動作を把握しやすく、管理も簡単です。プロキシ設定を参照しないアプリの通信も取り込みたい場合や、UDPをまとめて処理したい場合にTUNを有効にし、検証済みの復旧用設定を残しておきましょう。安定した設定とは、通信の入口、名前解決、ルール、出口を説明できる状態です。スイッチの数が多いことではありません。