2026年8月21日応用設定読了時間：約12分

ClashのTUNモードとシステムプロキシの違い｜通信の範囲と使い分け

システムプロキシとTUNの仕組みの違いを解説。ゲーム、コマンドライン、UWPアプリに適した方式も紹介します。

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

普段のブラウジングにはシステムプロキシを使い、プロキシ設定を参照しないアプリやUDP通信も取り込みたい場合、複数のアプリをまとめて処理したい場合はTUNモードを検討しましょう。この2つが決めるのは「通信をどうmihomoに取り込むか」であり、最終的に直接接続するかプロキシノードを経由するかではありません。

mihomoでは、接続を3段階に分けて考えられます。まずプロキシポートまたはTUN仮想インターフェースから取り込み、次にルールを照合し、最後に直接接続またはプロキシノードへ送ります。入口、ルール、出口はそれぞれ独立しています。入口だけ切り替えても、適用されるルールが変わるとは限りません。

「すべての通信を取り込む」はTUNの用途を示す表現で、無条件に保証されるものではありません。ルートの除外設定、ほかの仮想インターフェース、IPv6の設定、アプリのインターフェース指定、クライアントの実装によって、実際の対象範囲は変わります。ノードへの接続はTUNを正しく迂回させ、ループを防ぐ必要があります。

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

システムプロキシの仕組み

クライアントで「システムプロキシ」を有効にすると、通常はOSのプロキシ設定がローカルの待ち受けアドレス（例：127.0.0.1:7890）に変更されます。この設定を参照するアプリは通信をそのアドレスに送りますが、設定を参照しないアプリは従来どおりの経路で接続します。

7890はこの記事で使う設定例であり、すべてのクライアントに共通する固定ポートではありません。クライアントの設定画面で「混合ポート」または「HTTPポート」を確認してください。表示された値が異なる場合は、コマンドやアプリのプロキシ設定も同じ値に変更します。コントローラーのポートをプロキシポートと取り違えないようにしてください。

ブラウザー：通常はシステムプロキシを参照しますが、ブラウザー独自のプロキシ設定がシステム設定より優先される場合があります。
コマンドラインツール：デスクトップOSのシステムプロキシを参照するとは限らず、プロキシ用の引数や環境変数が必要な場合があります。
ゲーム・リアルタイム通信：ネイティブのUDP通信は、HTTPシステムプロキシを有効にしただけでは通常mihomoに取り込まれません。
独自のネットワーク接続を実装したアプリ：システムプロキシを迂回することがあります。ログイン画面だけがプロキシ経由になり、メインの通信は直接接続される場合もあります。

プロキシを明示してポートの動作を確認

次のコマンドは、リクエストをローカルのHTTPプロキシ経由で送るよう明示します。Windowsのターミナルでは、同名コマンドとの混同を避けるためcurl.exeを使ってください。ほかのOSでは通常curlを使います。

curl --head --proxy http://127.0.0.1:7890 https://clash67.com/

実行後、クライアントの接続ログを確認します。宛先ドメインと適用ルールが表示されていれば、そのリクエストが実際にmihomoへ届いたと判断できます。HTTPステータスコードが示すのは接続先サイトのその時点での応答であり、すべてのサイトにアクセスできることを保証するものではありません。また、このテストではプロキシをコマンドで明示しているため、OSのシステムプロキシ設定が正しく反映されたかどうかは確認できません。

TUNモード：仮想インターフェースとルーティングで通信を取り込む

TUNはレイヤー3の仮想ネットワークインターフェースです。クライアントがインターフェースを作成してルートを設定すると、条件に合うIPパケットがmihomoに取り込まれます。アプリ側でHTTPやSOCKSプロキシに対応する必要がないため、システムプロキシ設定を参照しないプログラムも対象にしやすくなります。

この方式で通信を取り込むには、通常、より高いシステム権限が必要です。デスクトップ版クライアントでは、バックグラウンドサービスや昇格したプロセスがインターフェースとルートを設定する場合があります。Androidでは、システムのVPN許可を使って指定アプリの通信を取り込む方式が一般的です。プラットフォームによって実装や設定名が異なるため、デスクトップ版の設定値をそのままスマートフォンに適用しないでください。

mihomoのTUN設定例

以下は一般的な入口の設定例です。ノード、グループ、DNSの設定一式は含みません。現在有効な設定に統合し、サブスクリプション全体を置き換えないでください。既存のtunまたは同名のトップレベルキーがある場合は、重複定義を避けるため既存の項目を編集します。

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

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

