基本の違い：アプリがプロキシに接続するか、ルーティングで仮想ネットワークアダプターに流すか

システムプロキシはアプリ側の対応が必要で、TUNはOSのルーティングを利用します。この違いが、通信をどこまで取り込めるかを判断するポイントです。システムプロキシでは通常、OSのネットワーク設定にローカルHTTPプロキシのアドレスを登録します。この設定に対応したアプリはClashのローカル待ち受けポートに接続し、カーネルがルールを適用します。システム設定を無視するアプリや、独自のプロキシ設定を使うアプリ、直接ネットワーク接続を行うプログラムは、この経路を通らない場合があります。

一方、TUNはL3仮想ネットワークインターフェースを作成し、ルーティング条件に合うIPパケットをカーネルに渡して処理します。アプリ側でローカルプロキシのアドレスを設定する必要がないため、直接通信するソフトも幅広くカバーできます。ただし、「TUNを有効にする」ことは「すべての通信がリモートノードを経由する」ことを意味しません。ルートの除外設定、他のVPN、インターフェースの優先順位、プロキシルールによって実際の経路は変わります。

クライアント、カーネル、サブスクリプションの役割

  • クライアント：システムプロキシの切り替え、サービス管理、設定編集、接続一覧などを提供します。メニュー名や権限の仕組みはプロジェクトによって異なります。
  • カーネル：プロトコル処理、DNS、ルール判定、TUNのネットワークスタックを担います。Clash、Clash Premium、Clash Meta（後にmihomoの名称を使用）の機能を同一とみなすことはできません。
  • サブスクリプション：ノードや設定一式を提供します。プロキシグループ、ルール、DNSには影響しますが、仮想ネットワークアダプターに必要なOS権限を代替するものではありません。

この記事ではmihomoの設定項目を例に説明します。まずクライアントのカーネル情報または起動ログで実際に動作しているカーネルを確認し、各項目の対応状況を調べてください。アプリ名だけでTUN対応を判断しないようにしましょう。

システムプロキシ：ブラウザーには便利、コマンドラインは個別確認が必要

Windows 11では、「設定」→「ネットワークとインターネット」→「プロキシ」→「手動プロキシ セットアップ」でシステムプロキシのアドレスを確認できます。クライアントのHTTPまたはmixed待ち受けポートが7890の場合、アドレスには通常127.0.0.1、ポートには7890を指定します。ポート番号は例なので、現在有効な設定に合わせてください。

ブラウザーは通常システムプロキシを使いますが、拡張機能、独自のプロキシ設定、除外リストによって動作が変わることがあります。OSのユーザープロキシ設定とWinHTTPの設定も別の仕組みです。ブラウザーで通信できるからといって、バックグラウンドサービスやすべてのデスクトップアプリも同じプロキシを使うとは限りません。

curlで「ノードが使える」と「システムプロキシが適用される」を切り分ける

次の2つのコマンドはWindowsターミナルで実行できます。1つ目はHTTPプロキシを明示し、2つ目はそのままリクエストを送ります。2つ目がプロキシを使うかどうかは環境変数などの設定によるため、必ず直接接続する比較対象とは限りません。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
curl.exe --connect-timeout 10 -I https://example.com
  • プロキシを明示した場合は成功し、通常のリクエストは失敗する場合は、ノードをすぐに変更せず、まずターミナルの環境変数とアプリのプロキシ対応を確認してください。
  • 127.0.0.1:7890に接続できない場合は、待ち受けポート、カーネルの状態、ローカルファイアウォールを確認してください。
  • ローカルプロキシへの接続後にTLSまたはリモート接続で失敗する場合は、ノードとのハンドシェイク、DNS、ルールの一致状況を確認してください。

macOSやLinuxでは、たとえばHTTPS_PROXY=http://127.0.0.1:7890 curl -I https://example.comのように、1つのコマンドだけに環境変数を設定できます。変数名はHTTPSリクエスト用のプロキシ設定を示しますが、プロキシのアドレスにはHTTPを使用できます。ローカルの待ち受けポートでTLSを有効にする必要があるという意味ではありません。大文字・小文字の変数名やSOCKSへの対応はツールによって異なるため、各ツールの説明を確認してください。

TUNモード：幅広い通信を取り込める一方、権限とルーティングの確認が必要

TUNはIPパケットを受け取り、カーネルがネットワークスタックを通じてTCPやUDPなどの通信を処理し、設定に従って外向きの接続を確立します。ゲームやコマンドラインツール側でHTTPプロキシを設定する必要がないため、アプリごとのプロキシ設定が難しい場合に適しています。インターフェースの作成、ルートの変更、DNSの処理には、通常、管理者権限やサービスモード、またはOS側の許可が必要です。

