Fake-IPとredir-hostを比較

まずDNSモードと通信の取り込みを分けて考える

dns.enhanced-modeは、Clash内蔵DNSがドメイン名の問い合わせにどう応答するかを決めます。fake-ipはマッピング用の仮想IPを返し、redir-hostは上流DNSで解決した実IPを返します。どちらもルールモードやグローバルモードの代わりではなく、接続先のプロキシノードを決めるものでもありません。

もう一つの要素が通信の取り込みです。システムプロキシの影響を受けるのは、通常、プロキシ設定に従うアプリだけです。TUNは仮想ネットワークインターフェースとルーティングを使い、より多くのIP通信を取り込みます。DNS問い合わせがコアに届いているか、アプリの接続がコアに戻っているかは、それぞれ確認が必要です。設定のモードをFake-IPに変えただけで、すべてのアプリが自動的にプロキシを経由するわけではありません。

• ドメイン名を保ったルール分岐を使い、DNSと接続の両方をコアに取り込んでいる場合は、まずFake-IPを試してください。
• アプリが実IPを必要とする場合や、LAN機器の検出に問題がある場合は、対象を個別にフィルタリングしてからredir-hostを検討してください。
• タイムアウトが発生した場合は、DNS、ルーティング、外向き接続のどこで問題が起きているかを先に切り分けてください。モード、ノード、ルールを一度に変更するのは避けましょう。

Fake-IPの仮想IPが機能する仕組み

Fake-IPの仕組みの要点は、ドメイン名と仮想IPのマッピングです。Webサイトのアドレスを恒久的に書き換えるわけではありません。アドレスプールには、予約済みのベンチマーク用アドレス範囲にある198.18.0.1/16がよく使われます。これはWebサイトが実際に公開しているIPアドレスではありません。このアドレスはプロキシコアが解釈する必要があり、通常の接続先としてそのままインターネットに送ることはできません。

1. アプリがドメイン名の名前解決を要求し、その問い合わせがClash内蔵DNSに届きます。
2. コアはアドレスプールから仮想IPを割り当てるか、既存のものを再利用して、ドメイン名との対応を保存します。条件に合うAレコードの問い合わせでは、通常、接続先ドメインの実際のAレコードを待たずに応答できます。
3. アプリがその仮想IPに接続し、TUNなどの取り込み経路を通じてコアに通信が渡されます。
4. コアはマッピングを使ってドメイン名を特定し、ルールに照合したうえで、該当するアウトバウンドに接続を渡します。DIRECT接続では通常、実際の接続先IPを解決する必要があります。プロキシ側で名前解決するかどうかは、プロトコルとアウトバウンドの実装によって異なります。

初回接続が速くなることがある理由

従来の経路では、接続開始前にDNSの実応答を待つことがよくあります。Fake-IPはこの待ち時間を短縮し、ドメイン名ベースのルールでドメイン情報を利用しやすくします。ただし、すべての通信が速くなるわけではありません。プロキシのハンドシェイク、TLS、リモートでの名前解決、接続先サーバーの応答時間は変わらず、IPベースのルールに一致すると実際の名前解決が必要になることもあります。

198.18.x.xが名前解決の結果に表示されても、Webサイトの障害や実際の送信元IPを意味するわけではありません。このアドレスに直接pingを実行しても、ノードの遅延を判断する材料にはなりません。実際の通信で確認し、コアの接続パネルでルール、ポリシー、エラーを調べてください。

redir-hostの名前解決経路と注意点

redir-hostでは、内蔵DNSが設定済みの上流DNSに問い合わせ、実IPをアプリに返します。コアは名前解決で得たドメイン名とIPの対応関係を記録し、後続の通信でドメイン名を特定する手がかりにできます。ただし、複数のドメイン名が同じIPを共有する場合や、アプリが内蔵DNSを経由しない場合もあるため、元のドメイン名を常に一意かつ完全に復元できるわけではありません。

実IPが返るほうが扱いやすいアプリもあります。たとえば、名前解決後のIPを比較するソフトウェアや、IPを別のプロセスに直接渡すアプリ、特定のLANアドレスへの接続が必要な機器などです。ただし、実IPが返っても必ずDIRECT接続になるわけではありません。TUNで通信が取り込まれていれば、引き続きルールに従ってアウトバウンドが選ばれます。

