まず階層を確認：プロキシ設定と仮想ネットワークインターフェース

システムプロキシとTUNモードはいずれも通信をClashへ送れますが、入口となるネットワーク階層が異なります。システムプロキシは、OSにHTTP、HTTPS、またはSOCKSプロキシのアドレスを登録し、アプリがその設定を読み取ってClashの待ち受けポートへ自発的にリクエストを渡します。一方、TUNモードは仮想ネットワークインターフェースを作成し、システムルーティングと組み合わせてIPパケットをClashのコアへ転送します。前者はアプリがプロキシ設定に従うかどうかに左右され、後者は主にルーティングが対象通信をカバーしているかどうかに依存します。

この違いが実際の対応範囲を決めます。ブラウザー、一部のデスクトップ通信アプリ、OSのネットワークインターフェースに従うプログラムは、通常そのままシステムプロキシを利用できます。コマンドラインツール、ゲーム、単独のアップデーター、独自ネットワークスタックを使うソフト、UDPだけを送信するプログラムは、システムプロキシを無視することがあります。TUNはより低い層に位置するため、こうしたプログラムのTCP・UDP通信も受け取り、mihomoなどのコアがルールに従ってプロキシ、直接接続、拒否を選択できます。

この2つは速度設定でもありません。TUNを有効にしてもノードの帯域幅が自動的に向上するわけではなく、システムプロキシを使ったからといって接続性能が悪化するわけでもありません。速度は、ローカルネットワーク、ノードの負荷、回線品質、通信プロトコル、対象サイト、DNSの結果などによって決まります。モード選択で解決するのは、主に「どの通信をコアへ取り込むか」と「ドメイン情報を接続にどう関連付けるか」という問題です。

比較項目 システムプロキシ TUNモード
取り込みの入口 アプリがOSのプロキシ設定を読み取る 仮想インターフェースとシステムルーティング
アプリの対応範囲 アプリがプロキシに対応しているかによる より多くのTCP・UDP対応プログラムをカバー可能
必要な権限 通常は現在のユーザーのプロキシ設定を変更するだけ 通常は管理者権限またはシステムネットワーク拡張が必要
DNSとの関連付け 一部のリクエストはドメイン名をそのまま渡せる 通常はDNSハイジャックとfake-ipを組み合わせて使用
トラブル対処の難易度 入口が少なく、無効化後の確認も容易 ルーティング、インターフェース、DNS、ファイアウォールを同時に確認する必要がある

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

ClashのGUIクライアントにある「システムプロキシ」スイッチは、通常、OSのHTTP・HTTPSプロキシアドレスをローカルループバックアドレスとコアの待ち受けポートに設定します。たとえば 127.0.0.1:7890 です。クライアントがmixed-portを使う場合、このポートではHTTPとSOCKSの両方の接続を受け付けられます。アプリがプロキシ設定を取得すると、まずこのローカルポートへ接続し、その後Clashが対象アドレスを読み取ってルールを照合します。

ブラウザーでHTTPSサイトへアクセスする場合、ブラウザーは通常、対象のドメイン名とポートを含むCONNECTリクエストをHTTPプロキシへ送信します。Clashはそのドメイン名を使ってDOMAIN、DOMAIN-SUFFIX、ルールセットを照合できます。トンネル確立後もHTTPSの内容はエンドツーエンドで暗号化されたままであり、通信を取り込むことはWebページの内容を復号することではありません。通常のHTTPリクエストでも、プロキシはリクエスト先からドメイン情報を取得できます。

システムプロキシの利点は、変更範囲が明確なことです。プログラムがシステム設定に従う限り、OSのルーティングを書き換えたり、仮想ネットワークインターフェースを作成したりする必要はありません。初期設定、ブラウザーでのアクセス、ドキュメントのダウンロード、一般的なデスクトップアプリでは、まずこの方式を使うとよいでしょう。スイッチをオフにすれば、クライアントは通常、元のシステムプロキシ状態へ戻ります。そのため、問題がプロキシ経路にあるのかローカルの直接接続にあるのかを素早く切り分ける用途にも向いています。

システムプロキシでよくある対応漏れ

  • アプリがシステム設定を無視する：独自のプロキシ設定を内蔵しているプログラムもあり、未設定の場合は直接ネットワークへ接続します。
  • コマンドライン環境にプロキシが引き継がれない：ターミナルツールは HTTP_PROXY、HTTPS_PROXY、または独自の設定ファイルだけを読み取ることがあります。
  • UDP通信はHTTPプロキシを通らない：ゲーム、音声通話、一部のリアルタイム通信機能は、そのまま直接接続を続けることがあります。
  • バックグラウンドサービスが別のアカウントで動作している：システムサービスが、現在デスクトップを操作しているユーザーのプロキシ設定を読み取るとは限りません。
  • アプリが独自のDNSと接続方式を固定している：ドメイン解決とその後の接続が、システムプロキシの入口を迂回することがあります。

