仕組みと応用 読了時間：約12分

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

TUNとシステムプロキシの違い、仮想NICがプロキシ設定に対応していないアプリの通信を取り込む仕組みを解説。サービスモードの導入、DNSハイジャック、設定後の確認方法も紹介します。

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

ブラウザーではアクセスできるのに、コマンドラインツールはタイムアウトする。Webページは表示されても、ゲームやデスクトップアプリは直接接続してしまう。こうした場合は、ノードを変える前に通信の入口を確認しましょう。Windowsのシステムプロキシは、その設定を参照するアプリに指定のHTTPプロキシへリクエストを送るよう伝えるものです。システムプロキシを参照しないアプリは、設定を切り替えても自動的にClash経由にはなりません。

TUNはネットワーク層に仮想NICを追加し、ルーティングと連携して、取り込み対象のIPパケットをカーネルに送ります。アプリがHTTPプロキシに対応している必要も、プロキシ設定を備えている必要もありません。カーネルは受け取った通信をルールに従って、直接接続、プロキシ経由、または拒否に振り分けます。

比較項目システムプロキシTUNモード
通信の入口アプリがプロキシ設定を読み取り、待ち受けポートへ接続する。システムのルーティングによって通信を仮想NICへ送る。
主な用途ブラウザーやシステムプロキシに対応したデスクトップアプリ。システムプロキシを参照しないアプリや、取り込みが必要なUDP通信。
権限通常、ローカルのプロキシ設定にシステムサービスのインストールは不要。通常、権限のあるバックグラウンドサービス、または昇格した権限で動作するカーネルが必要。
処理対象アプリがプロキシ設定を利用するかどうかによる。ルーティング、インターフェース、除外アドレス、プロトコルの対応状況による。

仮想NICが通信を取り込む仕組み

通信の流れは4段階に分けて確認できます。まずデータがカーネルに届いているか、次にどのルールに一致したかを確認し、最後にノードの性能を見ます。仮想NICが表示されただけでは、通信の取り込みが完了したとは限りません。

  1. アプリがリクエストを送信。アプリは宛先IPにTCPまたはUDPデータを送ります。ドメイン名を使う場合は、先に名前解決を行います。
  2. Windowsが経路を選択。クライアントで自動ルーティングを有効にすると、対象の通信をTUNインターフェースに送るルートが追加されます。より具体的なルート、除外アドレス、ほかのVPNが経路に影響する場合もあります。
  3. カーネルが通信を識別してルールに照合。DNSマッピングなどからドメイン名を取得し、ドメイン名・IPアドレス・プロセスのルールに基づいて方針を選びます。ドメイン名を特定できなければ、ドメインルールに一致しないことがあります。
  4. 実際の送信接続を確立。直接接続する通信は物理NICから送信され、プロキシ通信は選択したノードを経由します。クライアント自身の送信通信が再びTUNに入り、ループしないようにする必要があります。

TUNは物理NICを置き換えるものではありません。実際のネットワーク接続にはWi-Fiやイーサネットを使い、仮想NICは指定された通信をカーネルに渡します。ノードがUDPに対応していなければ、TUNを有効にしてもUDP転送が可能になるわけではありません。ゲーム、音声通話、QUICが使えるかどうかは、ノードのプロトコル、サーバー設定、ネットワーク環境にも左右されます。

有効化の前に：クライアントとサービスモード

まず基本の接続を確認

  • 信頼できる提供元のサブスクリプションを追加し、ファイルをダウンロードするだけでなく、クライアントで実際に使うプロファイルを選択します。
  • プロキシグループを開いてノードを手動で選び、まずはシステムプロキシを使ってブラウザーが接続できることを確認します。
  • 現在の待ち受けポートを確認します。例としては7890がよく使われますが、クライアントに表示される実際の値に従ってください。他の環境のポートをそのまま使わないでください。
  • 複数の仮想NICが同時にルートを変更しないよう、ほかのVPN、通信高速化ツール、別のプロキシクライアントを一時的に終了します。
  • 現在の設定、DNS設定、VPN情報を保存しておきます。リモート接続中のPCではルートを不用意に切り替えず、できるだけローカルで操作してください。

サービスモードはTUNのスイッチではない