どちらのモードも、DNS漏えいを防ぐスイッチではありません。アプリ独自のDoH、取り込まれていないIPv6通信、外部DNSへ直接問い合わせるアプリは、それぞれ個別に確認が必要です。WebページのDNSテストで特定のDNSサーバーが表示されても、すべてのアプリが同じ経路で問い合わせているとは限りません。

Fake-IPの基本設定と利用条件

以下は既存設定に統合するdnsセクションのみです。プロキシノードやプロキシグループは含まれません。現在のサブスクリプション設定のほかの項目は残してください。クライアントが設定の上書きやマージに対応している場合は、永続化される設定箇所を編集し、次回のサブスクリプション更新で設定が上書きされないようにしてください。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.local"

• listenの1053はこの記事で使う待ち受けポートの例であり、HTTPやSOCKSプロキシのポートではありません。ループバックアドレスだけで待ち受け、LANにはDNSサービスを公開しません。
• default-nameserverは、DNSサーバー自身のホスト名を解決するなど、起動時の名前解決に使います。ここで行う通常のDNS問い合わせは、DoHのように暗号化されません。
• nameserverは通常の上流DNSを指定する項目です。HTTPSのURLを指定しても、すべてのDNS通信が自動的にプロキシ経由になるわけではありません。実際の経路を確認してください。
• OSの通常のDNS設定では、一般に1053のようなポートを直接指定できません。実際に利用するには、クライアントのDNS取り込み、TUNによるDNSリダイレクト、またはローカルフォワーダーとの連携が必要です。127.0.0.1を指定しただけで接続設定が完了したと考えないでください。

redir-hostと比較するには、enhanced-modeを一時的にredir-hostへ変更し、ほかの条件はそのままにします。アドレスプールとフィルターリストは、仮想IPの割り当てには使われなくなります。変更前にバックアップを取り、設定を再読み込みしてください。クライアントがDNS設定を管理している場合は、生成後の実行設定に変更が反映されていることを確認します。

fake-ip-filterで個別に例外を設定する

一般的なブラックリスト方式では、fake-ip-filterに登録したドメイン名にはFake-IPを割り当てず、実際の名前解決結果を返します。「そのドメイン名をプロキシに通さない」という意味ではありません。DIRECT接続かどうかはrulesで決まります。フィルター方式の切り替えに対応したmihomoのバージョンでは別の動作になることもあるため、リストをコピーする前にホワイトリスト方式などが設定されていないか確認してください。

まずドメイン名を個別に指定し、必要に応じて対象を広げる

たとえば、自宅のNASのドメイン名がnas.home.arpaで、アプリが仮想IPを受け取ると接続を拒否する場合は、まずこのドメイン名を個別に追加します。同じネットワーク内の機器でも同様の問題が起きる場合は、コアが対応するドメイン名のワイルドカード構文で対象を広げます。mihomoで一般的なマッチングでは、+.home.arpaはルートドメインとサブドメインを対象にできます。ただし、すべての旧バージョンのコアで使える汎用的な書き方ではありません。

dns:
  fake-ip-filter:
    - "localhost"
    - "nas.home.arpa"
    - "+.home.arpa"
    - "*.lan"
    - "*.local"

これは一部だけを変更する例です。先ほどのdnsセクションに統合してください。YAMLのトップレベルに同じ名前のdnsキーをもう一つ作らないでください。個別指定と、それを包含するワイルドカード指定は、必要に応じてどちらか一方にできます。長期運用する設定では、重複する項目を削除してください。

フィルターだけではLAN内の名前解決はできない

NASのドメイン名をフィルターに追加しても、上流DNSが実際のIPアドレスを知っている必要があります。パブリックDNSは通常、家庭内のドメイン名を解決できません。ルーターや内部DNSに該当ドメインを問い合わせるようにし、必要に応じてnameserver-policyで名前解決先を指定してください。フィルターを設定しても適切な上流DNSがなければ、仮想IPとの互換性問題が名前解決エラーに変わるだけです。