そのため、「ブラウザーは正常なのに、特定のプログラムだけ接続できない」という場合でも、すぐにノードを変更するべきではありません。まず、そのプログラムにプロキシ設定があるかを確認し、HTTPまたはSOCKS5に対応しているかを調べます。プロキシにまったく対応していない、またはUDPも同時に取り込む必要がある場合に、TUNモードを検討してください。

TUNモード：ルーティングでIPパケットをコアへ転送

TUNはレイヤー3の仮想ネットワークインターフェースです。有効にすると、クライアントまたはmihomoコアが仮想ネットワークアダプターを作成し、設定に応じてルートを追加して、対象範囲のIPパケットをそのインターフェースへ送ります。コアはパケットから送信元アドレス、宛先アドレス、プロトコル種別を読み取り、DNSマッピング、接続スニッフィング、ルールと組み合わせて判断します。プロキシノードへ転送する場合、コアは元の接続を対応するプロキシプロトコルの接続へ変換します。ルールがDIRECTに一致した場合は、実際のネットワークインターフェースから対象へ直接接続します。

仮想インターフェース、ルーティングテーブル、ネットワークスタックに関わるため、TUNには通常、より高い権限が必要です。Windowsクライアントでは管理者としてのインストールやサービスの起動が必要になる場合があります。macOSではネットワーク拡張の許可やシステム認証情報の入力を求められることがあります。Linuxでは通常、/dev/net/tunへのアクセス権やルート設定に必要な権限が必要で、これらの操作をシステムサービスが担う場合もあります。具体的な方法はクライアントの実装によって異なるため、画面にスイッチが表示されているかだけでTUNが有効だと判断することはできません。

mihomoの設定にあるTUNセクションには、通常、スタックの種類、自動ルート、インターフェース検出、DNSハイジャックのオプションが含まれます。以下の断片はフィールド間の関係を示すものです。実際に使用する際は、クライアントが生成した設定と現在のコアのドキュメントを優先してください。

mixed-port: 7890
mode: rule

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
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

auto-route は取り込み用ルートを自動設定し、auto-detect-interface は実際の外向きインターフェースを識別して、プロキシノード自身の接続がTUNへ再び送られるのを防ぎます。対応するスタックの種類はOSやコアのバージョンによって異なり、system、gvisor、mixedなどが一般的です。スタックの種類は端末上でのパケット処理経路に影響しますが、ノードの品質やルール設定の代わりにはなりません。

プロキシループを防ぐ

TUNの取り込み範囲を広くする場合は、Clashからプロキシサーバーへの接続が実際のインターフェースから送信されることを必ず確認してください。その接続まで仮想ネットワークアダプターへルーティングされると、プロキシループが発生します。TUNを有効にした途端にすべての接続がタイムアウトする、同じ宛先への接続確立がログに繰り返し現れる、短時間だけシステムネットワークが完全に使えなくなる、といった症状が出ます。自動ルートとインターフェース検出で通常は対処できますが、複数のネットワークアダプター、VPN、仮想マシン、コンテナ、手動ルートの環境では明示的な除外が必要になる場合があります。

DNS処理：ドメインルールを正確に照合できるか

プロキシルールはドメイン名で記述されることが多い一方、TUNが受け取る元のパケットに含まれるのは主に宛先IPです。DOMAIN-SUFFIXなどのルールを正しく機能させるには、コアが「DNS検索結果と後続の接続」の対応関係を構築する必要があります。DNSハイジャック、fake-ip、接続スニッフィングはいずれもこの問題への対処方法ですが、役割はそれぞれ異なります。

fake-ipモードでは、Clash DNSがドメインに対して予約アドレス範囲内の一時アドレスを返し、そのアドレスとドメインの対応を保存します。アプリがその一時アドレスへ接続すると、コアは元のドメイン名を復元してドメインルールを適用し、リモート側へ実際の接続を確立できます。一般的なデフォルトのネットワーク範囲はベンチマーク用途の予約アドレス範囲に属し、インターネット上のサーバーアドレスではありません。この仕組みにより、「ローカルでIPへ解決してからIPルールで誤判定する」ケースを減らせます。

一部のLAN機器の検出、プリンターサービス、ゲームプラットフォーム、実際のDNS応答を必要とするプログラムは、fake-ipに適していません。その場合は fake-ip-filter で該当ドメインを除外し、実際の名前解決結果を取得させます。除外項目をむやみに増やすのは避けてください。通常のドメインを大量に除外すると、ドメインと接続の関連付けが弱まり、ルール照合がIP判定に戻ることがあります。