旧版Clash for Windowsでは、サービス管理の入口は通常、General → Service Modeの横にある歯車ボタンです。管理ウィンドウを開き、Installを選んでサービスをインストールし、画面の案内に従ってWindowsの権限確認を完了します。アーカイブ版によってボタンの位置や状態表示は異なる場合があります。見つからない場合は、まず使用中のバージョンを確認し、出所不明のドライバーを繰り返しインストールしないでください。

サービスモードはバックグラウンドプロセスに特権操作を行わせるための仕組みで、TUNスイッチは仮想NICによる通信の取り込みを制御します。サービスのインストール後も、サービスが実行中であることを確認してからTUN Modeを有効にしてください。両者は互いに代用できず、GUI全体を常に管理者権限で実行する必要があるという意味でもありません。

ほかのクライアントを使う場合は、設定画面で「サービスモード」「システムサービス」「TUNモード」などの項目を探してください。旧版の画面に合わせるために、クライアントをダウングレードする必要はありません。サービスのインストールでエラーが出たら、エラー全文とカーネルログを記録し、権限、安全ソフトのブロック履歴、古いサービスの残存を確認します。システムのセキュリティ機能を安易に無効化しないでください。

mihomoのTUN設定とDNSハイジャック

以下はmihomo向けの設定項目の例であり、単独でインポートできる完全なサブスクリプションではありません。ノード、プロキシグループ、ルールが含まれていないため、既存の設定の代わりにはなりません。旧版Clash for Windowsでは、すべての項目に対応しているとは限りません。クライアントが画面操作からTUNやDNS設定を生成する場合は、サブスクリプションの更新で変更が失われないよう、画面設定またはオーバーライド機能を優先してください。

mode: rule
mixed-port: 7890

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：通信を取り込むために必要なルートをカーネルが自動設定します。仮想NICを作成しただけで適切なルートが設定されていなければ、アプリの通信が迂回することがあります。
  • auto-detect-interface：送信インターフェースの自動検出を試みます。複数のNIC、企業VPN、有線と無線の併用がある場合は、ログで実際の出口も確認してください。
  • stack: mixed：mihomoで混合プロトコルスタックを使用します。スタックの対応状況と実装はカーネルのバージョンによって異なります。特定のアプリで互換性に問題が起きた場合は、ドキュメントを参照してほかの選択肢を比較してください。
  • dns-hijack：取り込み対象の範囲に入り、指定ポート宛てに送信されたDNS通信を内蔵DNSに渡します。ここではUDP 53とTCP 53を個別に指定していますが、すべての暗号化DNSを識別できるわけではありません。
  • listen: 127.0.0.1:1053：内蔵DNSをローカルループバックアドレスの1053番ポートで待ち受けさせます。WindowsのDNSサーバーアドレスに、ポート付きの文字列を入力する設定ではありません。
  • fake-ip：ドメイン名に合成アドレスを割り当て、後続の接続をドメイン名に対応付けられるようにします。例のアドレスプール198.18.0.1/16はノードのアドレスではありません。

例にある2つの上流DNSは通常のDNSアドレスで、設定項目の構造を示すためのものです。あらゆるネットワークに適しているわけでも、暗号化された名前解決を提供するものでもありません。実際に導入する際は、上流DNSへの到達性、ノードのドメイン名解決、ルールに応じた名前解決、社内ドメインも考慮してください。設定が必要な場合は設定リファレンスを参照し、例の断片を汎用の推奨設定として扱わないでください。

DNSがルール判定に影響する理由

ドメインルールにはドメイン名の情報が必要です。アプリが独自に暗号化名前解決を行う場合や、古いキャッシュを使ってIPアドレスへ直接接続する場合、カーネルが想定したドメイン名との対応を取得できないことがあります。ポート53宛てのDNSハイジャックでは、HTTPS上のDoHやTLS上のDoTを自動的に処理できません。ブラウザーのセキュアDNS、アプリ内蔵のリゾルバー、Windowsの暗号化DNS設定によっても、実際の名前解決経路は変わります。

切り分け時は、テスト対象アプリのカスタムセキュアDNSを一時的に無効にし、システムの名前解決と比較できます。テスト後は元の設定に戻してください。一度の名前解決結果だけで「DNSリーク」と断定したり、すべてのドメインがfake-ipに解決されることを成功の基準にしたりしないでください。LAN内のデバイス名、社内ドメイン、一部の特殊なアプリでは、クライアントのドキュメントに従って例外や専用の上流DNSを設定する必要があります。

