ClashのTUNモードとシステムプロキシの違い｜通信の取り込み方と使い分け

まず、通信の取り込みとルールによる振り分けを区別する

システムプロキシとTUNが解決するのは、アプリの接続をClashのコアにどう渡すかという入口の問題です。接続がコアに入った後、mode、rules、プロキシグループによってDIRECT、プロキシ、拒否のいずれかが決まります。つまり、「TUNを有効にする」ことは「すべての接続をプロキシ経由にする」ことではなく、「システムプロキシを有効にする」ことも「端末全体の通信を取り込む」ことを意味しません。

この記事の設定例は、Clash Metaの後継として開発されているmihomoコアを基準にしています。GUIクライアントによっては、一部の設定を生成または上書きします。旧Clashコア、モバイル端末のVPNインターフェース、デスクトップクライアントの設定を、すべて同じものとして扱うことはできません。変更前に、クライアントのコア情報または起動ログで実際に動作しているコアを確認してください。

たとえば、mode: ruleでは、TUNに入った接続でもDIRECTにマッチすることがあります。一方、システムプロキシ経由でローカルの7890ポートに入った接続が、ルールによってプロキシノードへ送られることもあります。通信の入口と出口の選択は分けて確認しましょう。

システムプロキシ：アプリからローカルポートへ接続

GUIクライアントの「システムプロキシ」は通常、OSのプロキシ設定を変更し、その設定に従うアプリからのリクエストをローカルの待ち受けポートに渡します。たとえばmixed-port: 7890の場合、アプリはまず127.0.0.1:7890に接続し、その後コアが接続先との通信を確立します。mixedポートではHTTPプロキシとSOCKSプロキシの両方を受け付けます。

HTTPSをプロキシ経由で通信しても、内容が復号されるわけではない

ブラウザーがHTTPプロキシ経由でHTTPSサイトにアクセスする場合、通常はCONNECTでトンネルを確立します。システムプロキシを有効にしただけで、サイトのTLS通信が自動的に復号されることはありません。通常のプロキシ利用にサイト証明書をインストールする必要もありません。プロキシプロトコルのHTTPと、接続先サイトがHTTPSを使うかどうかは別の話です。

システムプロキシが適用されない主なケース

コマンドラインツール：HTTP_PROXYやHTTPS_PROXYなどの環境変数だけを参照する場合や、プロキシを個別に指定する必要がある場合があります。
ゲームや独自のネットワークアプリ：ソケットを直接開き、システムプロキシ設定を参照しない場合があります。
Windowsサービス：実行アカウントやネットワークAPIが現在のユーザーと異なる場合があります。ユーザーのプロキシ設定がすべてのサービスに適用されるわけではありません。
UDPを使う通信：HTTPプロキシを有効にしただけで、ゲームのUDP通信、音声通話、QUICもプロキシ経由になるとは限りません。

システムプロキシは、サブスクリプション、ノード、基本的なルールをまず確認するのに適しています。通常、現在のユーザーのプロキシ設定を変更するために、管理者権限で常時実行する必要はありません。影響範囲も把握しやすい方法です。ブラウザーだけにプロキシが必要なら、対象を広げるためだけにすぐTUNを有効にする必要はありません。

TUN：仮想インターフェースでIPパケットを受信

TUNはシステムに仮想ネットワークインターフェースを作成し、ルーティングと組み合わせて条件に合うIPパケットをコアに渡します。アプリは通常どおり接続先に通信するだけで、HTTPプロキシやSOCKSプロキシを意識する必要はありません。mihomoはパケットを受け取って接続を処理し、ルールに応じて出口を選択します。

auto-route: trueは関連するルートを自動設定し、auto-detect-interface: trueは出口インターフェースを自動検出します。これらの設定は権限の代わりにはならず、ほかのVPNとのルート互換性を保証するものでもありません。社内VPNへの接続、Wi-Fiの切り替え、有線LANアダプターの追加後は、出口インターフェースやルートの優先順位が変わることがあります。

比較項目	システムプロキシ	TUN
コアへの通信の渡し方	アプリがローカルのプロキシポートに接続	ルートによってIPパケットを仮想インターフェースへ転送
アプリ側の対応	プロキシ設定の参照、またはプロキシの明示指定が必要	通常、アプリがプロキシプロトコルを理解する必要はない
UDPの取り込み	一般的なHTTPシステムプロキシではUDPをカバーできない	ルーティング対象のUDPを取り込めるが、出口側の対応も必要
システム権限	通常、現在のユーザー設定を変更するだけで利用可能	通常、権限昇格、サービス、またはプラットフォームの許可が必要
主な確認箇所	ポート、アプリの設定、環境変数	仮想インターフェース、ルート、DNS、出口インターフェース