redir-hostモードは通常、実際のIPを返し、コアが名前解決の対応関係を記録します。一部のアプリとの互換性はより直接的ですが、1つのIPに複数のドメインが対応している場合、DNSキャッシュが別のリゾルバー由来の場合、またはアプリがClash DNSを迂回する場合は、ドメインの対応が安定しないことがあります。接続スニッフィングでは、TLS ClientHelloのSNIやHTTP Hostなどからドメイン名を補完できますが、すべてのプロトコルでドメイン名を取得できるとは限らず、HTTPSの内容を復号することもありません。

DNSリクエストの取り込み漏れを防ぐ

  1. Clash DNSが有効になっていることを確認し、クライアントに表示される待ち受けアドレスを確認します。
  2. TUNを有効にしたときは、DNSハイジャックのルールが通常の53番ポートへの問い合わせをカバーしているか確認します。
  3. 暗号化DNSを使うアプリは、指定したサーバーへ直接アクセスすることがあります。ルーティングとドメインルールによって、その接続も引き続き取り込む必要があります。
  4. トラブル対処では、古い結果が判断に影響しないよう、OSとブラウザーのDNSキャッシュを削除します。
  5. LAN内ドメインの名前解決に異常がある場合は、すべてのルールを停止するのではなく、nameserver-policy、fallback、fake-ip-filterを確認します。

システムプロキシモードでは、ブラウザーがCONNECTでドメイン名を渡すため、Clashは対象名を直接取得できます。そのため、通常はfake-ipへの依存度が低くなります。ただし、アプリが先に自分で名前解決し、IPアドレスだけをSOCKSプロキシへ渡す場合は、ドメイン情報が失われることがあります。SOCKS5はドメイン名の指定に対応していますが、その方式を使うかどうかはアプリ次第です。

利用シーン：必要な対応範囲で入口を選ぶ

日常的なWeb閲覧やシステムプロキシに対応したデスクトップソフトでは、まずシステムプロキシを有効にするとよいでしょう。ネットワークへの変更が少なく、問題が起きてもスイッチをオフにして直接接続へ戻しやすい方法です。サブスクリプションを取り込んだばかりのユーザーにとっても、まずノード、プロキシグループ、ルールが正常かを確認してからTUN層を追加できるため便利です。

プロキシ設定に対応していないソフト、UDPアプリ、ゲームプラットフォーム、バックグラウンドアップデーター、複数のコマンドラインプログラムを取り込む必要がある場合は、TUNが適しています。アプリごとにプロキシアドレスを入力する手間を減らし、異なるネットワークスタックの接続を同じルールシステムに通せます。使用前に、クライアントがTUN対応のコアを搭載していることを確認してください。現在よく使われている実装は、Clash Metaの後継プロジェクトであるmihomoが中心です。クライアントによって表示される項目名や権限管理の方法は異なります。

サーバーや開発環境では、コンテナ、リモート接続、管理経路も考慮する必要があります。SSHでデフォルトルートをリモート変更する場合、TUNのルート設定を誤ると管理接続が直ちに切断されることがあります。このような環境では、別のターミナルを確保し、自動ロールバックを設定したうえで、管理用ネットワークを明示的に除外してください。コンテナの通信がTUNへ入るかどうかは、ホストのルーティング、ネットワーク名前空間、転送ルールによって決まり、ホスト上のブラウザーでプロキシが成功したかだけでは判断できません。

段階的に設定するおすすめの手順

  1. 有効なサブスクリプションを取り込み、接続可能なノードまたはプロキシグループを選択します。
  2. ルールモードでシステムプロキシを有効にし、ブラウザーと一般的なアプリで動作を確認します。
  3. 接続ログを確認し、ドメインルール、直接接続ルール、プロキシルールが想定どおりか確認します。
  4. 対応範囲に不足がある場合に限りTUNを有効にし、クライアントに必要なシステム権限を与えます。
  5. TCP、UDP、LANアクセス、DNS名前解決、システムのスリープ復帰をそれぞれテストします。
  6. 動作する元の設定を残し、ルーティングやDNSの項目を変更したら、一つずつ再テストします。

「より徹底的に取り込む」ために、2つの入口を同時に使う必要は通常ありません。多くのデスクトップクライアントでは、TUNを有効にしてもシステムプロキシのスイッチが残ります。これは必ずしもエラーではありませんが、一部のアプリは明示的なプロキシを先に使い、別のアプリはTUNを使うため、トラブル対処時に実際の入口を判断しにくくなります。クライアントのドキュメントに特別な指示がなければ、まずは一方だけを有効にして安定性を確認し、その後に併用が必要か検討してください。

トラブル対処：入口から外向き接続まで順に確認

モード切り替え後にインターネットへ接続できなくなった場合は、DNS、ノード、ルールを一度に複数変更せず、データ経路に沿って確認します。最初にClashコアが動作していること、ローカルのmixed-portなどの待ち受けポートが他のプロセスに占有されていないことを確認します。次に、現在使われている入口を確認します。システムプロキシのアドレスが正しいポートを指しているか、またはTUNの仮想インターフェースが作成されているかを調べてください。その後、リクエストが接続ログに現れているか確認します。