有効化の手順：変更は一度に1つ

  1. 基本のプロキシ接続を確認。ルールモードのまま、接続できることを確認済みのノードを選びます。まずTUNは無効の状態で、サブスクリプションとノードに問題がないことを確認してください。
  2. サービスをインストールして起動。クライアントのサービス管理画面から操作し、状態が正常であることを確認します。サービスが起動しない場合は、権限や残存サービスの問題を解決してから先に進んでください。
  3. TUNを有効化。権限不足、インターフェースの作成失敗、ルート追加の失敗、DNSポートの競合などがログにないか確認します。エラーが出た場合は、まずTUNを無効にしてログを保存してください。
  4. システムプロキシを無効にして切り分け。この手順は通信がTUN経由かどうかを確認するためのもので、両方を同時に有効にできないという意味ではありません。システムプロキシを残すと、ブラウザーの接続成功がHTTPプロキシによるものかもしれません。
  5. テスト接続をやり直す。テスト対象のアプリを完全に終了して再起動するか、リクエストを再送します。長時間接続や古いDNSキャッシュによって、有効化前の経路が残っている場合があります。
  6. 接続の詳細を確認。クライアントの接続一覧で、宛先、ルール、ポリシーの経路を確認します。検証が終わったら、日常の使い方に応じてシステムプロキシを残すか判断してください。

Web閲覧が目的でシステムプロキシで十分なら、「より広く通信を取り込む」ためだけにTUNを無理に有効にする必要はありません。通信を取り込む層が増えると、LAN内の機器検出、企業ネットワーク、スリープ復帰、複数NICの切り替えなどとの互換性も考慮する必要があります。

Windowsで確認：NIC・ルート・接続履歴

スイッチの色だけで判断せず、仮想インターフェース、ルートの変化、実際の接続を順に確認し、相互に照合してください。以下のコマンドは状態の確認用で、NICの変更やルートの削除は行いません。

手順1：インターフェースとルートを確認

PowerShellを開き、TUNを無効にした状態と有効にした状態で、以下のコマンドをそれぞれ実行します。追加されたインターフェースやルートを比較してください。仮想NICの名前が特定の名称になると決めつけないでください。

Get-NetAdapter -IncludeHidden |
  Format-Table Name, InterfaceDescription, Status, ifIndex

Get-NetRoute -AddressFamily IPv4 |
  Sort-Object InterfaceIndex, DestinationPrefix |
  Format-Table DestinationPrefix, NextHop, InterfaceIndex, RouteMetric

Get-DnsClientServerAddress -AddressFamily IPv4

新しいインターフェースは手がかりであって、結論ではありません。TUNは複数のルートでアドレス範囲をカバーする場合があり、見慣れたデフォルトルートが1つ追加されるとは限りません。他のVPNが持つ、より具体的なルートにも注意してください。実際の通信でIPv6を使っている場合、上記のIPv4出力だけでは完全に取り込めている証明になりません。

手順2：明示的なプロキシを使わずにリクエスト

システムプロキシを無効にした状態で、次のリクエストを実行します。--noproxy "*"を指定すると、環境変数で指定されたプロキシを含め、curlが明示的なプロキシを使わなくなります。OSのTUNルートを迂回する指定ではありません。

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

HTTPレスポンスが返っても、それだけでプロキシ経由とは判断できません。宛先に直接接続できた可能性もあります。すぐにクライアントの接続一覧を開き、宛先のドメイン名またはアドレスから該当リクエストを探し、一致したルールと最終的なDIRECTまたはノードのポリシーを確認してください。リクエストがすぐ消える場合はクライアントのログも確認します。接続が記録されるかどうかはログ設定によります。

手順3：実際に取り込みたいアプリを検証

これまでシステムプロキシを使わなかったアプリを再起動し、ネットワーク通信を1回行ってから接続一覧に表示されるか確認します。ブラウザーのテストはゲームのUDPテストの代わりにはなりません。TCPリクエストに成功しても、音声通話が使えるとは限りません。リモート側の出口を確認するには、信頼できる出口確認サービスを使い、接続詳細と照合してください。Webページに表示された地域だけでシステム全体の接続先を判断しないでください。