mihomoの最小限の設定項目例

以下は設定の一部であり、サブスクリプション全体ではありません。既存のノード、プロキシグループ、ルール、DNSモジュールが正しく設定済みであることを前提としています。クライアントが設定の上書き機能で最終設定を生成する場合もあるため、サブスクリプション更新で上書きされる可能性のある元ファイルだけでなく、実際に適用された設定を確認してください。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • enable：TUNを有効にします。インターフェースを作成できない場合は、まず権限とサービスログを確認してください。
  • stack：ネットワークスタックの実装を選択します。mixedはmihomoの選択肢の1つであり、すべての旧カーネルにそのまま適用できるわけではありません。
  • auto-route：通信を取り込むためのルートを自動設定します。すべてのインターフェースや例外経路が対象になるわけではありません。
  • auto-detect-interface：外向きのインターフェース選択を補助します。VPNを複数同時に使用する場合は、手動での確認が必要になることがあります。
  • dns-hijack：条件に一致するDNSリクエストをカーネルのDNSモジュールに渡します。上記の例はUDP 53番ポートが対象で、すべての暗号化DNSを含むわけではありません。

利用シーン別の比較：コマンドライン、ゲーム、UWPアプリ

利用シーンシステムプロキシでの動作TUNを使う際の条件
ブラウザーでのWeb閲覧通常は利用可能。拡張機能と除外設定を確認通信を取り込めますが、Web閲覧だけなら通常は不要
curl、Gitなどのツールプロキシ引数または環境変数の指定が必要なことが多いルーティングの適用が必要。アプリごとの設定を減らせます
UDPを使うゲーム通信通常、HTTPシステムプロキシでは対象外UDPの転送機能と適切なルールが必要
サンドボックス化されたUWPアプリローカルプロキシへのアクセスがループバック制限を受ける場合がありますローカルHTTPプロキシを経由しない可能性がありますが、実際の動作確認が必要です
LAN・社内ネットワークのリソースプロキシの除外リストを利用できますLANルート、DNS、VPNとの競合を確認する必要があります

ゲーム：まずUDP対応を確認し、その後に遅延を比較

ゲームのダウンロードにはTCP/HTTPSが使われることが多い一方、対戦中の通信にはUDPが使われる場合があります。ランチャーからダウンロードできても、ゲームの対戦通信が取り込まれている証明にはなりません。接続一覧でプロセス、宛先アドレス、通信種別を確認してルールの適用状況を見たうえで、プロキシグループが最終的に選んだノードがUDP転送に対応しているか確認してください。ゲームによってはNAT、マッチング地域、アンチチートの仕様も影響するため、TUNで改善するとは限りません。

ノード一覧に表示されるHTTP遅延テストの結果だけでは、ゲーム内の遅延は判断できません。同じサーバー、近い時間帯で、直結とプロキシのそれぞれを5分間プレイし、ゲーム内の遅延とパケットロスを記録すると比較しやすくなります。「Webの測定値は80ミリ秒、対戦中は140ミリ秒」は測定対象の違いを示す例にすぎず、設定ミスの根拠にはなりません。同じ指標で変更前後を比較してください。

UWP：ループバック制限とネットワーク障害を切り分ける

AppContainerで分離された一部のアプリは、ローカルのループバックプロキシに直接アクセスできず、アプリごとのループバック除外設定が必要になることがあります。問題の切り分けを目的に、すべてのアプリを一括で許可するのは避けてください。まず対象アプリが制限を受けているか確認し、クライアント付属のツールまたはWindowsの管理方法を使います。TUNによってローカルHTTPプロキシに直接アクセスせずに済む場合はありますが、ログインサービス、証明書、アプリ独自のDNS、接続先の地域制限まで解決できるとは限りません。

DNSとFake-IP：TUNを有効にしただけではDNS漏えい対策にならない

DNSはドメイン名の解決方法を決め、カーネルがドメイン名ベースのルールを適用できるかにも影響します。Fake-IPモードでは、ドメイン名に仮想IPアドレスを返し、その後の接続時に対応表からドメイン名を復元します。リモートノードでも暗号化プロトコルでもありません。Fake-IPとTUNは併用されることがよくありますが、別々の機能です。

