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

まず結論：違いは「全体かどうか」ではなく、通信の入口

ブラウザーやシステムプロキシ設定に従うアプリだけをプロキシ経由にするなら、まずはシステムプロキシを使います。プロキシ設定を参照しないコマンドラインツールやゲーム、その他のUDP通信も取り込みたい場合は、TUNを検討してください。2つの方式で決まるのは通信がどのようにClashのコアへ入るかです。Rule、Global、Directはコアに入った後の経路選択を決めるものであり、この2つを混同しないようにしましょう。

TUNを有効にしても、ルールがDIRECTに一致した接続は直接通信します。システムプロキシを有効にしてGlobalを選んでも、すべてのプロセスが自動的にプロキシ設定を使うわけではありません。「全体モードなのにゲームの挙動が変わらない」ときは、ノードを何度も切り替える前に、まずゲームの通信がコアに入っているか確認してください。

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

通信経路とローカルポート

システムプロキシでは通常、HTTPやHTTPSなどのプロキシアドレスをOSの設定に登録します。その設定を参照するアプリは、まずローカルのプロキシポートに接続し、コアが宛先とルールに基づいて後続の接続を確立します。ローカルの混合ポートが127.0.0.1:7890の場合、通信経路は次のとおりです。

システムプロキシに従うアプリ
  → 127.0.0.1:7890（HTTP / SOCKS混合ポート）
  → コアのルールとプロキシグループ
  → DIRECTまたは選択したプロキシノード
  → 宛先サービス

ここでの7890は例であり、すべてのクライアントで固定されているポートではありません。クライアントの設定または現在有効な設定で、mixed-port、port、socks-portを確認してください。HTTPポートをそのままSOCKSポートとして使うことはできません。HTTPとSOCKSの両方を受け付けるのは混合ポートです。

HTTPS、UDP、ブラウザー拡張機能の制約

HTTPS：通常、アプリはHTTP CONNECTを使って宛先へのトンネルを確立します。通常のプロキシ転送でコアがWebページのTLS通信を復号するわけではなく、プロキシを使うためにルート証明書をインストールする必要もありません。
UDP：OSのHTTPプロキシ設定は、汎用的なUDP転送の入口ではありません。SOCKS5にはUDP ASSOCIATEがありますが、アプリ側の実装に加え、プロキシサーバーとノードの対応も必要です。
ブラウザー：ブラウザー拡張機能、PAC、自身の設定がシステム設定より優先されることがあります。Webページが開けても、すべての通信が同じ入口を通るとは限りません。QUICなどの通信方式も、ブラウザーの実装や設定によって異なります。
ターミナル：多くのコマンドラインアプリはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照するか、アプリ固有のプロキシ引数を必要とします。デスクトップOSのシステムプロキシ設定には自動で従わない場合があります。

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」、macOSでは「システム設定」→「ネットワーク」→使用中のネットワークサービス→「詳細」→「プロキシ」でシステムプロキシを確認できます。ここで分かるのは設定が登録されていることだけで、特定のアプリが実際に使っているかまでは確認できません。

TUN：仮想NICでIPパケットを受け取る

TUNはネットワーク層に仮想インターフェースを提供します。クライアントまたはコアがルートを設定し、条件に一致したIPパケットをこのインターフェースへ送ります。コア内のプロトコルスタックがTCPやUDPを処理し、ルールに従って外向きの接続へ渡します。アプリ側でHTTPプロキシやSOCKSプロキシに対応する必要がないため、通常はシステムプロキシより広い範囲の通信を扱えます。

アプリが送信したIPパケット
  → OSによるルート選択
  → TUN仮想インターフェース
  → コアのプロトコルスタック、DNSマッピング、ルール判定
  → DIRECTまたはプロキシノード
  → 物理NICから最終的な接続を送信

TUNに高い権限が必要な理由もここにあります。仮想インターフェースの作成、ルートの変更、DNSハイジャックの設定には、管理者権限、システムサービス、またはLinuxの該当するネットワーク権限が必要になることがあります。単にプロキシアドレスを別のポートに変える仕組みではありません。

TUNを有効にしても、すべてのネットワーク環境が対象になるとは限らない

自動ルーティングには除外対象があり、別のVPNにルートを奪われることもあります。LAN、特定のインターフェース、IPv6、仮想マシン、コンテナは個別に確認してください。特にWSL2、Docker、仮想マシンでは、通信が独立したネットワーク空間や仮想スイッチを経由することがあります。ホスト側でTUNを有効にしただけでは、これらの環境のDNSやルートが正しく設定されたとは限りません。

対応範囲の違い：ブラウザー、コマンドライン、ゲーム、LAN