mixed-port：同じポートでHTTPとSOCKSのプロキシ接続を受け付けます。TUNを有効にした後も、この入口を残せます。
allow-lan: false：LANにプロキシサービスを公開しません。この設定を有効にしなくても、TUNは本機で利用できます。
stack: mixed：mihomoがサポートする混合スタックを選択します。「システムプロキシも同時に有効にする」という意味ではありません。実際に使える値は、クライアントに搭載されたカーネルに依存します。
auto-route：関連するルートをmihomoに自動設定させます。仮想インターフェースを作成しただけで適切なルートが設定されていない場合、対象の通信を取り込めないことがあります。
auto-detect-interface：送信インターフェースを自動検出します。複数のネットワークインターフェースがある環境では、ログと実際に選ばれた出口も確認してください。
dns-hijack：条件に合う従来型DNSリクエストを取り込みます。UDP 53とTCP 53が対象ですが、アプリ内の暗号化DNSを直接復号するものではありません。

システムプロキシとTUNの使い分け

利用シーン	優先する方式	確認する項目
ブラウザーでWebサイトを閲覧	システムプロキシ	ブラウザーがシステム設定に従うか、独自のプロキシ設定があるか
一時的なコマンドラインリクエスト	プロキシを明示する引数	ツールが対応する引数、実際のポート、環境変数
プロキシ設定を参照しないツールを複数使用	TUN	ルートが有効か、プロセスまたはドメインのルールが適用されているか
UDPを使うゲーム	TUN	ノードとサーバーがUDPに対応しているか、誤ってDIRECTに一致していないか
UWPアプリ	まずシステムプロキシを試し、その後TUNを検討	アプリのネットワーク実装、ループバック制限、システムポリシー
社内ネットワークとほかのトンネルを併用	まずシステムプロキシを使う	社内ルート、専用DNS、ほかの仮想インターフェースとの優先順位

ゲーム：UDPを取り込めても、ノードがUDPに対応しているとは限らない

TUNを使うとゲームの通信をmihomoに取り込めますが、出口も該当する通信方式に対応している必要があります。ノードやサーバーがUDPに対応していない場合、TUNに切り替えてもその制約は解消しません。まず接続パネルでゲームの通信を確認し、ネットワーク種別、宛先アドレス、適用ルール、選択中のノードを調べてから、問題が入口と出口のどちらにあるか判断します。

ゲームランチャー、ログインサービス、対戦通信では、異なるドメインやアドレスが使われることがあります。ログインできても、対戦中の通信がプロキシ経由とは限りません。また、一度の遅延テストだけでTUNのほうが速いと判断しないでください。遅延はネットワーク経路、ノードの負荷、接続先サーバーの場所にも左右されます。

コマンドライン：単一ツールならプロキシを明示して設定

プロキシ引数に対応したツールを1つだけ使う場合、プロキシを明示して設定すると通信経路を追跡しやすく、ほかのアプリの経路も変わりません。HTTP_PROXY、HTTPS_PROXY、ALL_PROXYが有効かどうかはツールの実装によります。変数名にHTTPSが含まれていても、値にHTTPSプロキシのプロトコルが必須という意味ではありません。

UWP：プロキシ制限とループバック制限を切り分ける

一部のUWPアプリでは、ローカルプロキシへの接続時にループバック制限の影響を受けることがあります。これはノードが利用可能かどうかとは別の問題です。システムプロキシ経由で接続できない場合は、まずブラウザーでローカルポートが正常に動作するか確認し、アプリごとのループバック許可が必要か、TUNで接続できるかを調べてください。特定のアプリを調査するために、すべてのアプリの権限を一度に開放しないでください。

DNSとFake-IP：TUNで接続できてもドメインを開けないときの確認点

TUNは通信を取り込み、DNSはドメイン名を接続先のアドレスに変換します。この2つが連携して動作する必要があります。よくある症状は、有効化後にブラウザーが読み込み中のままになる、ログに名前解決のタイムアウトが出る、アプリによって同じドメインへの接続結果が異なる、といったものです。この場合、ノードを切り替えても入口側のDNSの問題は解決しないことがあります。

DNS機能が有効か確認：現在の実行設定にあるdns.enableと、クライアント独自の設定からDNS設定が生成されているかを確認します。
ポート53の取り込みを確認：従来型DNSは通常UDP 53を使い、TCP 53を使う場合もあります。どちらか一方だけでは確認が不十分です。
アプリ内の暗号化DNSを確認：アプリがHTTPSやTLSで名前解決のリクエストを送信する場合、ポート53のDNSハイジャック設定には単純には一致しません。
DNS上流への接続を確認：DNS上流サーバーに接続できることを確認します。上流への接続に未確立のプロキシ接続が必要となり、循環依存に陥らないよう注意してください。

Fake-IPは条件に合うドメインに合成アドレスを返し、mihomoがドメインとアドレスの対応を管理します。アドレスプールの例として、198.18.0.1/16がよく使われます。この範囲のアドレスが表示されても、必ずしも異常ではありません。ただし、関連する通信が想定どおりmihomoに戻らないと、接続先を正しく復元できません。

