ClashのTUNモードとシステムプロキシの違い｜通信を取り込む仕組みを徹底比較

まず通信の取り込み方式を選び、次にプロキシルールを確認

ブラウザーや一般的なWebアクセス：まずはシステムプロキシを使い、アプリがOSのプロキシ設定を参照しているか確認します。
curl、Git、開発ツール：最初にプロキシポートを明示的に設定します。プロキシに対応していないツールや、通信をまとめて取り込みたい場合はTUNを検討してください。
ゲーム、音声通話、UDPアプリ：まずTUNを検討し、接続先プロトコル、ノード側、ネットワーク経路がUDPに対応していることを確認します。
会社のVPN、コンテナ、仮想マシンを併用：まずルーティングとDNSを確認し、複数の通信取り込みツールを安易に重ねないようにします。

Clash Metaは現在、一般にmihomoカーネルのエコシステムを指します。クライアントの画面ではサブスクリプションの読み込み、設定の管理、機能の切り替えを行い、カーネルが接続を受け付けてルールを照合し、通信の出口を確立します。システムプロキシとTUNは通信の入口が異なる方式であり、サブスクリプションやノードが別々に存在するわけではありません。

システムプロキシ：アプリがローカルポートに接続

システムプロキシを有効にすると、通常は127.0.0.1:7890のようなローカルプロキシアドレスがOSの設定に登録されます。この設定を参照するアプリは、そのポートにリクエストを送ります。ポート番号はクライアントで現在有効な設定と一致させてください。例の7890がすべてのクライアントで使われる固定値ではありません。

mixed-port: 7890
allow-lan: false
mode: rule

この設定は、mihomoが混合ポートでHTTPおよびSOCKSプロキシのリクエストを受け付けるものです。ただし、OSのシステムプロキシを有効にする設定ではありません。クライアントの「システムプロキシ」ボタンが別途その役割を担います。システムプロキシ画面に設定するのは通常HTTPプロキシのポートであり、OS上のすべてのプログラムがSOCKSを使うという意味ではありません。

ブラウザーで使えることが多い理由

一般的なデスクトップ環境では、ChromeやEdgeはシステムプロキシを参照します。Firefoxは独自のネットワーク設定を使う場合があるため、「設定」→「一般」→「ネットワーク設定」→「設定」で「システムのプロキシー設定を利用する」が選択されているか確認してください。ブラウザー拡張機能がプロキシ設定を上書きすることもあります。問題を切り分ける際は、拡張機能にプロキシ権限があるかも確認しましょう。

ターミナルからの通信が直接接続になりやすい理由

ターミナルのプログラムは、それぞれ独自にネットワークへの接続方法を決めています。デスクトップのプロキシ設定を参照するとは限りません。まずプロキシを明示してテストすれば、「ツールがプロキシを使っていない」のか「ノードへの接続に失敗している」のかを切り分けられます。

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

現在のシェルセッションでプロキシを使う場合は、次の環境変数を設定します。HTTPSリクエストもHTTPプロキシのCONNECTトンネルを通るため、https_proxyの値にはhttp://を指定できます。

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890

# テスト後に現在のセッション設定を解除
unset http_proxy https_proxy

上記のコマンドは一般的なPOSIXシェル向けで、PowerShellの構文ではありません。また、すべてのプログラムがこれらの環境変数に従うとは限らず、開発ツールによっては個別の設定が必要です。SOCKSのテストで宛先ドメインの名前解決をプロキシ側に任せる場合は、curl --proxy socks5h://127.0.0.1:7890を使えます。hは宛先ドメインの名前解決をプロキシ側で行うことを示します。

TUN：仮想ネットワークインターフェースでIP通信を受け取る

TUNはOS上にL3の仮想ネットワークインターフェースを作成し、ルーティングルールと組み合わせて条件に合うIP通信をmihomoに送ります。アプリはHTTPプロキシの仕組みを意識せず、通常どおりTCPまたはUDP接続を開始できます。カーネルは受け取った通信を設定に従って直接接続、遮断、またはプロキシノードへ転送します。

TUNは通常、システムプロキシより広い範囲の通信を扱えますが、どのネットワーク環境でも「すべてのアプリを切り替える」機能ではありません。ルートの除外設定、他のVPN、ネットワーク名前空間、仮想マシンのネットワーク、OSの権限などによって、実際に取り込める範囲は変わります。

最小限の確認用設定

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

