目次
システムプロキシはアプリからトラフィックが渡されるのを待ち、TUN はシステムのネットワーク階層でトラフィックを取り込む
システムプロキシを有効にすると、Clash はローカルプロキシアドレスをOSへ書き込み、この設定を参照するアプリが HTTP、HTTPS リクエストをそのポートへ送ります。ブラウザは通常この設定を使いますが、ターミナルツール、ゲーム、一部のデスクトップアプリは使わない場合があります。システムプロキシだけでは UDP を一律に取り込むこともできません。
TUN は仮想アダプターを作り、システムルーティングを通じて、より多くの TCP、UDP 接続を Mihomo へ入れます。「このプロセスがローカルプロキシポートを使っていない」という入口の問題は解決できますが、ノードの可用性、ルール順序、サーバーが返す 403 は変えられません。
二つの入口方式の主な違い
| プロジェクト | システムプロキシ | TUN |
|---|---|---|
| トラフィックを Clash へ入れるかを誰が決めるか | アプリがシステム設定を参照するか | システムルーティングと仮想アダプター |
| UDP | 通常は取り込まない | TUN へ入れることはできるが、ノードと設定には引き続き依存する |
| システム権限 | プロキシ設定の変更 | 仮想アダプター、サービス、またはネットワーク拡張の権限も必要 |
| ロールバック | プロキシスイッチを無効にするだけ | TUN を無効にし、ルートとインターフェースが解除されるまで待つ |
- アプリが接続を開始するブラウザ、ターミナル、ゲーム、またはバックグラウンドサービス
- システムプロキシまたは TUNそのトラフィックがコアへ入れるかを決める
- ルールと DNSドメインを維持し、直接接続かプロキシかを決める
- 実際の送信経路DIRECT、プロキシノード、または拒否
入口はトラフィックを取り込むだけです。実際の送信経路は、ルール、DNS の結果、ポリシーグループによって決まります。
入口の判定では、元々失敗していたプログラムに接続記録があるかだけを見る
同じ操作で前後を比較する
Profile、Rule モード、ノードを固定する
自動切り替えや設定更新が入口のテストを妨げないようにします。
システムプロキシだけを有効にする
対象プログラムで、決めた操作を一つ繰り返します。
Connections を確認する
リクエストがすでに表示されるなら入口は不足していません。ルールとログを続けて確認してください。
記録がない場合に限り TUN を有効にする
同じ操作をもう一度行い、新しい接続が表示されるか比較します。
TUN で新しい接続が表示されて成功すれば、不足していた取り込み範囲を補っています。二つの入口のどちらでもリクエストが見えるのに同じ timeout になる場合は、入口を切り替え続けず、ノード、DNS、対象ネットワークを確認してください。
auto-route、interface、stack が連携して、データが仮想アダプターを通過する方法を決める
Mihomo の auto-route はトラフィックを TUN へ送り、auto-detect-interface は実際の送信アダプターを識別します。stack には system、gvisor、mixed などの実装を選択できます。既定値で対象アプリを取り込める場合は、「高速化」のためだけに安易に変更しないでください。
Wi-Fi からホットスポットへ切り替えた後に突然通信できなくなる場合、送信アダプターの変更が原因かもしれません。特定のコンピュータで system または mixed だけがファイアウォールに遮断される場合に限り、コアプロセス用のファイアウォールを調整します。Windows の strict-route は VirtualBox などの仮想ネットワークにも影響する可能性があるため、仮想マシン使用時は個別に確認してください。
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53DNS の上書きでは、名前解決リクエストを同じ判定経路へ送る
アプリはまずドメインをアドレスへ解決し、その後接続を確立します。DNS リクエストが Mihomo を迂回すると、コアには IP だけが見え、ドメインルールが想定どおりに動作しない場合があります。また、プロキシの送信経路と一致しない名前解決結果を受け取り、ホームページは開くのに画像が失敗する、同じサービスが不安定になる、といった現象も起こります。
dns-hijack は、一致する DNS トラフィックを Mihomo 内部の DNS へ渡します。すべてのシステムと接続元に自動適用されるわけではありません。Windows と macOS からは LAN 内の別端末の DNS を自動で取り込めないため、ルーターやスマートフォンからのリクエストは別途設定が必要です。Android Private DNS も通常の取り込み経路を迂回します。
- Connections にドメインがあり、ルールも正しい
- DNS とスニッフィングによって、少なくともルール判断に使える情報が得られています。
- IP しか表示されず、ドメインルールに一致しない
- DNS が Mihomo に入っているか、アプリが暗号化 DNS を使用しているか確認してください。
- IP ではアクセスできるが、ドメインでは名前解決エラーになる
- システム DNS、Mihomo DNS、現在のネットワークを重点的に比較します。
Fake-IP はドメインとの対応を維持するためのもので、無条件に高速化するものではない
fake-ip モードでは、Mihomo はまず予約済みアドレスをアプリへ返し、内部で「この仮アドレスがどのドメインに対応するか」を保存します。アプリがそのアドレスへ接続すると、コアは元のドメインを復元し、DOMAIN、DOMAIN-SUFFIX、RULE-SET を早い段階で評価できます。
この方法で DNS が自動的に速くなることも、リモートノードの品質が変わることもありません。一部の LAN サービス、端末検出、企業向けソフトウェア、IP を直接検証するプログラムでは互換性がない場合があります。対象ドメインを正確に fake-ip-filter へ追加するか、検証後に別の DNS 拡張モードを選択してください。
Fake-IP でよく見られる結果
| 動作 | 説明 |
|---|---|
| システムの問い合わせが予約済みアドレスを返す | 正常な fake-ip マッピングの場合があり、ドメインが乗っ取られたことを意味しない |
| Connections に元のドメインを表示できる | マッピングによってコアがドメインルールを評価できる |
| 特定の内部ドメインが fake-ip では失敗する | 正確なドメインを除外し、内部 DNS で解決する |
| すべてのサイトが遅い | fake-ip だけで結論を出さず、ノード、DNS 上流、ログを続けて確認する |
実際の IP が必要なアプリには、redir-host または正確な Fake-IP 例外を使う
一部の企業向けソフトウェア、LAN サービス、端末検出機能は、DNS が返す実アドレスを直接使うため、Fake-IP に適さない場合があります。設定全体を redir-host にする方法と、互換性がないと確認したドメインだけを fake-ip-filter へ追加する方法があります。前者はすべてのドメインの名前解決方法を変更し、後者は影響範囲を小さくできます。
redir-host は通常の DNS に近く、アプリは上流が返した実際の IP を直接受け取ります。一方、Mihomo が Fake-IP ほど早い段階でドメインマッピングを維持できるとは限らず、ドメインルールの識別はクライアント、キャッシュ、スニッフィング設定にも左右されます。一つの内部ドメインが失敗しただけで全体を切り替えず、まずそのドメインだけを例外にしてください。
実際の IP が必要な場合の選び方
| 状況 | より適した対処 | 検証結果 |
|---|---|---|
| 一つの企業内ドメインだけが失敗する | 正確な fake-ip-filter を追加し、内部 DNS を使用する | 実際の内部 IP を返し、接続を DIRECT に一致させる |
| ある種類のアプリが広く Fake-IP と互換性を持たない | 別の redir-host 設定と比較する | アプリが復旧し、公開ドメインのルールも引き続き正しく一致する |
| NAS とプリンターが固定プライベート IP を使用する | プライベートサブネットを DIRECT のままにする | アクセスがプロキシポリシーを遠回りしなくなる |
| 互換性のないドメインが分からない | まず Connections と DNS ログから対象を探す | 対象を確認してから例外を追加し、広範囲のワイルドカードは使わない |
DNS のトラブルシューティングでは、変更しないリクエストを一つ残す
ドメイン関連の問題が起きたら、ノードとリクエストを固定し、現在の enhanced-mode、上流 DNS、エラーを記録します。比較のために変更する変数は一つだけにしてください。たとえば、明らかに互換性のない内部ドメインを fake-ip-filter に追加するか、Android のプライベート DNS の状態を一時的に切り替えます。結果が変わった場合に限り、その変更を残します。
no such host / DNS lookup failed
上流 DNS に到達できるか、リクエストが Mihomo に入っているかを確認します。
内部ネットワークのドメインだけ名前解決できず、公開ドメインは正常
内部 DNS の経路を維持し、対象ドメインに正確な直結ルールまたは Fake-IP 除外を設定します。
ネットワークを切り替えた後だけ名前解決に失敗する
すべてのノードを変更する前に、二つのネットワークの DNS、IPv6、出口インターフェースを比較します。
ドメインルールが常に MATCH と表示される
コアがドメイン名を取得できているか、より広いルールが先に一致していないかを確認します。
ブラウザ利用者はシステムプロキシから始め、UDP または取りこぼしへの対応が必要な場合に TUN を使う
利用場面に応じて選択する
| 利用場面 | 推奨する開始方法 | 選択理由 |
|---|---|---|
| 主にウェブ閲覧と、システムプロキシに従うデスクトップアプリを使用する | システムプロキシ | 必要な権限が少なく、無効化しやすく、接続経路も明確 |
| ターミナルやゲームランチャーの記録が Connections にない | アプリプロキシまたは TUN と比較する | システムプロキシを使用しないプロセスも取り込める |
| UDP の処理が必要なアプリ | TUN | システムプロキシでは UDP を一括して取り込めない |
| 社内ネットワーク、仮想マシン、複雑なローカルネットワーク | システムプロキシから始める | まず元のルートを維持し、TUN の除外範囲を一項目ずつ検証する |
| 特定ドメインのルールが誤った経路を選ぶ | 既存の接続方式のいずれか + ルール修正 | 取り込み範囲を広げても、最初に一致するルールは変わらない |
この選択は固定ではありません。普段ブラウザしか使わないときは TUN を無効にしてシステムプロキシへ戻し、特定のプログラムで必要になったときだけ再び有効にできます。切り替え後は、スイッチの色だけで判断せず、元の操作と Connections で結果を確認してください。
通信断では、TUN、DNS、システムプロキシの順に元へ戻す
TUN を有効にした直後にすべての通信が止まった場合は、まず TUN を無効にし、元の Profile とノードを維持します。システムプロキシで復旧するなら、原因は仮想ネットワークアダプター、ルート、または TUN の DNS にあります。システムプロキシでも失敗するなら、ノードと設定を見直してください。無関係な設定まで消去されるため、いきなり OS のネットワークリセットを実行しないでください。
クライアントを終了してもウェブページが開かない場合は、システムプロキシに 127.0.0.1 の古いポートが残っていないか確認します。残存設定を削除すれば、直接接続に戻るはずです。選択した方式は実際の結果で判断できます。システムプロキシはブラウザを処理し、TUN はこれまで取りこぼしていたプロセスを取り込み、DNS モードは対象ドメインを想定したルールへ安定して一致させます。必要な結果をもたらさない層は、常時有効にしないでください。