用途	システムプロキシ	TUN
ブラウザーのHTTP / HTTPS通信	通常は利用可能。拡張機能やPACによる上書きに注意	ルーティングで取り込まれればコアに届き、ルールに従って振り分け
curl、Gitなどのターミナルツール	環境変数または明示的なプロキシ引数が必要な場合が多い	通常はアプリ側のプロキシ引数は不要。ただし実行環境のルートを確認
ゲームのUDP通信、ボイスチャット	通常のHTTPシステムプロキシでは対象外	UDPを受け取れるが、その後の通信にはノードとサーバー側の対応も必要
LANプリンター、NAS	OSのプロキシ除外リストで直接接続することが多い	LAN向けルール、ルート除外、ファイアウォールを確認
必要な権限と変更範囲	主にアプリが参照するプロキシ設定を変更	仮想インターフェース、ルート、場合によってはDNSの取り込みを変更

ゲームでは、「TUNが通信を取り込んでいる」ことと「そのゲームに適したノードである」ことは別問題です。ノードがUDPに対応し、サーバー側でも該当する転送が許可されている必要があります。ゲームのサーバー地域、往復遅延、ジッター、パケットロス、NATの挙動もプレイ体験に影響します。プロキシ画面でHTTPの遅延が60 msと表示されても、ゲームのUDP往復遅延が60 msとは限りません。ボイスチャットの安定性も判断できません。

有効化前に確認すること：権限、ルート、DNS、ノードの対応状況

現在の状態を記録する

現在の状態を記録：現在有効な設定を保存し、システムプロキシのポート、DNS設定、ほかのVPNの状態を控えておきます。リモートで設定を変更する場合は、ネットワークを復旧するための代替手段も先に確認してください。
コアを確認：クライアントのコア情報またはログで、mihomoを使用しているかとバージョンを確認します。クライアント名だけで同じTUN設定項目に対応していると判断しないでください。
権限を確認：クライアントが案内するサービスモードや権限設定に従います。サービスをインストールしても失敗する場合は、起動ログでインターフェースの作成、権限不足、ルート設定のエラーを調べてください。スイッチを何度も切り替えるだけでは解決しません。
競合する入口を一時的に無効化：切り分け中はほかのVPNとシステムプロキシをオフにし、TUNだけを有効にします。複数の入口が同時に動作すると、通信経路を特定しにくくなります。
出口インターフェースを確認：Wi-Fi、有線LAN、テザリングを切り替えた後、自動検出された出口が正しいか確認します。出口を誤ると接続に失敗し、深刻な場合はルーティングループが発生することもあります。

mihomo設定例のポイント

以下はTUNとDNSの関連設定だけを示したもので、ノード、サブスクリプションプロバイダー、分流ルール全体は含みません。このままでは通信可能な完全な設定として使えません。既存の設定に各項目を統合し、トップレベルのdnsやtunキーを重複して作らないようにしてください。クライアントが管理する項目は、クライアントのオーバーライド機能を優先して使います。

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

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

stack: mixedはプロトコルスタックの設定であり、mixed-portでも「システムプロキシを同時に有効にする」スイッチでもありません。利用できるスタックとプラットフォームごとの挙動は、使用中のコアのドキュメントで確認してください。
auto-routeはコアにルート設定を任せる項目、auto-detect-interfaceは外向きインターフェースを検出する項目です。複数のNICやほかのVPNを使用している環境では、引き続き手動確認が必要です。
dns-hijackのany:53は、TUNに入った通常のUDP DNSリクエストを取り込む設定です。TCP 53も処理する場合は、使用中のコアの対応状況に応じてtcp://any:53を設定してください。
127.0.0.1:1053はコアがDNSを待ち受けるアドレスです。OSのDNS設定にポート番号付きのアドレスをそのまま入力できるという意味ではありません。
198.18.0.1/16は、ここではFake-IP用のアドレスプールです。合成アドレスが返されても、後続の接続がマッピングを保持するコアに戻るなら、名前解決の失敗とは限りません。

この例では具体的なDoH上流を指定していますが、到達できるかどうかは現在のネットワークとDNSの出力設定によります。ネットワークに接続できないときに、DNSの選択肢を次々と切り替えないでください。まずDNSリクエストがコアに入っているか確認し、その後、上流の名前解決や接続エラーを調べます。

DNSとIPv6：TUNを有効にしても直接接続される主な原因

通常のDNS取り込みでは暗号化DNSまで処理できない

UDP/TCP 53のハイジャックルールでは、任意のHTTPS接続に含まれるDoHリクエストを直接判別できません。DoTを自動的にコアのDNSクエリへ変換することもできません。ブラウザーで「セキュアDNS」を有効にすると、独自の名前解決経路が使われる場合があります。その通信自体はTUNに取り込まれていても、コアが同じドメインマッピング情報を取得できるとは限りません。

ドメインルールの判定に問題がある場合は、ブラウザー独自のセキュアDNSを一時的にオフにして接続し直し、コアにドメインと対応するルールが記録されるか確認してください。原因が分かったら、どの名前解決方式を使うか決めましょう。説明できないDNS設定を複数重ねたままにするのは避けてください。