enable：TUNを有効にします。インターフェースを作成できるかどうかは、権限や実行環境にも左右されます。
stack: mixed：混合スタックを選択します。通常はTCPをシステムスタック、UDPをgVisorスタックで処理します。プロキシノードのプロトコルではありません。
auto-route：必要なルートを自動設定します。他のVPNと競合する場合は、既定の動作をそのまま使わないでください。
auto-detect-interface：通信の出口となるインターフェースの検出を補助します。複数のネットワークインターフェースやVPNを併用する場合は、実際に選択されたものを確認してください。
dns-hijack：該当する従来型DNSリクエストをカーネルのDNSモジュールに送ります。アプリ内のDoHやDoTを直接復号するものではありません。

Windowsでは通常、管理者権限またはクライアントがインストールするサービスコンポーネントが必要です。Linuxでは適切なネットワーク管理権限とTUNデバイスが必要で、macOSではクライアントに応じた認証が求められます。メニュー名はクライアントによって異なるため、「サービスモード」や権限に関する案内を確認してからTUNを有効にしてください。スイッチがオンであることだけでは、仮想インターフェースやルートが作成された証拠になりません。

ブラウザー、コマンドライン、UDPの対応範囲を比較

通信の種類	システムプロキシ	TUNモード
ブラウザーのHTTP / HTTPS	アプリがシステム設定を参照する場合に取り込み可能	ルートが対象通信をカバーすれば取り込み可能
curl、Gitなどのコマンドライン	多くの場合、引数・環境変数・ツールの設定が必要	通常、プロキシポートをアプリごとに設定する必要はありません
ゲーム、音声通話のUDP通信	通常のHTTPシステムプロキシでは通常カバーされない	通信は取り込めますが、出口の経路もUDPに対応している必要があります
LANとプリンター	プロキシのバイパスリストによって異なる	ルートの除外設定とDIRECTルールによって異なる
コンテナと仮想マシン	通常、それぞれの環境で設定が必要	仮想ネットワークの構成と転送経路によって異なる

UDPを取り込めても、ノードがUDPを転送できるとは限らない

ゲームや音声通話ではUDPがよく使われます。ブラウザーのHTTP/3もQUICを使用し、通常はUDPの443番ポートで通信します。TUNは通信の入口を用意できますが、ノードのプロトコル、クライアント側のノード設定、サーバーの対応、ネットワーク事業者の環境がすべて要件を満たす必要があります。一般的なHTTPプロキシはこの種のUDP通信を直接転送できません。UDP対応のSOCKSクライアントを使う方法は、明示的にプロキシを設定する別の経路です。

そのため、「Webサイトは見られるのにゲームはつながらない」という現象だけで、TUNの不具合とは判断できません。まず接続ログでゲームの宛先、プロトコル、最終的に適用されたポリシーを確認し、次にノードがUDPに対応しているかを調べてください。ノードの遅延テストは通常、特定のテスト先へのリクエスト結果を示すだけで、ゲームのUDP通信が可能である証明にはなりません。

DNS、fake-ip、ルール照合の関係

システムプロキシとTUNはいずれもドメイン名を扱いますが、情報の取得方法は異なります。HTTP CONNECTやSOCKSのドメイン指定リクエストでは、宛先のドメイン名をそのままプロキシに渡せます。一方、TUNが最初に受け取るのはIPパケットです。ドメインルールを安定して適用するには、カーネルがDNSとの対応付けやスニッフィングなどでドメイン名を特定する必要があります。宛先IPだけからサイト名を推測するわけではありません。

fake-ipモードでは、カーネルが198.18.0.1/16の範囲から合成アドレスをアプリに返し、実際のドメイン名との対応を保持できます。接続がカーネルに届いた後、ドメイン名に基づいてルールを照合します。このアドレス範囲はノードの出口アドレスではありません。DNSが予約済みアドレスを返したことだけを根拠に、名前解決に失敗したと判断しないでください。

よくある3つの注意点

アプリ独自の暗号化DNS：ブラウザーがHTTPS経由でDNSを問い合わせる場合、通常の53番ポートのDNSハイジャックでは問い合わせ内容を直接読み取れません。問題の切り分け中は、一時的にシステムDNSに統一して結果を比較してください。
古いDNSキャッシュ：モードを切り替えた後も、アプリが以前にキャッシュした実IPアドレスや合成アドレスを使うことがあります。テストするアプリを再起動し、必要ならシステムのDNSキャッシュを消去してから、新しい接続を確立してください。
LAN内の名前解決：ルーターの管理画面、NAS、社内ドメインでは、LAN内DNSの指定や実際のドメインに応じたfake-ipフィルターが必要な場合があります。DIRECTルールを追加するだけでは、名前解決の問題が解消しないことがあります。

