まずは通信の入口とプロキシモードを分けて考える

システムプロキシとTUNは「アプリの通信をどうClashのコアに取り込むか」を決める仕組みです。一方、ルール・グローバル・ダイレクトの各モードは「コアに取り込んだ通信の出口をどう選ぶか」を決めます。この2つは別の階層にあります。TUNを有効にしてもルールモードは使えます。中国国内のWebサイトにはDIRECTを適用し、それ以外はプロキシグループで処理できます。逆に、グローバルモードを有効にしても、プロキシ設定を参照しないゲームが自動的にコアへ取り込まれるわけではありません。

この記事の設定例は、Clash Metaの後継として開発されているmihomoコアを対象としています。Clashはコアやクライアントのエコシステムを指す通称として使われますが、GUIで利用できる機能は実際のコアとOSによって異なります。旧版Clashの設定と現行mihomoのTUN項目に完全な互換性があるとは限りません。まずクライアントのコア情報で名称を確認し、該当するドキュメントを参照してください。

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

システムプロキシを有効にすると、クライアントは通常、127.0.0.1:7890などのローカルプロキシアドレスをOSに設定します。この設定に従うブラウザーは、まずそのポートへ接続し、続いてコアがダイレクト接続かプロキシ経由かを選びます。HTTPSでは通常、HTTP CONNECTでトンネルを確立します。システムプロキシを使ってもHTTPSの内容が復号されるわけではなく、通常のプロキシ転送に証明書のインストールも必要ありません。

対象範囲はアプリによって決まる

  • ブラウザー：多くのブラウザーは標準でシステムプロキシを参照しますが、拡張機能、企業ポリシー、ブラウザー独自の設定によって上書きされる場合があります。
  • コマンドライン：curl、Git、パッケージマネージャーがシステム設定を使うかどうかは、ツールやビルド方法によって異なります。明示的な引数や環境変数を使うと、設定を確認しやすくなります。
  • ゲーム・音声通話：多くのアプリはソケットで直接通信し、システムのHTTPプロキシを参照しません。システムプロキシを有効にしただけでは、UDP通信の経路は変わらないことがほとんどです。

mixed-portは、HTTPとSOCKSの両方のプロキシ接続を受け付ける待ち受けポートです。以下の設定では、ローカルアプリがポート7890経由でコアに接続できます。ただし、システムプロキシが自動設定されるわけでも、ほかのデバイスからこのポートに接続できるわけでもありません。

ローカル待ち受け設定の例
mixed-port: 7890
allow-lan: false
mode: rule

システムプロキシの主な利点は、変更の影響範囲が小さいことです。通常のWeb通信をプロキシ経由にするために仮想ネットワークインターフェースを追加する必要はなく、無効にすれば通常はシステムプロキシ設定を元に戻すだけで済みます。一方、アプリがこの入口を使わなければ、コアは該当する通信を認識できません。

TUN：仮想ネットワークインターフェースとルーティングで通信を取り込む

TUNはL3の仮想ネットワークインターフェースを作成し、OSがそのインターフェースへルーティングしたIPパケットを受け取ります。コアは通信を処理し、ルールに従って実際の接続を確立します。そのため、プロキシ設定のないアプリでも通信を取り込める場合があります。すべてのアプリにHTTPプロキシを使わせるのではなく、より低いネットワーク層で通信経路を変える仕組みです。

デスクトップOSで仮想ネットワークインターフェースを作成してルートを変更するには、通常、管理者権限や特権サービス、またはOSが提供する機能が必要です。Androidクライアントは一般に、OSのVPNインターフェースを使って通信を取り込みます。同じユーザー領域では、この種のVPNを2つ同時に有効にできないのが一般的です。実際の動作はプラットフォームとクライアントの実装によって異なります。

mihomo TUN設定項目の例