システムプロキシを有効にするとブラウザーは使えるのに、ターミナルのコマンドが直接接続される場合はどうすればよいですか？

まず、コマンドラインツールがシステムプロキシを読み取るか確認します。ツールのドキュメントに従ってHTTP、HTTPS、またはSOCKSプロキシを設定するか、多数のターミナルプログラムを一括して取り込む必要がある場合はTUNを使います。プロキシ環境変数をすべてのシェル設定へ永続的に書き込み、後で削除し忘れないようにしてください。Clash終了後も、コマンドが停止したローカルポートへ接続し続けることがあります。

TUNを有効にしたらLAN内の機器へアクセスできなくなった場合はどうすればよいですか？

LANのセグメントが誤ってプロキシへ送られていないか確認し、プライベートアドレス向けのルールがDIRECTのままになっていることを確認します。さらに、fake-ip-filterでLAN内ドメインがどう処理されているかを確認してください。プリンター、NAS、ルーターの管理画面では通常、ローカルでの名前解決と直接接続が必要です。複数のネットワークアダプターがある端末では、実際のLANインターフェースが自動ルートによって誤認識されていないかも確認します。

TUNは有効なのに、特定のUDPプログラムだけ接続できないのはなぜですか？

まず、仮想インターフェースが実際にUDPパケットを受信していることを確認し、次に選択したノードのプロトコルとサーバーが該当するUDP転送に対応しているか確認します。TUNでUDPを取り込めても、すべてのプロキシノードがその通信を正常に運べるとは限りません。ファイアウォールの制限、厳しいNAT、プログラムがLANブロードキャストを使っていること、ルールによって対象が利用できないプロキシグループへ誤って割り当てられていることも確認してください。

クライアントを終了した後もシステムは接続済みと表示されるのに、Webページを開けない場合はどうすればよいですか？

システムプロキシが、すでに待ち受けを停止したローカルポートを指しているか、TUNのルートが正常に削除されていない可能性があります。まずクライアントを再起動し、関連するスイッチを通常の手順でオフにします。その後、OSのプロキシ設定、仮想ネットワークアダプター、デフォルトルートを確認してください。プロセスの強制終了や端末の異常なシャットダウンでは、復元が必要なネットワーク状態が残りやすくなります。

ルールログにIPしか表示されず、ドメイン名が表示されない場合はどうすればよいですか？

アプリがClash DNSを迂回していないか、DNSハイジャックが有効か、拡張モードが想定どおり動作しているか確認します。アプリが独自リゾルバーを使っている、または固定IPへ直接接続している場合、コアが適用できるのはIP-CIDR、GEOIPなどのルールだけになることがあります。互換性の範囲内でスニッフィングを有効にしてドメイン名を補完できますが、まずDNS経路を修正してください。

最後にノードを比較します。同じノードがシステムプロキシでは使えるのにTUNでは使えない場合、問題は仮想インターフェース、ルーティング、DNS、権限にある可能性が高いです。両方のモードでプロキシ接続を確立できない場合は、サブスクリプションの状態、プロキシグループの選択、ノードへの到達性、ローカルネットワークを確認します。特定の対象だけに異常がある場合は、適用された具体的なルールとプロキシグループを確認し、単一サイトの問題をTUN全体の機能不全と誤認しないようにしてください。

結論：モードを決めるのは名称ではなく対応範囲

システムプロキシはアプリ層の入口に位置し、設定がわかりやすく、トラブル対処の経路も短いため、OSのプロキシ設定に従うプログラムに適しています。TUNはIPルーティングの入口に位置し、より多くのTCP、UDP、プロキシ設定を提供しないアプリをカバーできますが、権限、仮想インターフェース、ルーティング、DNSマッピング、プロキシループへの対処が必要です。どちらも最終的には接続をClashまたはmihomoのルールエンジンへ渡す仕組みであり、サブスクリプションに含まれるノード自体の品質を変えるものではありません。

まずシステムプロキシで基本設定を確認し、明確なアプリ対応の不足がある場合にTUNを有効にするのが合理的です。異常が起きたら、アプリの入口、DNS、ルール、プロキシグループ、外向きのプロキシ接続、実際のネットワークインターフェースの順に確認します。一度に変更する項目を1つに保つほうが、ノードやネットワークスタックを頻繁に切り替えるより、問題を早く特定できます。

対応するプラットフォームのインストーラーを選択

ダウンロードセンターでOSとアーキテクチャを確認し、利用ガイドに従ってサブスクリプションの取り込み、システムプロキシ、TUNモードを設定します。

ダウンロードページへ ガイドを見る