目次
ブラウザーは使えるのにターミナルの接続記録がない場合と、リクエストは記録されるのにドメインルールが効かない場合では、変えるべき設定が異なります。前者は通信がクライアントに届く仕組みを、後者は実際のドメイン、名前解決の結果、ルールを確認します。ノードやサービス自体の不具合は、取り込む通信の範囲を広げても解決しません。こうした違いを押さえると、仮想アダプターを使うべきか、内部ドメイン一つに例外を設定すればよいかを判断できます。
システムプロキシと TUN がアプリの通信を取り込む仕組み
システムプロキシを有効にすると、Clash はローカルプロキシアドレスをOSへ書き込み、この設定を参照するアプリが HTTP、HTTPS リクエストをそのポートへ送ります。ブラウザは通常この設定を使いますが、ターミナルツール、ゲーム、一部のデスクトップアプリは使わない場合があります。システムプロキシだけでは UDP を一律に取り込むこともできません。
TUN は仮想アダプターを作り、システムルーティングを通じて、より多くの TCP、UDP 接続を Mihomo へ入れます。「このプロセスがローカルプロキシポートを使っていない」という入口の問題は解決できますが、ノードの可用性、ルール順序、サーバーが返す 403 は変えられません。
二つの入口方式の主な違い
| 項目 | システムプロキシ | TUN |
|---|---|---|
| トラフィックを Clash へ入れるかを誰が決めるか | アプリがシステム設定を参照するか | システムルーティングと仮想アダプター |
| UDP | 通常は取り込まない | TUN へ入れることはできるが、ノードと設定には引き続き依存する |
| システム権限 | プロキシ設定の変更 | 仮想アダプター、サービス、またはネットワーク拡張の権限も必要 |
| ロールバック | プロキシスイッチを無効にするだけ | TUN を無効にし、ルートとインターフェースが解除されるまで待つ |
- アプリが接続を開始するブラウザ、ターミナル、ゲーム、またはバックグラウンドサービス
- システムプロキシまたは TUNそのトラフィックがコアへ入れるかを決める
- ルールと DNSドメインを維持し、直接接続かプロキシかを決める
- 実際の送信経路DIRECT、プロキシノード、または拒否
システムプロキシまたは TUN が通信をコアに渡します。その後、直接接続するかプロキシノードを使うかは、ルール、DNS の結果、ポリシーグループによって決まります。
Connections でアプリに TUN が必要か判断する
同じ操作で前後を比較する
Profile、Rule モード、ノードを固定する
自動切り替えや設定更新が入口のテストを妨げないようにします。
システムプロキシだけを有効にする
対象プログラムで、決めた操作を一つ繰り返します。
Connections を確認する
リクエストが表示されていればクライアントに届いています。続けてルールとログを確認します。
記録がない場合に限り TUN を有効にする
同じ操作をもう一度行い、新しい接続が表示されるか比較します。
TUN で新しい接続が表示されて成功すれば、不足していた取り込み範囲を補っています。二つの入口のどちらでもリクエストが見えるのに同じ timeout になる場合は、入口を切り替え続けず、ノード、DNS、対象ネットワークを確認してください。
auto-route、出口アダプター、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:53ドメインルールが効かない場合は DNS が Mihomo に入るか確認する
DNS はドメイン名を接続用のアドレスに変換します。名前解決が Mihomo を迂回すると、コアには IP しか見えず、ドメインルールが想定どおりに一致しないことがあります。解決結果とプロキシの出口が合わず、トップページは開いても画像が失敗したり接続が不安定になったりする場合もあります。
dns-hijack は対象の DNS 通信を Mihomo 内部の DNS へ渡しますが、すべてのシステムで自動的に動くわけではありません。Windows と macOS では、LAN 内の DNS サーバーへ送るクエリを自動で取り込めないため、実際のシステム DNS アドレスと取り込み結果を確認します。Android のプライベート 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 上流、ログを続けて確認する |
redir-host と単一ドメインの fake-ip-filter 例外
一部の企業向けソフトウェア、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 と表示される
コアがドメイン名を取得できているか、より広いルールが先に一致していないかを確認します。
Web 閲覧、UDP、社内ネットワークに合う方法
利用場面に応じて選択する
| 利用場面 | 推奨する開始方法 | 選択理由 |
|---|---|---|
| 主にウェブ閲覧と、システムプロキシに従うデスクトップアプリを使用する | システムプロキシ | 必要な権限が少なく、無効化しやすく、接続経路も明確 |
| ターミナルやゲームランチャーの記録が Connections にない | アプリプロキシまたは TUN と比較する | システムプロキシを使用しないプロセスも取り込める |
| UDP の処理が必要なアプリ | TUN | システムプロキシでは UDP を一括して取り込めない |
| 社内ネットワーク、仮想マシン、複雑なローカルネットワーク | システムプロキシから始める | まず元のルートを維持し、TUN の除外範囲を一項目ずつ検証する |
| 特定ドメインのルールが誤った経路を選ぶ | 既存の接続方式のいずれか + ルール修正 | 取り込み範囲を広げても、最初に一致するルールは変わらない |
この選択は固定ではありません。普段ブラウザしか使わないときは TUN を無効にしてシステムプロキシへ戻し、特定のプログラムで必要になったときだけ再び有効にできます。切り替え後は、スイッチの色だけで判断せず、元の操作と Connections で結果を確認してください。
TUN の無効化、システムプロキシの復旧、古いポート設定の処理
TUN を有効にした直後にすべての通信が止まった場合は、まず TUN を無効にし、元の Profile とノードを維持します。システムプロキシで復旧するなら、原因は仮想ネットワークアダプター、ルート、または TUN の DNS にあります。システムプロキシでも失敗するなら、ノードと設定を見直してください。無関係な設定まで消去されるため、いきなり OS のネットワークリセットを実行しないでください。
クライアント終了後もページが開かない場合は、システムプロキシに 127.0.0.1 の古いポートが残っていないか確認します。解除したら、普段は直接接続できる宛先で復旧を確かめます。