システムプロキシでは、HTTP CONNECTリクエストを使って通常、宛先のドメイン名をプロキシに渡せます。ただし、アプリが独自にDNSを先行解決したり、別のDNSを使ったりする場合があります。TUNでは、従来型のDNSをルーティングやDNSハイジャックによってカーネルに渡せますが、ブラウザー内蔵のDoH、AndroidのプライベートDNSなどの暗号化DNSまで、any:53を設定しただけで同じ解決ポリシーに取り込めるわけではありません。

  1. クライアントで最終的に適用される設定を開き、DNSモジュールが有効か確認したうえで、enhanced-modeと上流DNSの設定を確認してください。
  2. システムのリゾルバー、ブラウザーのセキュアDNS、他のVPNを確認し、それぞれどのリクエストを処理するのかを整理してください。
  3. モードを切り替えた後はアプリの接続を確立し直し、必要に応じてDNSキャッシュをクリアしてください。古い名前解決結果が判断に影響するのを防げます。
  4. DNSログと接続ログから通信経路を確認してください。検査サイトに表示されるリゾルバーの所在地だけで判断しないようにしましょう。

検査ページにローカルISPのリゾルバーが表示された場合は、追加調査が必要なサインですが、それだけで結論は出せません。分割ルーティングの設定では、直結するドメインをローカルDNSで解決する場合もあります。重要なのは、指定した経路で解決する想定のドメインが、実際に想定外の経路を通っていないかどうかです。

確認手順：通信の取り込み設定は一度に1つだけ変更する

最初のトラブルシューティングでは、TUN、システムプロキシ、DNSモード、ノードを同時に切り替えないでください。変更項目が多いと、通信が復旧しても原因を特定できません。まず動作確認済みのノードを固定し、次の手順で確認します。

  1. ローカルの入口を確認：TUNをオフにし、プロキシを明示する引数でテスト用アドレスにアクセスします。例のポート7890を現在のカーネルが実際に待ち受けているか確認してください。
  2. システムプロキシを確認：システムプロキシをオンにしてブラウザーで新しい接続を開始し、接続一覧に宛先ドメインと適用ルールが表示されるか確認してください。
  3. TUNだけを確認：システムプロキシとアプリ個別のプロキシ設定を一時的にオフにし、TUNを有効にしてから対象アプリを再起動します。既存の接続が再利用されないようにしてください。
  4. 外向きの経路を確認：適用されたルール、プロキシグループ、最終的に選択されたノードを確認します。通信がカーネルに入ったことだけでは、リモートプロキシを経由した証拠になりません。
  5. 実際の用途で確認：Webページはブラウザー、ゲームは実際の対戦、ターミナルは対象リポジトリやAPIでテストします。1種類の速度測定だけですべての用途を判断しないでください。

TUNを有効にしたらインターネットに接続できない

まずTUNをオフにして、通常のネットワーク接続が戻るか確認してください。次にインターフェースの作成、サービスの権限、他のVPNによるデフォルトルートの上書き、DNSへの到達性を順に確認します。ログで接続の再試行が繰り返される場合は、ノードサーバーのアドレス解決や、外向き通信がループしていないかも調べてください。インターフェース選択の誤りを、ルート規則の追加で無理に補わないようにしましょう。

LANプリンターや社内ネットワークに接続できない

192.168.10.0/24など、実際のLANのネットワーク範囲を記録し、ダイレクトルールとルートの除外設定を確認してください。プロキシルールのDIRECTは、通信がカーネルに入った後に直接外向き接続する指定です。一方、ルートの除外設定では、パケットがTUNに入らない場合があります。両者は設定の階層が異なります。社内VPNで専用DNSが必要な場合もあるため、IPルールを1つ追加しただけで解決と判断しないでください。

選び方：必要な通信範囲に応じて段階的に設定

  • Web閲覧が中心：まずはシステムプロキシを使い、ブラウザーの接続記録で適用状況を確認してください。
  • 使う開発ツールが少数：ツールごとにHTTPまたはSOCKSプロキシを明示的に設定する方法がおすすめです。適用範囲が明確で、同じ条件を再現しやすくなります。
  • システムプロキシを使わないアプリが複数ある：TUNを検討し、権限、DNS、UDP、LANへのアクセスを重点的に確認してください。
  • 社内VPNも同時に使用する：まず組織のネットワーク要件を確認し、ルーティングとDNSを併用できるかテストしてください。2つの仮想ネットワークを問題なく重ねられるとは限りません。

安定動作を確認した後であれば、クライアントの仕様に応じてシステムプロキシとTUNを併用できますが、トラブルシューティングでは分けて検証してください。両方を有効にしても必ず二重プロキシになるわけではなく、通信範囲が広がるとも限りません。アプリによってはローカルプロキシに直接接続し、別の通信は仮想ネットワークアダプターを通ります。設定をむやみに増やすより、経路が明確で検証できる状態を保つことが大切です。