Fake-IPとRedir-Hostの違い｜DNS拡張モードの仕組みと選び方

2つのDNS拡張モードの主な違い

Fake-IPとRedir-Hostで決まるのは、ClashがDNSクエリを処理した後にアプリへどのアドレスを返すか、そして後続の接続をドメイン名にどう関連付けるかです。「ルールモード」と「グローバルモード」の代わりではなく、ノードのプロトコルを決めるものでもありません。トラブル時は、DNS応答、通信の取り込み、ルールの適用、外向き接続を分けて確認しましょう。

以下の設定例は、主にClash Meta（mihomo）を対象としています。従来版ClashやClashXの各種コア、グラフィカルクライアントでは、対応フィールドや設定の上書き方法が異なる場合があります。まずクライアントの「バージョン情報」またはコア情報で名称を確認し、実行中の設定を調べてください。アプリ名だけで設定の互換性を判断することはできません。

Fake-IP：仮想IPを割り当ててからドメイン名と紐付ける

1つの接続が処理される流れ

1. アプリがドメイン名のAレコードを問い合わせ、クエリがコアのDNSサービスに届きます。
2. コアが設定済みの仮想IPプールからアドレスを割り当て、「ドメイン名 ↔ 仮想IP」の対応を保存します。
3. アプリがその仮想IPへの接続を開始し、TUNなどの通信取り込み機能を通じてコアに渡されます。
4. コアは対応情報からドメイン名を特定し、ルールに基づいて外向きの接続先を選びます。その後、ローカルで実アドレスを解決するかどうかは、ルール、接続先の種類、プロトコルの機能によって異なります。

一般的な設定例 fake-ip-range: 198.18.0.1/16 では、ネットワークのベンチマーク用に予約されたアドレス空間を使用します。これらは接続先サイトのグローバルIPでも、ノードのアドレスでもありません。この処理経路では、ブラウザーでページを開ける一方、システムの名前解決結果に 198.18.x.x が表示されても正常です。

Fake-IPの利点は、アプリが接続しようとしているアドレスをドメイン名に明確に紐付けられ、実IPだけから接続先を推測せずに済むことです。複数のドメイン名が同じCDNアドレスを共有することがあり、実IPとドメイン名は一対一ではありません。仮想IPによる対応付けで、こうした曖昧さを減らせます。ただし、すべてのリクエストが速くなるわけではなく、無効なサブスクリプション、到達不能なノード、誤ったルールを解決するものでもありません。

Redir-Host：実アドレスを返し、名前解決の対応情報を保持

Redir-Hostは実際にDNSで名前解決してから、その結果をアプリに返します。アプリには実際に解決されたアドレスが表示され、コアは観測済みのDNSレコードなどを使ってドメイン名と関連付けます。接続ごとにインターネット上でPTR逆引きを実行する方式ではありません。ここでいう「ドメイン情報の照合」とは、主に既存の対応情報からドメイン名のコンテキストを復元することです。

名前解決結果の確認やインターフェースのアドレスとの比較を行うアプリ、独自にネットワーク接続を処理するアプリでは、この方式のほうが挙動を把握しやすいでしょう。ただし、アプリが独自の暗号化DNSを使う場合、IPアドレスを直接指定して接続する場合、クエリがコアを経由しない場合は、ドメイン名との関連付けが不完全になることがあります。複数のドメイン名が同じアドレスを共有している場合も、1つのIPを特定のドメイン名に結び付けることはできません。

Redir-Hostに切り替える前に確認すること

• プリンター1台または特定の内部ドメインだけで問題が起きる：まずは対象にFake-IPの例外を設定し、適切な内部DNSを指定しましょう。すぐに全体のモードを切り替える必要はありません。
• アプリが実DNSの結果を明示的に必要とする：Redir-Hostに切り替えて比較テストし、適用されたルールと名前解決結果も記録しましょう。
• ノードへの接続がタイムアウトする：まず外向きアドレスとネットワークへの到達性を確認しましょう。DNS拡張モードを切り替えても、ノードのハンドシェイク結果が変わるとは限りません。