.localはmDNSで使われることが多く、LAN内のマルチキャストに依存します。*.localを追加すれば、該当する問い合わせに仮想IPが割り当てられるのを防げますが、コアがOSの代わりにmDNSで機器を検出するわけではありません。プリンターや画面共有機器では、マルチキャストによる検出経路とLAN内のルーティングを引き続き利用できるようにする必要があります。

名前解決の結果と接続経路を確認する

切り分けは、実行中の設定、内蔵DNSへの直接問い合わせ、アプリの接続確認の3段階で行います。設定エディターの表示だけを確認したり、ブラウザーでWebページを開けるかどうかだけで判断したりしないでください。

1. 1053番ポートに直接問い合わせる

digをインストールした環境で、以下の2つのコマンドを実行します。どちらもループバックアドレスの1053番ポートを明示して問い合わせるため、OSのDNS設定の違いによって別のDNSサーバーを誤ってテストすることはありません。

dig @127.0.0.1 -p 1053 example.com A +short
dig @127.0.0.1 -p 1053 nas.home.arpa A +short

Fake-IPでは、フィルター対象外のドメイン名に対して、通常は設定したアドレスプール内のIPが返ります。割り当てられる値は固定ではありません。NASのドメイン名に実IPが返るのは、フィルターに一致し、LAN内の上流DNSが利用できる場合です。問い合わせがタイムアウトする場合は、待ち受け状態と設定の読み込みエラーを確認してください。実際のパブリックIPが返る場合は、モード、フィルタールール、クライアントによる設定上書きを確認します。

2. ルールとアウトバウンドを確認する

クライアントの接続パネルを開き、対象のWebサイトにアクセスして、ドメイン名、適用されたルール、使用中のポリシーを確認します。仮想IPが返ったのに対応する接続記録がない場合は、通信がコアを迂回していないか、ルーティングの競合がないか、または別の未接続端末でそのIPが使われていないかを重点的に確認してください。

3. 古い状態を消して再テストする

モードを切り替えても、アプリが古いキャッシュや既存の接続を使い続ける場合があります。まず対象アプリを終了し、OSのDNSキャッシュを消去してから再起動してください。Windowsではipconfig /flushdnsを実行します。systemd-resolvedを使うLinuxではresolvectl flush-cachesを実行します。アプリ独自のDNSキャッシュは、OSのキャッシュを消去しても残る場合があります。

profile.store-fake-ipを有効にすると、一部のコアではマッピングが永続化されます。既存のマッピングを復元するのに役立ちますが、あらゆるタイムアウトを解消する設定ではありません。アドレスプールを変更する場合は、クライアントが対応する方法で古いマッピングを消去し、接続を作り直してください。用途が分からない設定ファイルを直接削除するのは避けましょう。

症状に応じてモードを選ぶ

• 一般的なWebサイトやアプリが正常に動作する：現在のモードを維持してください。漠然と速くなることを期待して、何度も切り替える必要はありません。
• NAS、プリンター、LAN内のドメイン名だけに問題がある：環境全体のモードを切り替える前に、フィルター、LAN内DNS、ローカルルーティングを確認してください。
• アプリが仮想IPを明確に拒否する：まず、そのアプリが実際に問い合わせているドメイン名を例外に追加してください。依存するドメイン名が多く管理しにくい場合は、redir-hostを試します。
• Fake-IPを使ったすべての接続がタイムアウトする：仮想IPのアドレス帯に対するルーティングと通信の取り込みを優先して確認してください。DNSの応答に成功しても、接続がTUNに届いているとは限りません。
• redir-hostで一部サイトに適さないIPが返る：DNSの出口とプロキシの出口が一致しているか確認し、上流DNSをむやみに増やすのではなく、ドメイン名ごとに名前解決ポリシーを設定してください。

最終的な判断には、再現性のある通信結果を使います。同じ端末、同じノード、同じドメイン名で、DNSの応答、適用ルール、接続の成否をそれぞれ確認してください。Fake-IPはマッピングによってドメイン名を保ち、名前解決のタイミングを調整する方式です。redir-hostはアプリに実IPを返す方式です。どちらを選ぶかは、実際の通信の取り込み方法とアプリの要件に合わせて判断してください。どちらか一方がすべての状況に適するわけではありません。