IPv4が正常でも、IPv6が正常とは限らない

接続先にAレコードとAAAAレコードの両方がある場合、アプリがIPv6を優先することがあります。IPv4のルートしか確認していなければ、IPv6が別の経路を使っている可能性があります。IPv4とIPv6のテスト結果、ルート、接続ログをそれぞれ確認してください。IPv6だけ失敗する場合は、ノード全体の障害と判断する前に、ローカルのIPv6接続とコアの関連設定を調べます。

Fake-IPも通信経路全体が正しく設定されている必要があります。DNSが合成アドレスを返しても、アプリの接続がTUNを迂回すると、通常のサーバーアドレスのようにインターネット上へ接続することはできません。モードを切り替えた後、一部のアプリで失敗が続く場合は、対象アプリのDNSキャッシュや接続キャッシュを消去し、OSのDNS設定に停止済みのローカルサービスが残っていないか確認してください。

確認手順：「コアに入る」と「プロキシを経由する」を分けてテスト

手順1：ローカルのプロキシ入口を明示してテスト

まずTUNをオフにし、コアを起動したまま、次のコマンドで例示の混合ポートへ明示的に接続します。--noproxy ""は今回のリクエストの除外リストを空にし、NO_PROXYの影響を避けるための指定です。Windows PowerShellでは、古い環境の同名エイリアスとの衝突を避けるため、コマンド名をcurl.exeにできます。

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

このテストで確認できるのは、明示したプロキシ入口と今回のリクエストの出力経路だけです。システムプロキシが有効になっていることや、UDPが使えることは確認できません。この段階で失敗する場合は、仮想NICではなく、ポートの待ち受け、ルール、ノードを先に確認してください。

手順2：TUNだけを有効にし、今回のリクエストでは明示的なプロキシを無効化

システムプロキシをオフにしてTUNを有効にし、次のコマンドを実行します。--proxy ""は今回のcurlリクエストでプロキシ設定を無効にし、--noproxy "*"はアプリケーション層のプロキシを使わない指定です。OSのTUNルートを迂回するものではありません。

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

クライアントの「Connections」または接続一覧で該当時刻のリクエストを探し、「Logs」でルール、プロキシグループ、最終的な出力先を確認してください。画面によってはTUNのインバウンド種別が表示されます。表示されない場合は、仮想インターフェースのカウンターやルートも判断材料になります。Webページが正常に表示されても、もともと直接接続できていた可能性があるため、通信を取り込めた証拠にはなりません。

手順3：実際のアプリでUDPを確認

ゲームサーバーに接続するかボイスチャットを開始し、テスト時刻を記録して、接続一覧でUDP接続、宛先アドレス、ルール、プロキシ経路を確認します。接続がコアに入っていてもDIRECTに一致する場合は、該当ルールを調整してください。ノードに一致しているのにタイムアウトが続く場合は、ノードのUDP対応状況とサーバー側の制限を調べます。ブラウザーの速度テストやICMP pingでは、この確認の代わりにはなりません。

トラブルの切り分けと元に戻す方法：一度に変更するのは1項目だけ

ブラウザーは使えるが、ターミナルから接続できない：システムプロキシを使う場合は、まずターミナルの環境変数とアプリのプロキシ引数を確認します。TUNの場合は、ターミナルがコンテナ、WSL2、リモートホスト内で実行されていないか確認してください。
TUNを有効にするとすぐネットに接続できなくなる：まずTUNをオフにして元の状態に戻し、サービスの権限、仮想インターフェースの作成、デフォルトルート、物理的な出口、DNS上流を確認します。ルートの競合を避けるため、ほかのVPNは一時的に終了してください。
ゲームはプロキシ経由になったが、かえって遅くなった：ゲームサーバーまでの経路、UDPのパケットロスとジッターを確認し、同じ時間帯の直接接続とプロキシ接続を比較します。HTTPの遅延だけでゲーム向けノードを選ばないでください。
NASやプリンターに接続できない：LANのアドレス帯が直接接続のルールに一致しているか、ルート除外が必要かを確認し、ローカルファイアウォールも調べます。DIRECTはコアの出力先の判断であり、パケットが仮想インターフェースを完全に迂回するという意味ではありません。
クライアント終了後にネットワークの調子が悪い：システムプロキシが停止したポートを参照したままになっていないか、DNSが停止したローカルの待ち受け先を参照していないか、TUNのルートと仮想インターフェースが復元されているか確認してください。

選び方はシンプルです。アプリがプロキシに対応していて、主な用途がWeb閲覧ならシステムプロキシを使います。プロキシに対応していないアプリやUDP通信まで扱う必要がある場合はTUNを有効にし、権限、ルート、DNS、ノードの対応状況を順に確認してください。対応範囲が広がっても、速度が必ず向上するわけではありません。各接続の入口と出口を説明できて初めて、設定が完了したと言えます。