既存の設定に追加してください。完全なサブスクリプションではありません
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • stack: mixedはmihomoがサポートする混合スタック方式を選びます。名前だけでほかのスタックより高速だと判断しないでください。
  • auto-routeはルートの自動設定を要求します。auto-detect-interfaceは出口インターフェースの自動検出に使います。対応状況や効果はプラットフォームによって異なります。
  • dns-hijackは、条件に一致する従来型DNSリクエストをコアのDNS処理に渡します。DNSモジュールを有効にし、正しく設定する必要があります。この例は、すべての暗号化DNS経路を網羅していません。

システムプロキシとTUNの違い

比較項目システムプロキシTUN
コアに通信が取り込まれる条件アプリがプロキシ設定を参照する、またはプロキシを明示的に指定するOSが対象のパケットを仮想インターフェースへルーティングする
主な対象プロキシ設定に従うブラウザーやその他のアプリプロキシ設定に対応していないアプリも対象。ただしルーティング範囲による制限あり
UDP通常のシステムHTTPプロキシでは基本的に対象外。SOCKS UDPはアプリ側の対応が必要UDPも取り込めるが、ノードのプロトコルとサーバー側の転送対応が必要
権限とシステムへの変更主にユーザーのプロキシ設定を変更通常は特権、仮想インターフェース、ルートの変更を伴う
DNSのトラブル時に確認する点アプリがローカルで名前解決するか、プロキシに任せるかDNSの取り込み、コアでの名前解決、暗号化DNS、IPv6の経路
よくある問題プロキシポートの誤り、設定の残存、アプリ独自の設定ほかのVPN、仮想ネットワークインターフェース、出口の自動検出、ルートの競合

どちらの方法でもノードの帯域が増えるわけではありません。TUNではパケット処理の工程も加わり、リソース消費はプロトコルスタック、OS、接続数などによって変わります。ブラウザーがすでにプロキシを正しく使えているなら、TUNに切り替えただけでダウンロード速度が倍増したり、遅延が必ず下がったりするとは限りません。

ゲーム・ターミナル・UWPでの選び方

Web閲覧と一般的なダウンロード：まずはシステムプロキシ

ブラウザーや、プロキシを明示的に設定できるダウンロードツールだけが対象なら、通常はシステムプロキシで十分です。まず接続パネルにブラウザーのリクエストが表示されることを確認し、適用されたルールと実際の出口を調べましょう。特定のWebサイトにアクセスできない場合、TUNを追加する前にノード、DNS、ルールを確認してください。

ターミナルツール：対象が少なければ個別に指定

Windows PowerShellでは、curl.exeを使うと、環境によってcurlが別名として扱われることによる違いを避けられます。以下の2つのコマンドは、HTTPプロキシとSOCKS5プロキシをそれぞれテストします。2つ目のコマンドでは、プロキシ側で接続先の名前解決を行います。ポート番号はクライアントの実際の待ち受けポートに合わせてください。

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

Gitやパッケージマネージャーだけにプロキシが必要なら、そのツールだけに設定できます。多くのコマンドラインアプリや子プロセス、開発ツールの通信をまとめて取り込みたい場合は、TUNを検討してください。環境変数が影響するのは、それを読み取るプロセスだけです。反映にターミナルの再起動が必要な場合もあります。

ゲーム・音声通話：UDP対応と接続先の地域を確認

TUNは、プロキシ設定に対応していないゲームの通信を取り込むのに適しています。ただし、「通信を取り込めること」と「ゲームに接続できること」は別です。ノードのプロトコル、ノード設定、サーバーのすべてが必要なUDP転送に対応している必要があります。また、ゲームが実際に接続するサーバーの地域と適用ルールを確認し、近くのサーバーへの直結通信が遠方の出口経由にならないようにしてください。遅延テストで50ミリ秒と表示されても、ゲームサーバーとの往復遅延が50ミリ秒になるとは限りません。これは数値の意味を示す例であり、実測値ではありません。

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