TUNを使っても、UDP非対応のノードにUDP機能が追加されるわけではありません。また、任意のIPプロトコルをリモートプロキシ経由で転送できるという意味でもありません。特に、pingの成否だけでTCPサイトへのアクセス可否を判断しないでください。ICMPと実際の通信では、処理経路が異なる場合があります。

DNS：名前解決の経路がルール判定に影響する

システムプロキシ利用時に、どこでドメイン名を解決するかはアプリとプロキシプロトコルによって異なります。HTTPプロキシには、接続先をドメイン名で渡せます。SOCKS5は、ドメイン名でもアプリ側で解決済みのIPアドレスでも受け取れます。ターミナルで使うsocks5://とsocks5h://では名前解決の経路が異なる場合があるため、出口IPが変わったかどうかだけで判断しないでください。

TUNが受け取るのは、通常IPパケットです。ドメインルールを安定して機能させるには、コアがDNSの対応情報や既存のメタデータを利用するか、必要に応じて通信をスニッフィングする必要があります。仮想インターフェースを有効にしただけでDNSを確認しないと、サイトにはアクセスできてもドメインルールが想定どおりに適用されないことがあります。

fake-ipとDNSハイジャックの役割

enhanced-mode: fake-ip：対象となるDNSクエリにマッピング用アドレスを返し、コアがそのアドレスをドメイン名に対応付けます。例の198.18.0.1/16はこの対応付けに使うもので、実際のサイトの出口アドレスではありません。
dns-hijack：条件に一致するDNS通信をコアのDNS処理に渡します。一般的にはUDP 53とTCP 53を対象にします。
nameserver：コアが実際に利用する上流DNSサーバーを指定します。暗号化の有無、到達性、振り分け方針は別途検討してください。

IPv6も個別に確認が必要です。IPv4のルートだけを変更しても、IPv6が同じポリシーで取り込まれるとは限りません。社内ドメイン、プリンター名、LAN内サービスがローカルDNSに依存する場合は、対応する名前解決経路を維持してください。名前解決の異常をすべてノードの障害と決めつけないようにしましょう。

mihomoの設定：変更は最小限から

以下は設定項目を説明するための抜粋であり、サブスクリプション全体ではありません。既存設定の該当箇所に統合し、現在のproxies、proxy-groups、rulesは残してください。同じ階層にdnsやtunを重複して定義しないでください。クライアントに上書き機能がある場合は、設定がサブスクリプション更新で失われないよう、永続化される上書き機能を使ってください。

mixed-port: 7890
allow-lan: false
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:
    - 223.5.5.5
    - 119.29.29.29

127.0.0.1:1053は、ここで明示的に公開しているローカルDNSの待ち受けアドレスです。OSが自動的にこのポートへ問い合わせるという意味ではありません。TUNによるDNSハイジャックは、コアのDNSへ入る別の経路です。例では設定項目の関係を明確にするため従来型DNSを上流に指定しています。実際の環境やプライバシー要件に合わせて上流を選び、この2つのアドレスを汎用的な最適設定と捉えないでください。

stackはsystem、gvisor、mixedのどれを選ぶ？

system：システムのプロトコルスタックで接続を処理します。現在のOSとコアの実装で互換性を確認してください。
gvisor：ユーザー空間のプロトコルスタックを使用します。特定の互換性問題を切り分ける際の比較対象として使えます。
mixed：mihomoでプロトコルスタックを組み合わせます。TCPにはsystem、UDPにはgVisorの経路を使用します。

特定のstackがすべての端末で速いと決めつけないでください。テストではノード、接続先、ルールを同じに保ち、stackだけを変更します。コアを再起動し、既存の接続が終了したことを確認してから、接続成功率と実際の動作を比較してください。現在のクライアントやコアがその値に対応していない場合は、デフォルトに戻してください。別バージョンの設定を繰り返し流用するのは避けましょう。

権限と併用：まず個別に確認し、必要なら組み合わせる

Windowsでは、仮想ネットワークアダプターの作成やルートの設定に通常管理者権限が必要です。クライアントによってはサービスモードで処理します。macOSとLinuxでも、適切な権限昇格またはサービス権限が必要です。LinuxではTUNデバイスとネットワーク管理機能も関係します。GUIでTUNが有効と表示されても、操作が開始されたことを示すだけです。起動ログで権限不足、インターフェース作成、ルート追加の失敗がないか確認してください。