TUNモードでFake-IPがよく使われる理由

TUNは、仮想NICにルーティングされたIPパケットをシステムのネットワーク層で受け取るため、システムのHTTPプロキシ設定に従わないアプリの通信を取り込むのに適しています。ただし、IPパケット自体に元のドメイン名が含まれるとは限りません。Fake-IPの対応情報があれば、仮想IP宛てのパケットを受け取ったコアがドメイン名を特定できるため、TUNでドメイン名ルールに基づいて通信を振り分ける際によく使われます。

ただし、TUNとFake-IPは別々の設定です。TUNを有効にしてもDNSクエリが必ずコアに届くわけではなく、Fake-IPを選んでもすべてのアプリの通信が取り込まれるわけではありません。ブラウザーのセキュアDNS、別のVPNのルーティング、企業が配布するDNSポリシーなどにより、DNSクエリと接続が異なる経路を通ることがあります。

mihomoの設定例

以下はDNSとTUNの部分のみを示した例です。ノード、プロキシグループ、完全なルールは含まれていないため、そのまま接続に使えるサブスクリプションではありません。既存の設定に統合する際は、同名のセクションを編集し、トップレベルに dns や tun が重複しないようにしてください。

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

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

ここでの 1053 は、ローカルでDNSテストに使う待ち受けポートです。HTTP、SOCKS、混合プロキシのポートではありません。例にある上位DoHアドレスは、現在のネットワークとコアのDNS送信設定で到達できる必要があります。到達できない場合は、クライアントを何度も再起動するのではなく、環境で利用できるDNSサービスに変更してください。

dns-hijack は、TUNが受信したうち、指定ポート宛てのDNS通信を対象にします。ブラウザーからHTTPSで送信されるDoHリクエストを自動的に復号する機能ではなく、すべてのシステムでローカルDNS通信を捕捉できるわけでもありません。TUNの利用には、システム権限や対応するサービスも必要です。権限がない場合は、まず起動ログのエラーに対処してください。

fake-ip-filterの書き方とLAN向けの例外設定

一般的なデフォルトのブラックリスト方式では、fake-ip-filter に指定したドメイン名にはFake-IPを割り当てず、通常の名前解決経路で得た結果を返します。新しいmihomoではフィルターモードなどの拡張フィールドも利用できます。設定で fake-ip-filter-mode を明示している場合は、その意味を先に確認してください。デフォルトの動作をそのまま当てはめないようにしましょう。

例外は必要なドメイン名だけに絞る

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "printer.home.arpa"

printer.home.arpa は説明用のLAN名です。実際のデバイスのドメイン名に置き換えてください。単一のデバイスには完全一致の名前が適しています。*.lan のような項目は、該当するサフィックスのサブドメインに使います。ワイルドカードの適用範囲はコアによって異なる場合があります。これらの文字列を正規表現として扱ったり、確認せずルールリストの構文に混ぜたりしないでください。

• フィルター設定は直接接続を意味しません：仮想IPを返さないようにするだけで、DNS応答の方法が変わります。接続が直接接続になるかどうかは、引き続きルールと外向き接続のポリシーで決まります。
• フィルター設定はDNSサーバーの指定とは異なります：内部ドメインの名前解決には通常、ルーターや社内DNSが必要です。必要に応じて、コアが対応する nameserver-policy で使用するDNSサーバーを設定してください。
• フィルター設定はサービス検出の代わりにはなりません：.local はmDNSを使うことがよくあります。プリンターの検出には、マルチキャスト、ネットワークインターフェースの選択、ファイアウォール設定などが関わる場合もあります。ドメイン名の例外を追加しても、検出機能が必ず復旧するわけではありません。

モード切り替え後の確認手順