IPv6も個別に検証してください。クライアントのIPv6設定とルーティング、システムがIPv6アドレスを取得しているか、接続先がAAAAレコードを使うかを確認します。テストせずにすべてのIPv6通信が取り込まれていると断定しないでください。また、IPv6を全面的に無効化する方法を標準の対処として扱わないでください。

よくある問題と確認手順

症状まず確認する項目次に行う操作
TUNスイッチが勝手にオフに戻るサービスの状態、権限、インターフェースの作成エラー。最初に発生したエラーを記録し、サービスの状態を確認してから、古い仮想インターフェースやセキュリティソフトの記録を調べます。
有効化後、ドメイン名がすべて解決できない内蔵DNSが有効か、上流DNSに到達できるか、待ち受けポートが競合していないか。1053などの実際のポートを確認し、名前解決のログを調べて、まず利用可能な上流DNSに戻します。
接続はあるが、常に直接接続になるモード、ルールの順序、プロキシグループの選択。接続が一致した具体的なルールを確認し、Directモードや先に適用される直接接続ルールではないか調べます。
Webは使えるが、ゲームは接続できないUDP対応、ノード側のサーバー、ゲーム独自のネットワーク制限。該当するUDP接続を検証します。レイテンシテストの結果だけで判断しないでください。
プリンターやNASにアクセスできないLANのルーティング、DNS、ブロードキャストによるデバイス検出。デバイスのIPアドレスに直接アクセスして比較し、実際のサブネットに合わせてバイパスを設定してから、他のVPNのルートも確認します。
クライアント終了後にネットワークへ接続できないシステムプロキシの残存、サービスの状態、DNSやルートが元に戻ったか。まず通信の取り込みを正常に停止し、サービスを終了してからシステムプロキシを確認します。ネットワーク設定をすべて削除するのは避けてください。

LANの問題は層ごとに切り分けましょう。プライベートアドレスの範囲をDIRECTに設定すると、カーネルに入った後の送信方針は変わりますが、そのアドレス範囲が仮想NICを完全に迂回するわけではありません。ブロードキャスト、マルチキャスト、特殊な検出プロトコルに依存する機器では、ルートの除外も必要になる場合があります。サブネットは実際のネットワークに合わせて指定し、すべての家庭内ネットワークが192.168.1.0/24だと決めつけないでください。

DNSを変更しても古い結果が使われる場合は、必要な情報を保存したうえでipconfig /flushdnsを実行し、WindowsのDNSキャッシュを消去してからテスト対象のアプリを再起動します。これですべてのブラウザー内部キャッシュが消えるわけではなく、上流DNSやルートの誤りも修正されません。ネットワークのリセットコマンドを繰り返し実行することを、トラブルシューティングの手順にしないでください。

無効化と復旧の確認

テストに失敗した場合は、まずTUNを無効にし、クライアントを正常に終了するか、関連サービスを停止します。Windows 11では「設定 → ネットワークとインターネット → プロキシ → 手動プロキシ セットアップ」を開き、ローカルプロキシの設定が残っていないか確認します。Windows 10では「設定 → ネットワークとインターネット → プロキシ」で該当するスイッチを確認してください。組織の設定でプロキシが構成されている場合は、上書きしないでください。

  • 通信の取り込みを停止した後、通常のWebページやLAN内の機器がテスト前の状態に戻ったことを確認します。
  • DNSを手動で変更した場合は、記録しておいた元の値に戻してください。すべて自動取得に変更すればよいわけではありません。
  • インターフェースとルートを再確認し、別のVPNやプロキシが通信を取り込んだままになっていないか確認します。
  • 問い合わせる際は、OSとクライアント、カーネルのバージョン、エラー発生時刻、個人情報を伏せたログを添えてください。サブスクリプションURL、アクセストークン、ノードの認証情報は削除します。

TUNが正しく設定されているかは、取り込み対象のアプリが実際にカーネルへ届くこと、接続が想定したルールに一致すること、終了後にネットワークが正常に復旧することの3点で判断できます。入口、DNS、ルール、送信先を分けて検証すると、ノードを何度も切り替えるより原因を特定しやすくなります。

クライアントをダウンロード