TUNを無効にした後もアプリに合成アドレスがキャッシュされていると、一時的にアクセスできなくなる場合があります。まずアプリで接続し直し、必要に応じてOSの手順でDNSキャッシュを削除してください。Windowsではターミナルでipconfig /flushdnsを実行します。ブラウザー独自のDNSキャッシュは、別途削除が必要な場合があります。LAN内の機器検出、デバイス管理、特定の社内ドメインに問題がある場合は、すべてのドメインをフィルターに加えるのではなく、用途に応じてFake-IPのフィルターと直接名前解決の設定を確認してください。

入口・ルール・出口・復旧の4段階で検証

まず正常に動作する基準を作る
TUNを無効にし、サブスクリプションが有効であることを確認して、利用可能なノードを選びます。プロキシを明示するコマンドでローカルポートをテストし、クライアントの接続パネルで宛先ドメイン、適用ルール、グループを記録します。ここで接続できない場合は、TUNの調査を重ねる前にサブスクリプション、ポート、ノードを確認してください。
TUNによる取り込みを個別に検証
必要なサービスやシステム権限を有効にしてTUNを起動し、システムプロキシを一時的に無効にします。テストツールがプロキシ環境変数を引き継いでいないことも確認してください。curl --head --noproxy "*" https://clash67.com/を実行し、接続ログを確認します。ここでの--noproxy "*"はcurlに明示的なプロキシを使わせない指定であり、OSのTUNルートを迂回するものではありません。
ルールと出口を確認
直前のリクエストを見つけ、想定したルールに一致しているか、最終的に直接接続とプロキシノードのどちらが使われているかを確認します。Webページが開けても分かるのは接続に成功したことだけです。接続先に直接アクセスできる場合、ページが表示されたことだけではプロキシ経由の通信を証明できません。
復旧と特殊なネットワークをテスト
TUNを無効にして再接続し、通常のネットワークが復旧することを確認します。次にLAN内の機器、社内ネットワーク、IPv6の接続先、ゲームのUDP通信をテストします。一度に変更する設定は1つにし、変更前後の違いを記録してください。DNS、ルーティング、グループを同時に変更すると、原因を特定できなくなります。

よくある質問：二重起動、通信断、LANアクセス

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

できます。多くのクライアントでは、2つの入口を併用できます。ただし、同時に有効にすると切り分けが難しくなります。あるアプリはプロキシポート経由、別のアプリはTUN経由で接続する場合があります。初めて設定する際は、それぞれ個別に検証してから併用するか判断してください。両方を有効にしても自動的に通信速度が上がるわけではなく、適切な出口ルートの代わりにもなりません。

TUNを有効にしたら通信できなくなりました。まず何を無効にすればよいですか？

まずTUNを無効にして、通常のネットワークが復旧するか確認します。復旧した場合は、サービスの権限、デフォルトの出口、DNS、ほかのトンネルとの競合を順に確認してください。クライアントを再起動し、仮想インターフェースが作成されたか、ルートの追加時にエラーが出ていないかも確認します。最初にシステムファイアウォールを無効にするのではなく、ログをもとに許可が必要なプログラムと通信を特定してください。

TUNを使うとLAN内機器の通信もプロキシ経由になりますか？

必ずしもそうではありません。LAN内の通信がTUNに取り込まれるか、取り込まれた後に直接接続されるかは、ルートとルールによって決まります。192.168.1.1など、機器の実際のアドレスを使ってテストし、適用ルールを確認してください。直接接続が必要な場合は、ルートの除外設定とルールの両方を確認し、LAN内の管理画面を誤ってリモートノードに送らないようにします。

PCでTUNを有効にすると、スマートフォンも自動的に同じプロキシを使いますか？

いいえ。PC本体のTUNを有効にしても、PCが自動的にLANゲートウェイになるわけではありません。スマートフォン側でプロキシを設定するか、正しく構成したゲートウェイを使用してください。スマートフォンからPCのプロキシポートに接続するには、待ち受けアドレス、LANへの公開許可、ファイアウォールルールも関係します。これらはPC本体のTUNとは別の設定です。

IPv4では正常なのに、一部のアプリがプロキシを迂回する場合はどうすればよいですか？

該当する通信がIPv6を使っていないか確認し、クライアントのIPv6設定、DNSの応答、TUNのルート設定を調べてください。IPv4だけの検証では、IPv4とIPv6の両方が取り込まれているか分かりません。また、アプリが特定のネットワークインターフェースに固定されていないか、クライアントのアプリ除外設定で迂回されていないかも確認します。

最終的な判断は、接続ログで検証してください。システムプロキシで要件を満たせるなら、シンプルな設定のまま使います。より多くのアプリを対象にする必要があればTUNを有効にし、権限、ルート、DNS、UDPの出口を一つずつ確認してください。カーネルやルールの項目については、サイトのプロトコルリファレンスにあるmihomoカーネルの説明も参照してください。