Windowsの一部のUWP／AppContainerアプリでは、ローカルのループバックアドレスへのアクセスが制限されます。システムプロキシが127.0.0.1:7890を指していても、アプリが正常に利用できない場合があります。TUNを使えば、アプリがローカルHTTPプロキシへ直接アクセスする必要はなくなりますが、UWPのネットワーク問題がすべてループバック制限に起因するわけではありません。クライアントのループバック免除ツールを使う場合は、必要性があり、対応しているアプリに限って適用してください。一括免除を標準の手順にしないでください。

TUN有効化後の確認とトラブルシューティング

まずシステムプロキシが使える状態を基準として確認し、その後TUNだけを個別にテストすることをおすすめします。両方を有効にしても必ずループが発生するわけではありませんが、リクエストの入口を特定しにくくなります。特に、プロキシ環境変数を明示的に設定したターミナルは、システムプロキシを無効にしてもローカルポート経由で通信し続けることがあります。

  1. 通常のネットワーク接続を確認。2つの通信取り込み機能をいったん無効にし、ローカルネットワーク、ゲートウェイ、直結サイトが正常か確認して、基本的な接続障害を切り分けます。
  2. システムプロキシを確認。システムプロキシを有効にし、明示的に--proxyを指定したリクエストで、ポート7890の待ち受け、ノード、ルールが使えるか確認します。
  3. TUNだけをテスト。システムプロキシを無効にし、テスト対象アプリ独自のプロキシ設定を解除してからTUNを有効にします。プロキシ引数を指定していないアプリで新しい接続を試してください。
  4. 通信が取り込まれた証拠を確認。接続パネルやログで対象の接続を探し、ルール、プロキシグループ、出口を確認します。WindowsではGet-NetAdapterでインターフェースを、route printでルートを確認できます。タスクトレイのアイコンだけで判断しないでください。
  5. DNSとIPv6を確認。ドメイン名の解決に失敗する一方で既存の接続は正常な場合は、名前解決のログを重点的に確認します。IPv4は正常でも一部のアプリが迂回する場合は、IPv6のルートと設定も対象になっているか調べてください。

接続記録はあるのにアクセスできない

少なくとも一部のリクエストはコアに届いています。次に、REJECTルールに一致していないか、利用できないノードが選ばれていないか、サーバー側で接続が拒否されていないか確認してください。UDPを使うゲームは失敗するのにHTTPSは正常な場合、まずUDP対応を確認しましょう。HTTPのテストが成功しても、すべてのプロトコルが使えるとは限りません。

該当する接続記録がまったくない

まず接続パネルが現在稼働中のコアに接続されているか確認し、次にTUNサービスの権限、自動ルートの反映状況、アプリが物理ネットワークインターフェースを指定していないか、別のVPNがデフォルト経路を占有していないかを調べてください。Windowsでは「設定」→「ネットワークとインターネット」→「プロキシ」で、システムプロキシ設定が残っていないか確認できます。この手順はWindows 11を対象としています。ほかのバージョンでは項目名が異なる場合があります。

選び方のまとめ：アプリの対象範囲で決める

  • ブラウザーの通信だけが必要：まずはシステムプロキシを使い、ルールモードを維持してローカルポートと現在のプロキシグループを確認します。
  • ターミナルツールが少数：明示的なプロキシ引数か、ツール自体の設定を優先すると、個別に確認・解除しやすくなります。
  • ゲーム、音声通話、プロキシ非対応アプリ：TUNを検討し、UDP、DNS、IPv6、ルートの対象範囲も確認します。
  • 企業VPNや複雑な仮想ネットワークを利用中：まずルートの競合を評価してください。システムプロキシのほうが、通常は影響範囲を管理しやすくなります。

選ぶ基準は、どの設定が「全体に効きそうか」ではなく、アプリがどのようにネットワークへ接続するかです。動作確認済みの経路を1つ維持し、一度に変更する設定は1つだけにして、接続記録とルールの適用状況で結果を確認しましょう。すべての設定を同時に有効にするより、問題の原因を特定しやすくなります。初期設定については入門ガイドを、ルールや設定の構成については初心者から上級者向けの設定ガイドをご覧ください。