一度に変更する項目は1つだけにします。現在正常に動作している設定を保存し、元のDNS拡張モード、上位DNS、TUNの状態、問題が起きるドメイン名を記録してください。グラフィカルクライアントでは、サブスクリプションが画面上の設定や上書きファイルによって書き換えられる場合があります。サブスクリプションの元ファイルを編集した後、実行中の設定にも変更が反映されたか確認しましょう。

1. 設定を再読み込みしてログを確認：DNSの待ち受けとTUNの作成が成功し、ポートの競合やフィールドの解析エラーがないことを確認します。
2. コアのDNSに直接問い合わせる：dig がインストールされたmacOSまたはLinux環境で、以下のコマンドを使って例のドメイン名を問い合わせます。
3. システムの名前解決経路と比較：次に、サーバーを指定せずに問い合わせます。結果が異なる場合は、まずシステムのクエリが本当にコアを経由しているか確認してください。
4. アプリで接続をやり直す：対象アプリを終了してから再起動します。必要に応じてシステムのDNSキャッシュを削除し、古い実アドレスや仮想IPの影響を避けましょう。
5. 接続ログを確認：ページが開くかどうかだけでなく、接続先のドメイン名、適用されたルール、実際の外向き接続先を確認します。

# 上記の設定を使ってコアのDNSに直接問い合わせ
dig @127.0.0.1 -p 1053 example.com A +short

# システムのデフォルト経路で名前解決を確認
dig example.com A +short

Fake-IPモードでは、フィルター対象外のAレコードクエリに対し、通常は設定したアドレスプール内のIPが返ります。Redir-Hostモードでは、上位DNSから返された実レコードが返ります。example.com はテスト方法を示すためのドメイン名です。実際のトラブル調査では、問題が発生しているドメイン名を問い合わせてください。AAAAクエリに仮想IPv4アドレスが現れるかどうかで、Fake-IPの動作を判断しないでください。

OSごとにDNSキャッシュを削除

Windowsでは、コマンドプロンプトで ipconfig /flushdns を実行します。macOSでは通常、次のコマンドを使います。2つ目のコマンドはシステムのDNSサービスにシグナルを送るため、実行時に表示される指示に従って管理者パスワードを入力してください。systemd-resolvedを使用するLinuxでは resolvectl flush-caches を実行できます。それ以外のディストリビューションでは、実際に使用しているDNSサービスに応じて対処してください。

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

システムのキャッシュを削除しても、ブラウザー内部のキャッシュは自動的に消えません。また、期限切れのFake-IP対応情報が保持されるとも限りません。モードを切り替えた後は古い接続を終了してから再テストしてください。コアの再起動後に古い仮想IPの問題が頻発する場合は、クライアントがFake-IP対応情報の永続化に対応しており、その機能が有効か確認しましょう。

よくある問題と優先して確認する項目

また、ping の失敗だけでは、Webサイトにアクセスできないとは判断できません。ICMPとブラウザーのTCP・QUICリクエストは異なる種類の通信であり、Fake-IPのICMP処理もコアや通信の取り込み方法によって異なります。実際のアプリからのリクエストと接続ログを使って確認してください。

モード選択と最終確認

TUNで通信を取り込み、ドメイン名に基づいて安定して振り分けたい環境では、まずFake-IPを使い、互換性の問題が確認されたドメイン名に限って例外を追加できます。実DNSの応答を必要とするアプリでは、Redir-Hostに切り替えて比較テストしてください。モード変更後も、適切な上位DNSとドメイン名ルールを維持する必要があります。

最後に確認するのは4点です。DNSクエリを誰が処理するか、アプリがどのアドレスを受け取るか、接続を誰が取り込むか、ルールでどの外向き接続先が選ばれるか。それぞれの根拠を確認してから、DNS拡張モード、フィルターリスト、ルーティングのどれを変更するか決めましょう。プロキシポートやルールの概念については、使い方ガイドと用語集もご覧ください。