使い方に合わせて通信の入口を選ぶ

ブラウザーや一般的なデスクトップアプリ：まずシステムプロキシだけを有効にし、ノード、ルール、ローカルポートが正常か確認します。
ターミナルツール：まずプロキシを明示して動作を確認し、その後に環境変数の設定を検討します。一時的な環境変数なら、システム全体の変更より元に戻しやすくなります。
プロキシ設定を参照しないアプリ：システムプロキシをオフにしてからTUNだけをテストし、入口が同時に変わって問題を特定しにくくなるのを避けます。
複数の入口が必要な場合：それぞれの動作を確認した後、同時に有効にできます。アプリがローカルプロキシを明示していればその経路を使い、それ以外のルート条件に合う通信はTUNで取り込めます。

同時に有効にしても、必ず二重にプロキシされるわけではなく、ネットワーク品質が自動的に向上するわけでもありません。通常、ループを防ぐためコア自身の外向き通信はTUNの対象外にする必要があります。手動設定したルート、ほかのVPN、誤った出口インターフェースによってこの前提が崩れることがあります。併用後に問題が発生したら、まず入口を一つだけに戻してください。

システムプロキシの設定には「ローカルアドレスをバイパス」などの例外が含まれる場合があります。一方、TUNのプライベートネットワーク向けルーティングは別の設定です。NAS、LANプリンター、社内ネットワークに接続する場合は、システムプロキシのバイパス一覧、ルート、mihomoのルールを個別に確認してください。両者の例外範囲が同じだと思い込まないようにしましょう。

動作確認とトラブルシューティング：接続経路を特定する

同じ接続先を使って比較し、まずローカルプロキシポートが使えることを確認してから、システム側の通信取り込みを検証します。以下のコマンドはテスト方法の例であり、あらかじめ実測した結果を示すものではありません。Windowsでは、PowerShell環境によって同名のエイリアスが引数に影響することがあるため、明示的にcurl.exeを使ってください。

手順1：プロキシを明示してシステム側の設定を切り分ける

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

この場合、システムプロキシがオフでも、コマンドは指定したローカルポートへの接続を試みます。接続が拒否された場合は、まずコアが起動しているか、実際の待ち受けポートが7890か確認してください。コアに接続できてもアクセスに失敗する場合は、ログで名前解決、ルール、ノードとのハンドシェイク、リモート接続のエラーを確認します。

手順2：プロキシの明示指定を外してTUN経路を確認する

curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com/

--noproxy "*"を指定すると、今回のcurlリクエストではアプリケーション層のプロキシ設定を使いませんが、OSのTUNルートは回避しません。システムプロキシをオフ、TUNをオンにしてこのコマンドを実行し、クライアントの接続画面で接続先、適用ルール、ポリシーを確認してください。コマンドが成功しただけでは、プロキシノード経由だと証明できません。ルールによってDIRECTが選ばれている場合もあります。

手順3：症状から原因を絞り込む

明示的なプロキシでは成功し、TUNでは失敗：まず権限、仮想インターフェース、ルートを確認します。Windowsではroute print、Linuxではip routeでルーティングテーブルを確認できます。
ブラウザーでは成功し、ターミナルでは失敗：ターミナルの環境変数とツール独自のプロキシ設定を確認してください。ノードの障害とは限りません。
ドメインでは失敗し、既知のIPアドレスには接続できる：DNSを重点的に確認します。ただし適切なテストサービスを使ってください。HTTPSのドメイン名をIPアドレスに置き換えると、証明書やSNIの条件が変わります。
TCPは正常だが、音声通話やゲームに問題がある：ルールモードだけを切り替えるのではなく、UDPの取り込み、ノードのUDP対応、サーバー側の制限を確認してください。
別のVPNを有効にすると問題が起きる：一方を一時的にオフにし、デフォルトルート、DNS、出口インターフェースを比較してから、両者を併用する範囲を設定します。

変更は一度に一つに絞り、「入口、DNS、適用ルール、実際のポリシー、エラーログ」の5項目を記録してください。設定を戻す場合は、まずTUNをオフにして元の設定を復元し、システムプロキシのアドレスを確認します。クライアントを終了する前に、127.0.0.1:7890を参照したままのプロキシ設定を解除してください。ローカルの待ち受けが停止した後も、アプリが古いポートへ接続し続けるのを防げます。

初期設定は入門ガイドから始められます。ルールや設定構成を確認する場合は、ドキュメントを参照してください。