Windowsではipconfig /flushdnsでシステムのDNSキャッシュを消去できますが、すべてのアプリ内キャッシュが自動で消えるわけではありません。ブラウザーとコマンドラインで結果が異なる場合は、それぞれのDNS設定と接続ログを確認してください。DNS、ノード、ルールを一度に変更しないようにしましょう。

4つの手順で通信の取り込みを確認

1. ルールとノードを固定する

まずRuleモードのまま、使用可能なノードを手動で選択します。テスト中はポリシーグループの自動切り替えを一時停止し、ノードの変更によって結果が変わらないようにしてください。7890など、クライアントで有効なポートを記録し、サブスクリプションのポリシーグループ名とルール内の参照先が一致していることも確認します。

2. システムプロキシだけをテストする

TUNをオフにし、システムプロキシをオンにします。ブラウザーで新しい接続を開き、前述のcurl --proxyコマンドも実行します。接続パネルにテストリクエストが表示されるか、どのルールに一致し、最終的にどのポリシーが使われたかを確認してください。ブラウザーではアクセスできるのに、通常のcurlが接続ログに出ない場合、コマンドラインがプロキシを明示的に使っていない可能性があります。

3. TUNだけをテストする

システムプロキシをオフにし、テスト用ターミナルに設定したプロキシ環境変数を解除してからTUNを有効にします。以前にALL_PROXY、all_proxyやツール固有のプロキシを設定した場合は、それらも確認してください。その後、プロキシ引数を付けずにコマンドを実行します。明示的なプロキシ接続の成功を、TUNが動作した証拠と取り違えないためです。

curl --connect-timeout 10 -I https://example.com

Windowsではroute print、Linuxではip routeとip rule、macOSではnetstat -rnを使ってルートを確認できます。自動ルーティングの実装はプラットフォームによって異なるため、同じデフォルトルートが表示される必要はありません。仮想インターフェースが作成され、対象の通信が想定どおりカーネルに届いているかを確認してください。

4. ルールと出口を確認する

まず接続ログでリクエストがカーネルに届いていることを確認し、次に最終的なポリシーを調べます。ルールでプロキシが指定されている場合は、信頼できるIP確認サービスで出口を比較できます。DIRECTが指定されている場合、出口が変わらないのは想定どおりです。Webページを一度開けたこと、ステータスバーのアイコン、ノードの遅延だけでは、通信経路全体が正しいとは判断できません。

モードの選び方とトラブルからの復旧

システムプロキシとTUNは同時に有効にできますか？

可能ですが、トラブルの切り分け中は、取り込み方式をどちらか一方に絞るのがおすすめです。両方を有効にすると、一部のアプリはローカルのプロキシポートに接続し、別のアプリはTUNを通るため、通信の入口が分かりにくくなります。正常な設定であれば、同じリクエストが必ず2回リモートプロキシを経由するわけではありません。ほかのVPN、誤った出力ルート、DNS設定によるループには注意してください。

TUNを有効にするとNASや会社のVPNに接続できない

まずTUNをオフにし、元のネットワークが復旧することを確認してから、LANのサブネット、会社のVPNルート、社内DNSを調べます。プロキシルールのDIRECTはカーネルの通信先を決めるもので、ルートの除外設定は通信をTUNに入れるかどうかを決めます。両者は異なるレイヤーの設定です。実際のネットワーク構成に応じて対処し、すべてのプライベートIPアドレスを安易に特定のノードへ向けないでください。

クライアントを終了してもインターネットに接続できない

システムプロキシが、待ち受けを停止した127.0.0.1:7890を参照したままになっていないか確認します。必要に応じて、残っている手動プロキシ設定をオフにしてください。
クライアントからTUNを正しく無効にし、仮想インターフェースと自動ルートが解除されたことを確認してから、プログラムを終了してください。
VPN、ネットワークインターフェース、DNSの設定を確認し、テスト前に記録した状態へ戻してください。システムのルートをすべて削除するのは避けましょう。

さらに設定を進める前に、設定ガイドでルール、DNS、TUNの説明を確認できます。元に戻せる設定を保管し、一度に変更する設定項目を一つに絞ると、問題が発生しているレイヤーをすばやく特定できます。